<img alt="" src="https://secure.wauk1care.com/164394.png" style="display:none;">

UAT Testing Steps - Do you Test like a User?

Posted by Renée Elizabeth Mineart on 15/01/2019

Introduction to User Acceptance Testing (UAT)

If we were to visit the town where I grew up, I could take you to any place in that town without having to use Sat Nav. I wouldn’t even have to glance at Google Maps to find my way.

Copy of LinkedIn Post _white (2)

You can probably say the same about where you grew up. However, if you hop in my car and we go to a city I’ve never been to before, then I’m going to need some help. Sat Nav, Google Maps, directions, post code…and still, there’s a chance I’ll make a wrong turn along the way.

As techies, we have an innate understanding of how computers and applications work. First, we need to consider the UAT testing steps. Why? Because software is like the town we grew up in, we understand it. We get it. We don’t get lost. Although, users like strangers to our town, often do get lost.

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&eacute;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.

Mobile and UAT Case Study

Topics: Software Testing, User Acceptance Testing, UAT

nFocus Blog

Welcome to the nFocus software testing blog. As thought leaders and technical innovators, we created this blog to distil our thoughts, ideas and musings on improving software quality.

Fill out the form below to receive future communications from nFocus including our latest:

  • Blog articles
  • White Papers
  • and plenty more!

Follow us

Follow us on LinkedIn to see our latest content!

Subscribe Here!

Recent Posts

Posts by Topic

see all

Posts by Topic

see all