Nastya, our Senior QA Engineer and regular author, writes on how a tester can grow closer to a user for whom they actually test a product. What do Noveo QA-engineers like? Quality features, clean code, friendly teams and, of course, endless opportunities to grow! It is a fact that education is one of the most important parts of professional corporate life: going to conferences or watching streams, workshops, internship, meetups inspire and empower to introduce innovation in workplace.

For instance, what to do when the test cases are done, bugs reported and you know the specification like the back of your hand but still it seems as if something is missing? You need a fresh eye, better the one of a user. That is exactly what the last QA meetup was about, which had been inspired by the book "The Inmates are running the Asylum" by Alan Cooper.

How a tester can contribute to usability

A tester is an all-in-one unit of a project team, i.e. they are an authority on a project, a quality keeper and, moreover, they are the first to access an application so they can (even must!) find bugs before the actual users do.

To provide sufficient functionality test coverage we use different test-design techniques. They fall approximately into 3 levels:

• low level: equivalence classes, boundary value analysis;
• middle level: combinatorial techniques, domain analysis, pairwise;
• high level: state transition diagram, error-guessing, decision tree and use cases.

In usability testing we are more interested in use cases. They perfectly go with not only product functionality but also with usability. When a tester creates and runs these tests they manage to check the interface usability of an application but also to see if there are any previously undetected defects while imitating an actual user actions, the order of which is not clear from the specification.

A bit more about use cases

In order to create a use case a tester must understand the following:

• who the user is;
• what the purpose of the user is (why are they using the application?);
• what actions the user wants to accomplish (what they need to do to achieve the purpose);
• it is good to be able to prioritize use cases according to their aim and user features.

According to Alan Cooper a case is a brief description of the ways to use software to achieve goals. So cases act like some kind of a collective thing which includes several tasks.

What a tester must keep in mind when creating a use case?

1. The more detailed the information about a product is the more effective the cases are. So you should estimate how reasonable it is to create a test case right now: if there is enough data about the application in general? What are the odds of the use case you have created to scare away the QA team and to create a false impression of how the application must work? The risk must be taken into account.
2. A complete case is more important than an incomplete one with detailed steps. Since the main purpose of a case is to lead a user to the goal, completeness is one of the main requirements to a use case.
3. The cases which provide better understanding of a product and a user matter more than those which describe exceptional situations. It is quite an obvious statement but testers quite often mistakenly decide to focus more on checking exceptions (most likely negative) forgetting about how diverse typical positive user behaviour can be.
4. Copper describes 3 stages: a research, an interview and an actual observation. For testers they may be: getting to know a specification, a conversation with a customer and exploratory testing. The main thing is to get as much information about a product as possible - see paragraph 1.
5. When designing use cases it is worth keeping in mind that the goals are fixed but the tasks may vary over time. So one must be flexible and dare remove outdated tasks, add new ones but keep the goal.

Alan Cooper defines 3 types of cases:

• daily: they are done every day and several times a day. There are usually a few of them (2-3) they also often become routine and a user goes through them without giving it much thinking (for instance, for a tester it can be a bug report or a checklist design);
• mandatory: they are rare but regular, there are more of them than of the daily ones (for instance, a weekly report on testing, reporting hours to a time tracking system, test documentation update);
• exceptional: they are rare or even may never occur (speaking of testers again this can be an attempt to cancel the change in the production database if the change has been made by mistake). Only imagination is the limit to the amount of such cases. :)

During usability testing all the cases should be taken into account as each one includes unique actions which matter since they imitate an actual user.

Let’s look at a simple example of how to use a case: a mobile application for taxi service. We can assume the average user is 20-40 years old, they don’t like using public transportation and, most likely, they often get around not by their own car. Their goal is to get from A to B fast and comfortably. To gain this goal a user might have to go through the following steps:

• order a taxi to any location in the city;
• choose a pickup time;
• choose some properties (the type of a car; a luggage option, a silent driver etc.);
• check the rates;

and a lot more, it is up to the “user’s” imagination.

To successfully test the work of an application we must check the application properties listed in the specification but also try and become a user and look at the product as if we see it for the first time (though it doesn't make us want to gain the goal any less).

Personas and their motivation

However, if you think of it, the image of the user above is a little too abstract to design efficient cases for the user. For example, people aged 20 and 40 can have different opinions on the same technologies and something that is clear to some of them may cause difficulties to others. Moreover, some people value portliness and possibility to order a premium class car (for a business trip, for instance); others like instant pickup time, the rest, on the other hand, would like to be able to order a car in advance. How can you make use cases testing as efficient as possible and understand future users the best way?

Here a user’s profile or so called persona can come in handy.

A persona is a specific user image which helps to live user’s part and understand their needs. If we draw an analogy to OOP then a user is a class and a persona is its specimen.

Consider the following when creating a persona:

• age;
• occupation;
• social status (as a part of the product);
• preferences;
• factors determining interaction with the system;
• why they are using the application (the goal).

So instead of some man “20-40 years old without a car” we have a more common case of a possible user:

• Viktoria. 28 y.o.;
• a gym coach;
• uses the application to commute (as she mustn't be late) and to pick up her child from school in the evening;
• she can’t sometimes pick up her child from school on time so she asks her husband to do it;
• Victoria's husband works on a rotational basis that is why he is sometimes away and isn’t able to pick up the kids from school;
• Viktoria uses our application to come to work on time or school and occasionally order a car for the kids and to see where they are going.

Which cases will be relevant to Victoria as a user of a taxi application?

• Daily:
  • a trip from home to work, from work to school and then home;
  • a quick credit card payment method.
• Mandatory:
  • order a taxi for an unattended child;
  • track the trip on a map.
• Exceptional:
  • traveling by taxi outside the city.

Based on Viktoria’s profile and her needs we will be testing the following part of the application especially carefully:

• quick booking and pickup time;
• card payment;
• a trip with several destinations;
• booking a taxi for someone else;
• car geopositiong on the map and location accuarcy;
• trip options (a woman driver, a child seat, with/without luggage).

However, the following will require less attention:

• class and make of a car;
• booking a lot in advance;
• details of an error notification if you try to order a taxi outside the city;
• a chat with a driver option;
• the option to order several cars at the same time.

While testing we create several types of personas (typical future users) and plan common cases for them. After that it is time to test the use cases paying attention to the functionality which is relevant to the chosen type of persona.

The criterion if a use case passes the test is the answer to a simple question: is the goal gained using the application? If yes, and there haven't been any problems found which are not considered critical within a separate kind but matter particularly for them then the case has successfully passed the testing. Otherwise the priority of the bug should be reviewed and in addition you should check if during the use case testing the new previously unmarked bugs have appeared. An example of a failed case in Victoria’s story - an inaccurate location (delay of a real time car location). As for her it is one of the most important details when choosing a taxi application so even a small fault determines the choice (and, unfortunately, it may not be in favour of the application in which this bug is underestimated by the development and testing teams).

So after having created a user-persona and their common cases we can have another look at the product we are testing and as the result notice something important we might have missed during the specification-based testing.

Let’s sum up

Usability means not only a nice application interface (as outsource developers can hardly do anything about it). For us usability is first of all how convenient the common user cases are while using the application.

Being testers our main goal is to provide main cases with maximum clarity and reliability.

If this topic resonates with you i recommend to read the book The Inmates are running the Asylum by Alan Cooper. It applies mainly to UX- and business-analysts although testers may also get a lot of useful content and ideas.