As we approach User Acceptance Testing (UAT) in our projects, clients like to hear some of the things that can help drive a successful UAT cycle.
We want UAT to mean something. I’ve been in projects where UAT ends up just being a rubber stamp; another spot to run the same old tests in the same old way, but at the hand of a group of end users. While it’s great that we can still get something out of an uninspired UAT, there is something more we can strive for. This is where the designed and developed functionality is finally tested against the needs and experiences of the end user. It’s one of our last chances to make sure we are still on-track for delivering something that will be useful and accepted.
The most successful UATs I’ve witnessed are ones where the end users (the ‘UAT participants’…the ‘testers’) are engaged and informed enough to really get to that space of testing and analysis that drives real feedback. When they are focused on the goal of building their own acceptance of the solution they are about to adopt and to test its boundaries to ensure it does what they need. What can we do to foster that focus and drive so that User Acceptance Testing really means something?
Include Diverse Personalities
You can probably look across your base of users and group them based on how they’ll be using the solution; their particular group’s needs. It’s easy to see how including testers from across those different user groups would be helpful during UAT, especially in testing the flexibility and effectiveness of your solution.
It’s likely you can also look across that base of users and see how they fall into different broad personality groups. While everyone’s feedback is useful, it’s sometimes a little more difficult to remember how helpful it can be to include those different personality types. Here are some of the ones that seem to be the most common and what they can bring to a UAT cycle.
(Disclaimer time. These are generalizations. The point isn’t to pigeon-hole anyone. In fact, the traits listed below aren’t exclusive. Everyone is unique and will bring their own flair and personality to the table. This is an exercise in noting how some facets of everyone’s personality can be help the success of UAT.)
- High-Volume Users – these are the users who are used to processing a high volume. Testers from these groups tend to have a good number of scenarios and experience to bring to the table. They are good at spotting things that take away, or add to, the efficiency of the process. They can also ensure the UAT includes a healthy amount of standard-scenario tests and identify scenarios that may not be standard, but happen commonly enough to test for.
- Excited/Expectant Users – including users who have shown a natural excitement and interest in the project is a good way to infuse UAT with some positive morale and perspectives. This group can help keep your UAT moving because they want to be in there running tests. Some of them may not grant the solution an easy pass, but they may approach UAT with a sense of exploration and with less hesitation, which makes them a likely source of some surprise tests/results as they are playing with their new toy. Their excitement can infuse UAT with some positivity and fun.
- Doubtful Users – these are the users who we know are going to be hard to win over. Everyone’s reason is different and some are good-natured while others are decidedly less-so. While the knee-jerk reaction is to keep them as far away from UAT as possible, they can enhance UAT as long as they aren’t an unchecked source of negativity and misconception. Some of the heaviest testing can come from a doubtful user who is engaged in the goal of showing me exactly why my solution is not going to work for them. Their immediate feedback may be a good indicator of what you’ll see from other Doubtful Users when the solution is released, which is valuable for Change Management. Those that can get to a point of acceptance/satisfaction by the end of the UAT cycle can also end up acting as an accelerating agent for gaining acceptance from all users.
- New or Timid Users – having some testers who are new to the process in general (new hires) or who fear they won’t be able to keep up are important for getting some feedback around the simplicity of the solution. Most of the other users are focused on the things their experience tells them to look for while this group is just trying to get their bearings. They offer feedback on where we may have designed something with the unintentional expectation that a user would know something that they may not.
- Advanced Users – these are the testers who seem to know their processes and systems very well and are looking to see what sort of mileage they can get out of the solution. They will generally want to know every detail of every function so that they can fully understand the tools they have and start incorporating it into the rest of their processes. Advanced test cases are usually conceived and run by these testers which gives us a look into areas that may need to be strengthened either before release, or in a future phase. The testers from this group can also have a good impact on the acceptance of the solution by the masses, especially if they are looked to for help and guidance by their teams.
Prepare the Testers
The most involved testers seem to come from UATs where they are given the chance to understand the solution and the importance of incorporating their experience into UAT. Running a pre-UAT Demo and Q/A session in the weeks leading up to UAT will give the testers exposure to the solutions they will be testing and gives their minds a chance to engage with that challenge of ensuring the solution actually works for their needs. When I am in the role of a UAT tester, that little bit of preparation hugely increases the amount of confidence I feel toward my testing, which gives me the ability to really push and explore the edges of the solution. That is when meaningful tests and feedback really start coming in.
It’s also the best time to make sure everyone knows what the goals of the project/solution are. While that’s not necessarily going to stop stray feedback from coming in, it will help everyone understand what they’re supposed to be looking for and gives them the chance to sort out what sort of feedback is going to be the most helpful and accepted.
Utilize Their Experience
We run the risk of alienating the UAT Testers from really understanding what they are doing/testing when we simply hand them scripts to follow step-by-step. (Though I’ll note here that test scripts can be helpful in warming up testers, especially those who are new or a bit apprehensive about how to really use the tool.) At this point in the project, we have already had phases to test the designed and coded functionality and we really need to see if the solution will work in the UAT Tester’s everyday world.
If testers are given an early understanding of what they’ll be doing, they can prepare for UAT by noting/copying examples from their daily work to use as the bulk of their test scenarios for UAT. These are a good counterpart to scripted tests that are written to pass. It ensures real-world examples are able to be handled by the solution as intended. Prep is important here because, without an understanding of the solution, they may show up without the right variety of examples.
Guide Their Perspective
When we are in the role of a tester, we don’t always know what we should and should not worry about. We worry about everything. We’re given the task and responsibility of making sure a solution fits our needs and sometimes we feel a pressure to catch everything we possibly can. We probably weren’t involved in the full solution design and only have whatever knowledge was given to us in preparation.
As project members running UAT, we can do a lot to help guide a tester’s understanding of what they are seeing and how to interpret it, which can hugely influence their perspective. The step of Preparing the Testers can help them dig into UAT armed with information on what to expect as well as an understanding of what the project’s goals are. During UAT, we are the ones who need to keep those goals in everyone’s scope. If we can frame responses to their feedback in the context of the project’s goals, we can help the testers understand when certain requests are outside of the scope of those goals and help them to see when a solution has met its goals successfully.
While there are a lot of other things we can do to make UAT successful and meaningful, these are some of the things that are focused on helping the testers get “in the zone” with their testing so that they can give the sort of feedback that eventually shows us, and them, that they accept the solution. The feedback we need in order to close out UAT with our goals met and with the excitement of its impending release to others.
