UAT: Essential And Terrifying

August 21, 2019

"Why do we need User Acceptance Testing?...Are we paying for that?"...this is something we get asked all the time. For those in the know, the answer is of course "yes!", but if you aren't au fait with Quality Management or what it takes to make your custom systems as effective as they are, it's a good question and we're delighted you ask.

This question is an ever evolving challenge and a powerful reminder for everyone at Etain that we live and die by the quality of our Smarter Software ® so we thought it was about time we let Bob (Quality Manager and Jurassic Park afficianado) loose on the blog and bring you up to speed.

“We Have lift Off…”

There always comes a moment when all the hard work you put in gets put to the test.

Athletes who have gotten up to train at 6:00 AM every day for one shot at Olympic Gold eventually find themselves at the starting line…

Students who stayed up until 6:00 AM the night before their big exam eventually find themselves turning over their papers…

Astronauts who have trained for 6 years to join the tiny number of humans who have been to space eventually find themselves counting down to launch…

And software testers, who have spent 6 weeks running internal tests eventually find themselves at the start of UAT.

User Acceptance Testing (UAT) is when we work with our clients to help them check their software solution does what they want it to do. The aim is to reach sign-off - when we can celebrate a job well done and the client can get on with their delivering to their clients using the sleek, new system we delivered.

The start of UAT is when the client can finally get to play with the product they have only read documents about or seen wireframes of. Much like waiting for something to arrive having ordered it online however, this process carries a fundamental risk...

“This isn’t what we asked for!”

We always run the risk of ending up building something that is different from the client’s original vision because at each stage of the lifecycle different parts of the development team bring their own styles and preferences to the table.

While increasingly agile methodologies massively reduce this risk by allowing the client to see the product while it is being made, bit by bit, each stage of this process still contains the possibility of being told by the client that that “this isn’t what we asked for!”

When the client signs-off on a functional specification they have a vision in their minds of how it will turn out. Consider a movie based on your favorite book. It usually isn’t as good, right? This is because when you read a novel you generate a specific vision in your mind of what it 'looks like.' Both the author and each reader of the book have a vision like this but they’re never the same. When we’re confronted with the other person’s vision of the same material, the differences can be shocking.

Take Jurassic Park. Jurassic Park is a masterpiece by Steven Spielberg but it is not Michael Crichton’s book. Huge sections are missing. (Alan Grant should have a beard but Sam Neill definitely doesn’t have a beard, I don’t even know what they were thinking. They didn’t even glue one on.)

Jurassic Park is still amazing and everyone involved should be proud, but if you read the book 10 times before seeing the movie it’s not your Jurassic Park. It is a matter of interpretation.

To compound this problem a novel is also the artistic vision of an individual. An editor will edit and suggest improvements (and a good author will accept these suggestions) but it is the author’s book. The author has a vision in his head and he puts it down on paper.

Professional computer software hasn’t been made like this in a long time. Nowadays, software solutions are made by committee, like the movie adaptation of the book. Every part is brought together by different people.

Steven Spielberg is a genius filmmaker but he can’t animate dinosaurs. It wouldn’t be the same movie if the special effects team was rubbish right? Even if Spielberg did do pretty well with the terrible rubber shark in Jaws, Jurassic Park relies on awesome dinosaurs effects.

When they started pre-production on Jurassic Park they were actually thinking about stop-motion dinosaur movement. Like Wallace and Gromit or Nightmare Before Christmas and all the old monster movies (google it, footage exists.) At some point, someone floated the CGI idea.

“Hey! Maybe we can try using computers to do this instead! Could that work?!”

Michael Crichton had a vision for Jurassic Park. Steven Spielberg had a vision for bringing Crichton’s vision to life. The special effects team had competing visions for how to bring to life Spielberg’s vision of Crichton’s vision.

You can see where I’m going with this…

Managers have to deliver a product in a specific time for a specific amount of money. Business Analysts have to write specifications according to their best analysis of what the client wants.Designers have to make the best looking and most user-friendly product. Developers have to build the product according to a technical specification and make the product work. They have to fix bugs. Sometimes they have to learn new skills and this introduces bugs in and of itself.

Between conception and the time it takes to bring it to life, a software solution can change in unexpected ways, in unnoticed ways, in unintended ways. Even when everyone on board is trying their best to realize the client’s request.

Why UAT is Terrifying

UAT is the release of the movie adaptation of the book.

Some people are happy to accept differences that creep in. Some people reject it outright. I’m a massive nerd and have the sort of friends who complained about the size of furniture in The Lord of the Rings in relation to the hobbits. It sounds ridiculous I know, I mean - it’s furniture, it isn’t even a beard.

Usually, It’s not that anyone is wrong. It’s just that the aggregate of everyone’s approach to fulfilling the request isn’t the same as the request.

In order to keep disappointment to a minimum, in order to increase the client’s satisfaction with the finished product, it has to be someone’s job to try and keep everyone aiming toward the same thing – an 'as faithful as possible' reproduction of the client’s expectations.

Bearing in mind everything I’ve said so far, who wants this job?

A software tester, that’s who.

Having spent those 6 weeks before UAT running internal tests, making sure the software functions correctly, and looks right and most importantly, does what the client asks for – UAT is when the client gets to see the results of your effort. When the critics get to see the movie and offer their opinions.

Sink or swim time.

If everything goes well UAT bugs will be few, the client will be pleased, future work may lie in store.

If not, UAT represents a tactful mix of fixing things that are broken as quickly as possible (like giving the main character a beard) and defending improvements the client wasn’t previously aware of that the team discovered during development (liking using computers to animate the dinosaurs instead of using plasticine models) which sometimes means the final product is a little different to their original vision but often better.

Even if it’s a scary responsibility to pull off, the mission stays the same: Deliver the best quality software solution possible.