Strategies for Effective UAT

One of the perks I’ve enjoyed about being a Consultant is that I’ve been able to work in a number of different organisations in a range of roles. I’ve had the pleasure of working in some very small private companies to massive companies with offices around the world, as well as a number of public and government organisations, again both large and small. One would think that each of these different environments would have their own unique challenges, and they do to a certain degree, but you’d be surprised how many things are exactly the same across the board.

Take User Acceptance Testing (UAT) for example. This is something every organisation, large or small, private or public, is challenged with and every organisation I’ve worked for faces the same challenges.

I’ve written a previous blog about UAT from the developer’s point of view and highlighted some things the developer/tester can do to help the customer carry out their testing. But in another of my roles, I was the customer for an application someone else was developing and I had to change hats from creating test plans to using them.

1. There is never enough time

   As a developer, I’d spend two weeks pouring all my energy into coding and debugging the latest and greatest release of the software to get it ready for testing on time. I’d hand it over to the customer, complete with a UAT document and test scripts with a tight deadline so we could keep the project on schedule. Obviously, that’s the most important thing after-all. Then, once the deadline for UAT had well and truly passed, I’d get annoyed that the UAT hadn’t been completed, despite all my hard work.
   
   As a customer, and more specifically, as a Team Leader of a large and busy Service Desk, spare-time is something in short supply. Yes, I realise the UAT is essential for a successful launch of the software my team relies upon to do their job. Yes, I also know I gave my word in good faith to carry out the UAT in a timely manner but I also have other real-world, time-sensitive issues to deal with; a team to manage, a demanding serve to deliver and meetings to attend. Making time for UAT can be a challenge.
2. 
   

   So, here’s some ideas that might help:

   a) Schedule UAT into your calendar like it is a meeting. Book out the time far in advance so no one else takes that time slot.
   
   b) Find someplace away from your desk to do UAT if at all possible. A small meeting room is good, working from home might be an option, or even a broom closet. Just get away from your desk so you aren’t disrupted by people asking for your assistance. You have a good team after all, trust them to do the work for a few hours. They’ll be OK without you.
   
   c) Turn off your phone, close Outlook, Messenger, Teams and any other application that might send a distracting pop-up. You’d do the same if you were sitting on an interview panel all day, so give UAT that same level of respect. In fact, give it your full attention.
   
   d) Delegate. Get some of your team (assuming you’re a team leader) to help with the testing. This won’t only free up your time but will provide an additional set of eyes on the project.
   
   

3. Feel free to colour outside the lines

   If you’re the UAT tester, and someone else has written the test scripts for you, use them as a guide, not a rule book. Often the developer will write the UAT scripts because they want to focus the testing on the parts of the software that has changed, but they may not fully appreciate how you use the software.
   
   For example, in my career I’ve worked extensively with call logging software used in IT Departments to log and track tickets. This is essential software for any IT Department but is the bread and butter of the Service Desk. Often, only Service Desk Analysts log, progress and resolve tickets, whereas other teams may only progress and resolve. The Service Desk uses this software in a unique way and will often be the experts.
   
   It may be important to check the entire life-cycle of a ticket, and not just the parts of the software that changed, because sometimes the user will find the new release impacts on a part of the software the developer wasn’t aware of because they don’t use it on a day-to-day basis, or in the same way.
   
   

4. Make time for the deep dive

   When scheduling meetings between developer and customer, allow plenty of time to delve deep into particular topics. The to-do list for the developer can sometimes get quite long, and when they go to a meeting they are just looking for a thumbs up on all the items so they can start coding.
   
   However, sometimes the customer can feel like their concerns aren’t heard or given enough attention. There will always be one or two items in a list of fifty that needs fifteen minutes to fully hash out. It may seem like a minor thing to the developer but might actually be quite vital to the customer and the success of the end product. Make the time to listen.

All of this may seem like common sense. But you’d be surprised how many organisations get it wrong, even with Jedi Master level Agile experts running the show. UAT is a crucial step in any successful project, and the greatest risks to UAT often times comes down to poor planning, limited test scripts and poor communication.

Lastly, even with all of this in place, UAT may take longer than expected. Don’t get frustrated. Appreciate the customer has a full-time job on top of UAT. Sometimes getting it right is more important than getting it out on time.