A Simple Tip for Acceptance Testing

Document Type: Tip

Released: 2024-09-10

Acceptance Testing

While Acceptance Testing can play a critical role when it comes to the migrations, upgrades, and new-feature releases that DBAs (and DEVs) need in order to keep things moving on their end, the reality is that getting SMEs (who are typically pulled in myriad directions) to provide testing in a timely manner can be a challenge.

Basic Requirements for Acceptance Testing

To help facilitate a timely turn-around for testing, there are a couple of things that DBAs and DEVs can tackle out of the gate when throwing out requests for help:

• Start by making sure that the testing environment is easily accessible, fully configured, and that your SMEs can easily navigate to and log-in to the test environment. (This one sounds obvious, but NOTHING is going derail testing for your SMEs than testing/QA servers being powered down, or not being able to log in when they go to test, or something lame like there being SOME known bug for your group that makes features x, y, and z not work when you hope SMEs can overlook these issues and just focus on sections g, m, and Q of your app/site.)
• Keep your testing requests specific, bite-sized, and actionable - i.e., make sure to avoid anything nebulous, open-ended, or that might cause any kind of cognitive dissonance for your SMEs. In short, help them to help you.

Harnessing the Powers of Evil (i.e., Meetings) for ... Good

If you've already done the above, and you're not seeing results in a timely fashion (and are starting to worry about project dates starting to slip, etc.), then there is another, albeit slightly evil, approach that you can take: scheduling a meeting.

And, to be fair, I am NOT recommending 'meetings' in the traditional sense (i.e., where a bunch of people from different departments are pulled away from whatever they're TRYING to get done so that they can discuss some new thing or other problems).

Instead, what I'm advocating is that a meeting on someone's calendar is much more concrete than a request fired off by email or lobbed at someone during another, previous, meeting.

Collaborative Testing Sessions - Not a Typical Meeting

Specifically, what you're really looking at here is some shared time where you and an SME can collaborate on testing together - vs asking them to try and tackle testing on their own.

In fact, one of the biggest benefits of this kind of meeting is that - in many cases - you'll find that (at least initially) some SMEs simply don't have any real idea of "where to get started" when it comes to testing - and that you, as a technical person, showing up and offering to help them navigate to a test site/app, log in, and then showing them exactly what you're hoping they can validate is the exact thing they needed in order to be able to help them get this task (testing) off their plate.

And, obviously, trying to block out collaborative testing sessions isn't always going to work (time after time) - and may NEVER work with some SMEs. But, the approach of scheduling collaborative time on someone's calendar has worked insanely well for me in the past as it's a great way for you to show up and HELP someone else (who is then helping you).

Some general recommendations when attempting to harness the powers of evil ... for good:

• Again, these 'meetings' aren't to brow-beat anyone - period. Instead, they're blocks of time for you to collaborate with others.
• Keep these meetings short; 30-40 minutes is typically ideal. You want enough time to to be able to get something done (i.e., spin up the test environment and collaborate) without causing anyone to be fearful that you're capitalizing their time or RISKING them clicking on 'Decline' for the meeting request.
• Have fun. 'Meetings' may suck in your book, but by being respectful and looking for ways to genuinely help your co-workers while collaborating, you're much more likely to be successful in with short-term needs while also 'networking' and laying solid foundations for helping address future needs as well (for both you and your co-workers).