Everything You Ever Wanted to Know About QAT vs. UAT

We have a joke around the Lift Enablement virtual office: The four “words of death” for a project are “All we need is…”

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!

What is QAT?

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.

What is 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. 

How does the UAT process work?

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:

Q. How should the UAT process work?

• The agency creates a testing plan based on the agreed-upon business requirements/build map; the client signs off on the plan.
• The agency trains client participants on how to test. (We’ll dive deeper into this process down below.)
• The client uses the test cases to see if the product meets the requirements.
• Any errors that don’t meet requirements will be fixed.
• Any “fail” that is not in the spec is an enhancement for a future iteration.
• If the project meets requirements and is approved by the client, it’s production time!

Q. What client-side roles should take part in UAT?

A. In our opinion, there can be up to 3 “levels” of UAT:

• Level 1: The person or people you worked with. They are approaching testing with full knowledge of the requirements and build map. This is a useful viewpoint but they’re also approaching testing with full knowledge of how things should work, so it’s an insider’s perspective.
• Level 2: The sales lead. This role may or may not have been involved in the requirements and the build, but they have a sense of the expectations.
• Level 3: A salesperson who has been briefed about what to test. This is an outsider’s perspective, which is also useful, but they may also bring a laundry list of things that can be “better”—which is fine, but unless they don’t meet the specs, those changes will be for a future iteration.

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.

Q. How should client-side users be trained for UAT?

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.

Q. How many rounds of UAT should there be?

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.

Q. Is all UAT handled the same way?

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:

• Feature UAT - If you are testing a feature, your agency should supply you with checklists and test logging to see if it works to spec. 
• Use UAT - User gets use cases agreed upon before testing and works through them. Feature checklists are not as useful here.

Q. What if something isn’t working?

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!