5 Tips On How To Be a User-Friendly QA Specialist

When delivering a final product, you might find yourself facing a tight deadline. The project has to meet certain specifications and the client’s requirements, and it needs to be free of bugs. In the midst of all that, end users are often forgotten.

Users are going to have a bad time using your product if their needs are not taken into account during the development phase. This can, in turn, result in a product that is difficult to use and prone to human error. People tend to blame themselves for obstacles and errors they encounter using a product. This is quite unfortunate but mostly avoidable. See how you can avoid it.

Error-proof forms and validations

I am sure that from time to time everyone makes an error when typing in a password or completing any other input either on mobile or the web. Why does it happen? It is often caused by bad design. When testing a form, you should not only think about functionalities but about also its usability. How is one different from the other?

Imagine that a simple registration form is to be tested, and it consists of:

• A Name & Surname field

• Password/Confirmation Password fields

• An E-mail Address field

When testing it functionally, a QA specialist will always focus on following:

• Are all fields validated?

• Does the user have to fill all of them when submitting a form?

• Are correct errors displayed?

Everything mentioned above must always be taken into account when testing, but there are other aspects that tend to get lost in the process. In order to see them, you need to empathise with the user. The example on the right is better, because it clearly shows what to type into the fields by giving hints to users. When a user sees an example, he or she doesn't have to think about it too much. Everything is clear, and the user does not have to ask herself or himself What kind of password should I type in? or How do I put my name in this field? Forgetting to include hints might seem like a minor annoyance, but it can make a massive difference in terms of converting users.

Follow the design conventions

When creating a game-changing product, you can quickly jump to a conclusion that standing out from the crowd is all about ditching conventions. Not true. Conventions do not exist to constrain your creativity or your options. They exist because people get used to things. For instance, Google made its own style guide – Material Design. Material Design is very useful when designing Android apps, but it also contains some design rules that apply not only to Android. The guide’s purpose is to help designers, developers and testers create integral and usable apps. When appropriate conventions/guidelines are not taken into account in design process, a bad experience occurs.

What’s wrong with the example on the left? It lacks consistency. Conventions are all about consistency. If I were given such a form to test, I would reject it on the grounds of the lack of integrity and low readability. In contrast, the example on the right follows a pattern and gives user hints. It is also more readable. Why? People read from left to right, which is natural in cultures using the Latin script or the Cyrillic script. In other cultures, this trend is reversed, because people read from right to left (take Arabic, for instance).

Make sure that the product you are working on uses solutions that work. Obviously, conventions can be broken, but it should not happen all that often in interface design, and if it does happen, there must always be a good reason for it.

When testing, keep in mind your users’ goals

Each time someone launches the app you worked on, he or she has a goal in mind. For instance, someone is about to launch Ubereats. This person is definitely hungry and probably in a rush. Have you ever considered such goals when testing an app? Probably once or twice, but I, for example, did not do it very often in the past. I have come up with a little framework of my own which helps me think of users’ goals.

It all starts with circumstances, which can involve the device, demography, marketplace and many more external factors. By external factors, I mean factors that can have an impact on how the user will interact with the app and are not app-related. Then there are possibilities, which arise when the user opens the app and wants to achieve some goal (tech-related, how the app works, the user experience it offers and so on). Obstacles should play a vital role in testing cycles. Why? Imagine that you go to a sneaker store. You have spotted a model that you really like, and you try it on. It fits perfectly, and the price is reasonable. You are about to buy it, but then the sales assistant lets you know that there is only one shoe of that pair and the other one is lost. I am sure you would never come back to the store. Remember to take into account all the items from the above pyramid when testing products.

Remember to think about affordances

Affordances? What are they? For instance, a chair’s affordance its capability to let you sit on it (comfortably). In other words, a chair affords you the option of sitting. You can easily know that you can sit on a chair, because chairs clearly communicate it with their design. The same applies to digital products – elements such as buttons, inputs, or select lists must have an obvious purpose. If someone does not know how to interact with a particular item, he or she will not click on it.

Why did I choose the button on the right as a good example? It simply stands out more. Its affordance is that it can be clicked on, and it invites me to click on it because of what it looks like. A proper contrast ratio between the element and background is maintained. The left one lacks contrast and, consequently, does not stand out, which makes it barely visible against its background.

Do some field testing

Imagine that you are responsible for testing an app for renting city bikes. This app lets you buy subscriptions and rent bikes from stations located around the city. It runs both on iOS and Android.

It is quite unlikely that users will use it:

• From the office

• From home

Instead, they will use it:

• On crowded buses

• On the go

• With high-latency networks

• Running lots of different apps in background

You cannot achieve real-life scenarios sitting in your cosy office, because most of the scenarios are circumstantial. What did I do knowing all that when testing an app for renting bikes?

Once a week, I left the office earlier and pretended that I was using this app in the real world. I did not use strict scenarios. I acted naturally – as if I were using the real thing. When I was testing it this way, a few things occurred to me:

• The app crashed when there were a lot of concurrent processes running (Facebook app, internet browser, email client)

• The app worked inefficiently on high-latency networks, it often returned network errors on a high-latency 3G but did not on a 4G or WiFi

• The app’s performance was poor during phone calls

To sum up, when testing an application in its development phase, you can sometimes forget about user-centered design. You can be accustomed to following guidelines, specifications and technical requirements, but still might not think in broader terms – in terms of usage context. Why is it so important? Because this is why some products succeed and others do not. In my work, when a product succeeds owing to my team’s contributions, I feel satisfied and accomplished.

Reference:

Don Norman, The Design of Everyday Things, Basic Books 2013.

Preventing User Errors: Avoiding Conscious Mistakes by Page Laubheimer.