Why is UAT Important?

User Acceptance Testing (UAT) is a vital step in the successful release of any new software. But why? Why is this one stage so important?

I live in the far back corner of a housing estate situated behind another housing estate. If I want to go into the city near where I live, I have to drive through both housing estates and no matter which way I go, I have to drive over at least eight speed bumps.

The other day as I was making a run to the store for some essential items, I started thinking about these many speed bumps and why we have to have them. It occurred to me that if everyone drove the posted speed limit, there would be no need, whatsoever, to have speed bumps. Speed bumps are there to do one job; to force faster drivers to drive the speed limit.

If there is a 20 mph speed zone in front of a school and every human being that drove past that school drove no faster than 20 mph, there would be no need for speed bumps outside that school. Wouldn’t that be awesome?!

But, unfortunately not everyone adheres to the posted speed limit and as a result, we all have to slow down for speed bumps or risk bottoming out our car.

It’s a similar situation when creating and releasing software.

As a software designer, I know what my code is supposed to accomplish. I’ve designed it to do a specific task, I know the information it requires to run smoothly and in what format that information needs to be. When I do my own testing of my software, I enter the information sequentially from the top down. I fill in all mandatory and optional fields with preselected data that I know will work. In other words, I obey the speed limit and follow the rules of the form.

Although not everyone will use my software that way. Let’s say I’m developing a website designed to gather some information about a customer. I design a form and publish it. I’ve tested it, and it all functions as expected. However, there are many, many variables that I haven’t tested that a customer might try, which might cause an error. Variables that may not have even occur to me.

I don’t have dyslexia nor am I colour blind, for example. So, the small print on part of the form doesn’t bother me, and the red outlines indicating a mandatory field are clear to me. Even so, some of my customers may struggle with both of these design choices. In fact, one of my team members places a thin, light blue sheet in front of her monitor because it helps with her dyslexia. As a website designer, should I be taking this into consideration when designing the colours and selecting the font for my site? Absolutely! However, that thought would never have occurred to me if I didn’t work with a person who has dyslexia.

When I test my site, I enter the data top to bottom because I know what data I need and I have it all to hand (or make up random words as I go along). Real customer might complete part of the form, then need to go and find their debit card before completing the rest of the form. What happens if they don’t fill in that box and try to click ‘submit’? What happens if they are away from the computer long enough that the site times out or their screen saver kicks in. Whatever happens, is the result user friendly?

This is why we do UAT. The more people we have attempting to break our software, the more robust we can make it before it goes live.

There is a saying I’ve heard more than once in the developer world. It goes, ‘as soon as you make your software idiot proof, nature produces a better idiot’. I don’t mean for that to be offensive, I’m not calling people idiots, but what I’m trying to say and what this not very PC statement is saying, is that no matter how much testing you do to make something super-duper-user-friendly, someone will do something that never occurred to you… and break it.

The goal of UAT is to find those things that never crossed our developer-mind because we know how it is supposed to work. In other words, we not only know why there is a speed limit and are happy to drive it, we created the speed limit and are baffled when people drive faster than they should. As a result, we have to build speed bumps to force people to follow the rules.

I think of speed bumps as a patch applied to poorly UAT’ed roads.

You don’t want to have to put speed bumps in your website, you don’t want to force people to enter data in a certain way. Rather, you want to understand how people enter data and make the site flexible and friendly for them. This is what UAT accomplishes.

Going back a few decades, when I was at university, they had built a new building on campus. For three months after the building was finished, they didn’t put down any pavements outside connecting the building to other buildings and the rest of the campus. Rather, they just let the students walk on the freshly laid grass. After a while, several paths of worn down grass became apparent and the contractors returned to site and made these paths of trodden down grass pavements. They effectively User Acceptance Tested the best, most used routes to the building and then made them into paths.

That’s what you want to accomplish with your software.

Now, if I can only figure out a way to get civil engineers to UAT roads and design them in such a way to not require speed bumps, I’d be a happy developer!