User Acceptance Testing

Those of you familiar with the Information Technology (IT) industry will be familiar with the term User Acceptance Testing, or UAT Testing as people lovingly refer to it. I'm not sure why there's the need to double up on the testing, but hey why say one TLA when you can stick another word on the end to make it sound like you know what you're doing?

Today I've sat in a meeting discussing how you can meet a clients needs by getting them the data they want. The noises from the other side of the table were all of the "ah-but-no" kind. Ah, well we could do that and it's a good idea; but it means that we won't be able to complete the BIG project work we need to do and therefore, no, we won't do it because it could compromise the end deliverable. Then you get a whole bunch of techno-babble that indicates they really don't understand what they're saying at all. I'm sure there's a Dilbert cartoon out there describing this very phenomenon.

So in the life of any project, after you've waded through the joy of figuring out what the user really wants and then fight endlessly with IT to get some useful scrap of functionality onto your desktop you get into UAT and start to execute well laid out plans with rigidly documented test cases to ensure you've fully tested the application and ensured that nothing goes wrong at delivery.

The problem with this approach is that it fails to cater for the "do stuff" test conditions. There's a distinct lack of imagination about how a person interacting with the system might choose seemingly random and meaningless key strokes, enter all sorts of weird search data and generally play about with the system the way a two year old randomly pounds the keyboard on your machine. This is the testing approach I favour most. By all means, it's great to run through a documented set of scripts that ensure you didn't cock anything up with the latest release. But if you have a complicated interface you should really put it through its paces by coming up with all sorts of weird combinations that lie outside the documented tests. You will be surprised by how many weird errors pop up in systems that don't have many users; especially when the developers were under pressure to get the end product out the door.

As they say, if engineers built buildings the way computer programmers wrote code, the first woodpecker to come along would destroy civilization.

Unfortunately in the world of IT, the scum of mediocrity floating on top of the pond is choking the undergrowth to death.