There’s a common challenge in QA: ubiquitous terms that everyone assumes they understand, but that often lack a universal definition. User Acceptance Testing (UAT) is one of those terms. It frequently leads to confusion—what exactly is UAT? Is it simply Acceptance Testing with a user-focused approach, or is it an entirely separate step in the testing lifecycle? And, more importantly, why does it matter?
The Current State of UAT
Functionize notes: "With UAT, the aim is to test whether your new product delivers value for its users." Which is super important, and honestly should be more emphasized throughout all development and testing. But the confusion comes in as to where UAT fits in the test lifecycle.
Many organizations, Marker.io included, argue that "it is the final testing stage, so your product will already have been tested for bugs." They push for having "actual" or "ideal" users test your app in a production-like environment.
Here's Why That's a Problem
We absolutely agree that testing the application in a prod-like environment through the user's lens is essential before release. But here's where we don’t agree with this understanding of UAT: waiting until the last minute to center the user's experience is honestly a waste of time and money.
Let's be clear about something:
We're not saying end users' feedback should be ignored during development
We're saying that if you wait until the last second to consider the user's experience, you've already failed
You're burning money and time you don't need to burn
The Real Cost of Late-Stage UAT
Let's look at some hard numbers:
According to IBM, fixing a bug after release costs up to 15 times more than fixing it during the design phase
The Systems Sciences Institute at IBM found that the cost to fix an error found after product release was 4 to 5 times higher than during design and up to 100 times more in the maintenance phase.
A study by the University of Cambridge found that the global cost of debugging software has risen to $312 billion annually
Industry research shows that companies spend about 50% of their project time on avoidable rework.
Breaking this down to real money:
A bug that costs $100 to fix in development
Costs $1,500 to fix after release
And potentially costs $15,000 in lost customer confidence and brand damage
Here’s the reality:
We're not saying end users' feedback should be ignored during development
We're saying that if you wait until the last second to consider the user's experience, you've already failed
You're burning money and time you don't need to burn
The Lyon Perspective: Earlier is Better
At Lyon, we've got a different take: User Acceptance Testing shouldn't be your final testing before release. Instead, it needs to be baked into your QA processes from the beginning.
Our argument: Why split testing into separate stages of functional verification and UAT when you could...
Validate that new functionality meets acceptance criteria
Ensure it's intuitive for end users
Do both of these things simultaneously, as early as possible
Thus saving development time and money
The Data Backs Us Up
As the DORA report emphasizes, "User-centricity drives performance. Organizations that prioritize the end user experience produce higher quality products." That's why we incorporate "user" testing in everything we do, right from the start.
A Reality Check from the Field
Randall Rice from PractiTest notes: "I often say that user acceptance testing is one of the most valuable levels of testing, but often performed at the worst possible time. That is because if process gaps or other major flaws are discovered in UAT testing, there is little time to fix them before release. Also, the options available to fix late-stage defects may be very limited at the end of a project."
An Important Call out: Your Users Aren't Your QA Team
While we're challenging the typical UAT timing, let's also be clear about something else: your end users shouldn't be responsible for testing your software. Yes, you absolutely need a formal process for user feedback. Yes, that feedback is crucial. But no, your users shouldn't be your bug hunters.
Why not? Because:
Users aren't trained QA professionals
They don't have deep testing knowledge
They shouldn't be your first line of defense against bugs
They deserve a polished product, not an almost there product
The Bottom Line
Want to do UAT right? Stop treating it like a final checkbox and start integrating it into your entire testing process. Your users – and your bottom line – will thank you for it.
Comments