A well respected friend of mine compares User Acceptance Testing (UAT) to putting up wallpaper while the plasterer is still plastering the walls.
As a specialist in implementing large CRM (customer relationship management) systems Richard has been through his fair share of user acceptance testing. He says the UAT testing phase usually gets dispensed with when the supplier finds themselves under time or budget pressure. As a result the customer effectively gets landed with the suppliers testing responsibilities, or at worse, ends up testing something that’s effectively still in development. Simply put the test team are wallpapering whilst the developers are still putting the plaster on the walls.
Adding to the pressure is the obvious fact that UAT is the final step before go live. So in many projects everything gets lined up for the live date with little scope to move dates. And guess who bears the brunt of this. The test team yet again who generally end up dispensing with life’s luxuries such as sleep.
All the books say that what is supposed to happen is that development is completed and a rigorously tested system is delivered to UAT. UAT is then just a question of putting a series of ticks in boxes in front of the customer.
What happens though is that a clam tick the box activity is turned into the most stressful phase of the whole project. Deadlines loom. Contract commitments get stretched. Testers and developers work all hours.
The onus is on the test team to act as the thermometer. Is the evidence from your early testing looking bad? The sooner you demonstrate this, the sooner people can consider the implications on the UAT phase. You’re not trying to depress people here. You just need to tell the rest of the project team how it is.
If you don’t think the software is ready for UAT you need evidence to show that it it won’t be. A track record of high priority bugs raised over the duration of the project is a good start. Explaining how embarrassing it would be for the customer to see a bug during UAT tends to hit home harder.
You could just say we’ve got 3 blocker bugs stopping us from going into UAT. Alternatively you could paint a picture. If we go into UAT, and we test feature X in front of the customer, then he’s going to see Y. And that’s going to make us look pretty stupid. Perhaps we should put back the UAT? We need time to resolve this. Then when we run through these UAT tests we’ll look like the professionals we really are. Okay, I’m stretching it a bit here but you get the idea.
Putting back UAT and delivery deadlines is never a comfortable discussion to have with the customer. In my experience you are better off having one difficult discussion before the UAT starts, rather than several very difficult discussions with the customer during UAT.
Maybe we’ll never reach the utopia of completing development and delivering a rigorously tested system to UAT. As testers, part of our remit is to let everyone know how likely we are to have a successful UAT phase. This process of telling it like it is, keeps the whole team focused on what really matters. And what really matters is the customer.
For the customer it’s about finding that balance between delivering the features, to an acceptable level of quality, within the time frame. A sort of ‘the plaster still needs a bit of drying time but we should be okay hanging the wallpaper anyway’ approach.