SQL Server Acceptance Testing: A Subtle Trick

In previous posts, I outlined reasons to avoid in-place upgrades of SQL Server, along with detailed migration steps and guidelines for demoting your old server and promoting a new server as part of a 'side by side' migration. In both posts the idea, or notion of acceptance testing was stressed as not only a huge benefit of side-by-side upgrades, but also as something that you'd be dumb not to do.

In some environments, acceptance testing is pretty simple and easy to pull off—especially if there are more formalized QA routines or guidelines (and/or staff) in place. In many environments, however, acceptance testing can be a huge pain for DBAs as it commonly means that DBAs end up being reliant upon non-technical users to carve time out of their day, connect to a 'test' server or application instance and then 'go through the screens' and try to verify that everything is working correctly.

Use Meetings to Prioritize Acceptance Testing

As a consultant, I've helped a number of organizations (especially those without full-time DBAs on staff) with migrations to newer versions of SQL Server. In a couple of cases, overall migration plans and scheduling can and do get sidelined, however, when key users tasked with acceptance testing just don't find (or make time) to verify that everything is working as expected. Fortunately, I've found a fairly subtle (but, in some ways, scummy) way to help move this along when repeated requests to key end users conducting the acceptance testing don't seem to help testing efforts to materialize. And, sadly, the key I've found in the past is to use meetings.

Sadly, the business world runs on meetings. To that end, it's possible to use that fact to your advantage when trying to push the need for acceptance testing along. Personally, I find that many meetings in the business world are a waste of time (or worse), so I'm not advocating something stupid here—such as trying to spin up an 'all hands on deck' meeting where you try and shame someone or anything else as equally lame, sloppy, or vile. Instead, for people who are simply too busy (or too unable to prioritize) to tackle much needed acceptance testing, I've found that a key way to tackle this is simply to schedule a one hour meeting with them—at their desk.

Meet the Needs of End Users

For folks who continuously promise that they'll 'get to it' but don't, something formal and rigid like a meeting can commonly be a great tool for both them and you. For them, it gives them a 'hard' excuse to block out some time to accomplish what is needed. And for you, it gives you the opportunity to stroll over to their work area, help make SURE they're pointed at the right test applications/servers, and observe some of the key 'screens' or activities that they'll be testing. It also gives you a chance to better understand how (and for what) key users end up using your applications and data. Also, when done correctly, a meeting can be a great way to help ensure that you're helping meet the needs of end users (instead of merely being seen as some sort of impersonal 'data dictator' perched in your tour somewhere).