Introduction to User Acceptance Testing (UAT)

If we are testing new software, as a techie we will inevitably not make stupid mistakes or wrong turns (keeping with the home town analogy). In fact, even before we sit down in front of the new application, we’ll have a good idea of how it is supposed to work and what we need to test. We’ll jump ahead to screen 3, enter generic data in the required fields and without bothering to read the small text at the bottom of the screen, we’ll click next and continue on till the test is finished. Essentially, we’ll go from A to B to C, then click Next and wait patiently until the next page loads. Most users don’t work this way.

They may start at A but then scroll down to D and over to E and put some incorrect text in field H before filling in B. They’ll get lost somewhere around K and l, before finding their way back to C. When they do finally click Next and nothing immediately happens, they’ll click it another 5 times in rapid succession, smashing their finger down harder onto the mouse button with each press.

When a user launches an app they’ve never used before, it is like you or me driving into a city we’ve never been to, with only a vague set of directions written on our sweaty palm and no Sat Nav.

Even when we think the directions we’ve put on the forms are clear and obvious, people will still get it wrong. Like street signs pointing to the nearest car park. To someone living in the city, the location is obvious. But, to someone visiting the city for the first time, navigating and driving, while trying not to hit the old lady at the crosswalk or stall on a steep hill; finding the car park...well, it’s often more than users are equipped to deal with.

The other problem users face is when the software isn’t robust enough to cope with the information entered, assuming they’ve entered the information correctly (which is always a 50/50 chance).

Let’s suppose you have two fields: First Name & Surname. Because you are using a script to test this app, you code in ‘John’ & ‘Smith’ as the person’s name. Here I am thinking: "Awesome, fantastic. It’s going to work a treat."

However, what if your name has some funny characters in it, like Renée? I cannot count the number of newsletters I’ve received addressed to Renée because the subscription form wasn’t tested for letters like é or the surname is double-barrelled like Hatfield-Rose. This is the human element, which is often difficult, if not impossible, to predict. But that doesn’t mean we shouldn’t try.

This isn’t about “dumbing down” your application. But rather, understanding who is going to use it and how. Then designing tests appropriate to that market. It’s remembering that the left-turn down Maple Street to avoid a busy junction seems obvious to you but will be totally lost on a first-time visitor to your city.

I’m currently in the middle of a conversation with an application company, trying to get them to understand that not everyone in the world writes their dates in a Month Day Year format and that not all phone numbers are structured as 123-456-7890. They have produced an international product, designed and tested only for Americans. Clearly, the designers and testers of their forms did not understand their international customer base.

This is the approach, as testers, that we must always have in the forefront of our minds. Who are the end users?

It’s not only easy for us to get caught up in the technical aspects of testing, it is our nature as techies to do so. But we must remember that the people we are testing the software for, aren’t techies. In fact, they are strangers to our town and part of our job is to keep them from getting lost.