The reality is that things are never that simple.
And one of the hardest parts of any project is knowing when a project or launch is done.
That’s why it’s important that every single person involved in any project or implementation has the same definition of Quality Assurance Testing (QAT) and User Acceptance Testing (UAT). A shared understanding is the only way to ensure the process goes smoothly and that everyone—whether a client or an agency employee—is on the same page in terms of what “done” means. This not only reduces stress, it produces a better end product.
In our experience, many people use QAT and UAT interchangeably, even though they are different. Both terms were originally used in software development and then filtered out into other applications, which is one reason the terms got fuzzier.
In fact, we used to use these terms semi-interchangeably at Lift until relatively recently. However, as we started to do more and more integrations, product development, and implementations, we realized we had to get our ducks in a row and better define these terms. In fact, my COO Jess and I had a spirited discussion about it on The RevOps Podcast recently. (Then again, spirited discussions are kind of our thing.)
After the podcast, we decided to put together a blog post to help define QAT vs. UAT. So let’s get started!
QAT can be a confusing term because it’s often used as an umbrella for the entire testing process and for internal testing by the agency—and both usages are correct.
QAT kicks off when an agency believes a build or integration has been completed according to the build map. In this stage, agency employees test defined scenarios based on the business requirements.
In each scenario, employees are testing to see if the build meets the requirements and functions as specified. Any testing scenarios that don’t meet requirements are revised until the functionality passes. When all testing scenarios are completed and the result meets standards, the implementation is deemed complete, at least internally. Once all scenarios are executed satisfactorily in QAT, the project moves on to UAT.
UAT is user acceptance testing, aka testing performed by the client to ensure that the build meets the business requirements created at the beginning of the project. When a project reaches this stage, it’s already “passed” QAT done by the agency. UAT is a sort of final check by the client and is a subset of overall quality assurance testing.
In other words, UAT allows the client to know that the project does what it was specified to do.
Please note that this doesn’t mean that everything is “perfect.” It means that the implementation or build meets the original business requirements and functions correctly. If it doesn’t do something that wasn’t originally specified but is now deemed necessary, that would become part of the next iteration.
Although it sounds counterintuitive because it’s the final step before launch, UAT is based on the beginning of the process. It tests that the client’s choices, which were articulated in the business requirements and the build map, have been successfully executed.
At Lift, we like to think of the foundation for QAT as “the three Bs”: blue work, brief, and build. The more time spent on blue work, the faster the launch tends to be. That’s because the client and agency create a build map as a comprehensive blueprint, as opposed to going back and trying to “fix” things they didn’t think of originally—which means a never-ending, unsuccessful project.
With that in mind, we put together the QAT/UAT questions Lift tends to hear the most:
A. In our opinion, there can be up to 3 “levels” of UAT:
In all three cases, the tester will be working from specific use cases; this will be the case whether they were intimately involved with the project or are learning about it for the first time.
A. We believe there should be two stages of system walk-throughs:
1) The agency will take clients through a highly configured, but not yet fully built demo, to show them how the final product should work.
2) Just before UAT is scheduled, the agency should take users through the UAT requirements and process to create familiarity and comfort with the steps.
Some clients think they don’t need UAT training because they are transitioning from another CRM system, but any testing participants need to be clear about how UAT should work. It’s an important part of the process and should not be skipped.
A. UAT passes or fails. If an item fails and it was part of the specs, then it’s fixed. The fix then goes through QAT and UAT.
A. For the most part, yes. However, what’s being tested may vary, depending on the build. Regardless, your agency should supply clear use cases, checklists, and scenarios of what’s being tested, depending on the type of UAT.
There are primarily 2 types of testing:
A. If this issue is with something that was in the requirements spec, it’s fixed and that item goes through UAT and QAT until it is corrected and passes both. If the issue is with something that’s not in the spec, then it is an iteration for future builds that occur after the launch.
Testing is the final step, but it’s a vitally important one. It must be aligned with the choices you made back in the beginning, when business requirements were outlined. If it’s misaligned, you’re back to building what we call a “Frankenstein system” that cobbles pieces together instead of adhering to a strategy. That’s why 70-80% of implementations fail.
We hope this cleared up why the definitions of QAT and UAT are so important. Every project needs an “end,” which means defining what meets requirements. Again, ensuring that everything you want for launch is defined in the requirements and build map is the key to happiness, so it’s important not to rush through that part of the process. You’ll save time in the long run and QAT and UAT will be much smoother!