Improving user acceptance testing sessions

July 12, 2012

I’ve been involved in quite a few UAT sessions with clients, and they can be very frustrating for a developer. You’ve spent weeks working on something only for someone who knows next to nothing about it to say that it’s all terrible. The temptation is to go on the defensive, and adopt a default position of reject all bug reports, especially when confronted with irritations like:

  • Duplicate issues
  • Multiple defects in the same issue
  • Badly described issues
  • no steps to recreate
  • no screenshot
  • no mention of expected or actual behaviour
  • Users who think they’re too important to waste time using the bug tracking tool, and just send emails
  • Defect severity inflation - users who mark every single bug as critical or major

The worst example I ever saw was a single bug report, containing nothing but a zip file. Inside the zip file was a scan of about 20 black and white printouts from the browser, with notes scribbled on top.

It’s easy to get annoyed, blame the users and say that they’re a bunch of morons, but that’s missing the point. Unless the client is paying for specialists, testing isn’t their job. In that respect they’re like the average web user - not necessarily all that computer-aware, but using the thing you’ve built. So in that way, they’re ideal to test it. If the thing had only been tested by developers, I’d have some serious doubts about its usability.

Having said that, a testing session is work, so people should take a professional attitude to it.

It’s also important for the developers (or whoever is doing client liaison) to set the sessions up the right way.

  • explain what’s expected of the testers
  • provide a reference of what the categories mean
  • make sure that someone is triaging bugs

There are a lot of resources on testing out there, including this document by Cem Kaner of Florida Institute of Technology - it could do with a bit of design work, but it’s full of salient information, such as: “The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.”

The other place I’ve found good stuff is the Software Quality Assurance & Testing section of Stack Exchange.

The bottom line really is that testing shouldn’t be considered a chore or a necessary evil. It’s there to make sure that the thing works, and testers need to keep developers honest.

Testing should be respected.