News

UAT stands for User Acceptance Testing, and in my opinion the hardest type of testing of all to do!

Why is it so hard? Well there are a myriad of reasons and I am going to explain to you why I think that UAT is like testing with all your arms and legs tied tight behind your back!

First your right arm…this is the arm that knows about testing….this is the arm that knows how to design tests to find the key defects. Most people doing UAT are not testers, so they miss out on the knowledge of good and thorough test design. They struggle to clearly define their test conditions (the thing they are trying to prove) and then find it almost impossible to define clear test cases (how they will know they have proved it). Why is this so? Well because of the unenviable mind set in our industry that says “anyone can test”. Testing is more than randomly running scenarios through our systems. The skill of the user at UAT is in the domain knowledge – how the system and business works, not in the testing knowledge – how to structure effective testing. So these users end up being thrown in the deep end with no knowledge on how to apply test design techniques to prove important things about their applications.

Now the left arm….this is the arm that knows about the system…this is the arm that knows where the bugs will probably be and how best to find them. In the UAT environment we often ask people to “prove the system works” but only supply the front end or GUI (graphical user interface) to them through which they have to design tests (see above – Right Arm) that execute the business needs while also getting coverage of the system. This is impossible to do! There is no way that UAT can get system coverage unless the people executing UAT have a fundamental knowledge of the system components and structure. They need to know the key flexion points in the system to know how to design scenarios that exercise them! But sadly at UAT these are hidden from the people executing the tests. They usually only get to see and use the GUI which immediately limits the coverage possible!

Then we tie up the right leg, this is the tools that we can use for testing. Theoretically UAT should be conducted in a “live like” environment, the same set up and configuration that we would have in the production environment. This means no tools or equipment that is not in live. This makes it almost impossible for UAT to do anything except manual testing. Manual testing is brilliant as it uses the greatest test tool known to us all….the brain….but it also is quite reliant on the user of the brain to be actively engaged, know what they are looking for, and even worse, able to execute lots of scenarios very quickly. Why quickly?

Well that’s the left leg that we tie up. We leave UAT until right at the end of the lifecycle, when there is maximum slippage, maximum pressure to release and minimum time to do everything that needs to be done. UAT is the victim of all the other stages of the lifecycle slipping in their delivery dates and is squeezed right at the end. This is a tragedy as typically UAT test cases are big and long and complicated. They take time and energy to set up, execute and analyse the results of. No one works well under pressure and in UAT time pressure is paramount!

UAT – wow what a battle to do, with all the impediments associated with it, is it any wonder that it can be seen as a nightmare and something that is best avoided by participants. There is huge risk associated with getting it wrong and enormous pressure on the team to achieve the impossible. My hat is off to all those working in this stage of the lifecycle!