Small recipe to find big bugs

Finding bugs is a job, and you can learn it! Of course, experience counts for a lot, but there are some good practices that I offer to detail here. It can help you if you need to teach QA QA to someone, or if you are in a too small structure to have a full-time QA employee.

Test the limits of the system

First of all, start with the idea that PO did his job correctly: he thought about the majority of simple usecases. The job of the QA will consist in looking for all the edge cases, in looking for how to break the system.

1) Text fields

For all the fields where the user can fill characters, the trivial case consists in adding the expected text in the field (a name for instance). But what happens in the following cases?

unconventional characters (é, è, @, etc …)
if the field remains empty
if the text entered is very long
should the field accept only numbers? or conversely refuse them?
in the case of numbers, what happens with negative numbers? and zero?
etc …

2) Arrays

In the same way, if the user can update an array or a list of elements (addition / modification / removal of an item). What happens if he removes the last item from the array? how many elements can the array have at most?

3) Dates

If there is a date management system, are there situations where month / year changes could create issues ? What about time zones?

Test the system states

Current software often provides several states, or several levels of completion. For instance, a user may have paid only to access part of the software, or he may have filled in only certain fields and not all of them, etc.

These different states are as many situations to test, or at least to consider. It will then be your knowledge of the system that will allow you to know if each state should be tested, or if certain tests include several states at once.

Test internal interfaces

Our softwares are made of several layers (often, the frontend, API, and backend). Each layer is tested independantly from others thanks to unit tests made by the developers, but many bugs are hidden in the connection between these layers. These bugs are often due to poor communication between people within the team: for instance, the API dev changes an endpoint but forgets to give this information to the consumers of this endpoint.

Test external interfaces

Nowadays, our tools are interconnected, and we can call other softwares from our system (think about social networks). The “happy path” consists in having all these connections well connected. QA will therefore test all the other means of interacting with the software. For instance, in the case of a mobile application, how does it behave if you click on “share on Twitter” but Twitter is not installed? Similarly, does the application know how to manage the case of airplane mode, or not having access to the internet? What happens if I receive a phone call while using the application?

Test platforms

Whether you work on a smartphone, on the web, or on any other system, it can be interesting to test the different platforms. I advise you to look at your analytics to find out which platforms are the most used by your customers (get closer to your PO if you don’t know how to do that). For instance, if the usage distribution of your application is (90% chrome / 10% Firefox), do all your tests on Chrome, but plan one day per week on Firefox.

Create your system checklist

All the examples given above are quite generic, but your system is unique: make your own checklist, based on the pitfalls your team has encountered in the past. To do this, bring together some developers and POs who work in the company for a long time, and try to list recurring mistakes / omissions in the specifications and implementations. Once this checklist is made, do not keep it for yourself, share it with your POs. Thus, they will be able to review these points before submitting the next new features.

What you must remember

QA wants to break the system. To do this, he wants to:

test the edge cases (0, infinity, negative, exotic characters …)
test system states
test internal and external interfaces
test the various platforms
make a checklist of points to be checked by the PO before submission