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 …
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?
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
Test internal interfaces
Test external interfaces
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
- 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