Why UAT hurts and what good actually looks like

This is the first in a series exploring why UAT is one of the most consistently painful phases in retail technology programmes, and what it looks like when it's done properly.

Later articles will go deeper on agile acceptance, the change champion model in practice, and how automation can transform UAT preparation.

Don't want to miss them? Sign up to our monthly ctrl freaks email.

If you've run a large retail technology programme, you know the feeling. UAT is on the plan, the dates are in the diary. And then, somewhere around week two, the wheels come off.

Key colleagues are pulled away from their day-to-day roles to test. The programme manager is fielding calls about defects that should have been found months ago. And now you're having the conversation about extending. Again.

This is almost entirely predictable. And UAT fails for the same reasons, on programme after programme.

Here's what's actually going on.

UAT is being asked to do the wrong job

Business users are brought in at the end of the cycle and asked to repeat work that should already have been done. They end up re-running system testing rather than answering the one question UAT actually exists to answer: can I do my job in this system?

The merchandiser, the finance analyst, the customer service manager. They are not professional testers. They're there to confirm the system works for them, in their world. When they walk in and find a broken system, the damage goes beyond the defect log. Trust erodes. And recovering that trust, even after every technical issue is resolved, is harder than the fix itself.

There's a broader point here too. UAT is not free. Every senior person sitting in a UAT room is not doing their actual job. If UAT overruns (and it frequently does) you get a double hit: the programme isn't progressing and the business is running at reduced capacity.

Getting UAT done in the right amount of time is a business efficiency question as much as a testing one.

"Done to them, not with them"

When working with one client during a significant technology implementation, the accounts team came into UAT with almost no involvement in the programme beforehand. They hadn't been trained and they had no context for what they were accepting.

The programme was delayed significantly. This isn't unusual and UAT failure is very often a change management failure. The fix starts in the months before UAT, with early engagement, meaningful training, and clear communication about what's coming and why.

We'll cover this in more detail in a future article.

If your users are finding fundamental failures, testing has already broken down

UAT should never be system testing in disguise. And yet, sometimes, this is exactly what happens.

When business users walk into sessions and find core journeys that don't work, it's because the professional testing phases haven't done their job. And when the delivery team and the system integrator are marking their own homework, that happens more often than it should.

System testing, SIT, end-to-end exist precisely so that business users never face a broken system on day one. UAT is the final confirmation, not the safety net for insufficient upstream testing.

Preparation is the difference between two weeks and two months

Two of the most overlooked contributors to UAT overruns are data and environment readiness.

Business users shouldn't arrive and spend the first morning keying in orders just to generate the data they need. Automated data packs, run overnight, mean users walk in on day one to a populated, realistic environment. The environment itself also needs to be closer to production than anything used earlier in the cycle. Planning for that cost from the start of the programme, rather than as an afterthought, matters.

The preparation before UAT starts is often the difference between a clean acceptance phase and a month of overruns. It is plannable. It's also where professional testing support adds clear, concrete value, and where the question of what "good enough" actually means for a go-live decision gets its proper answer.

What UAT should actually feel like

Done well, UAT is not a weeks-long drain on the business. Business users arrive to a working system with realistic data. They've been involved in the programme, trained on the system, and told what to expect.

Credible change champions in the room manage feedback in both directions, as ASOS demonstrated during a major Oracle Retail implementation for thousands of merchandisers.

Their job, when they sit down, is to confirm one thing: can I do my job in this system?

The alternative to painful UAT is smarter UAT: professional testing done properly upstream, environments and data prepared in advance, and business users who arrive ready to accept rather than discover.

That's the model and the rest of this series will show you how to build it.

Next in the series: Agile UAT: how to break acceptance into functional slices instead of waiting for a big-bang phase.

Sign up to our monthly ctrl freaks emails to make sure you don't miss it.