Testers often use checklists. Each team has a different approach to how and why to use the it. Some people think that testing is impossible without a checklist or test cases, while others think that we don’t need it at all. Let’s see what approach I use.
What is a checklist?
First of all, let’s see how ISTQB answers this question:
high-level list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified
from the definition of checklist-based testing
But very often, teams understand checklists as test cases, from which only the name was left. Moreover, they try to describe the checks as accurately as possible so that anyone can use this checklist. Furthermore, there are cases when the presence of checklists or test cases is evidence that the product has been tested.
Checklist is a tool
The checklist is not the result of the tester’s work. Just like Postman, a keyboard and a mouse are not the result of the work of a tester. These are the things that the tester uses to do his job. Moreover, not every task needs a checklist, just as not every task needs Postman.
Thus, the checklist is a tool we need to use where it can be useful. Mostly, its main purpose is the self-control of the tester, that nothing important is forgotten or missed.
A typical workflow for using a checklist is as follows:
- get a task
- write checklists for it
However, I use a different order.
When a task comes to me, I immediately start generating ideas on how to test it. But instead of writing these ideas down in a checklist, I apply them. Thus, while testing, I am constantly looking for opportunities for other experiments. In contrast, if I wrote down all my ideas in a checklist, I would test, relying on the fact that all possible ideas are already there.
And after testing is completed, I can use the checklist as a tool. In case I want to find new ideas, I write down all the checks I made. Very often it works as a fresh look from the outside. I can see areas that I have paid little attention to. Also, I can spot obvious checks that I missed.
To summarize, I want to highlight that you should only use the checklist when you really need it. And by writing it after you’ve tested everything, you give yourself the opportunity to discover what you missed during testing. It is important to remember that testing is not writing documents, but the collection of the most complete information about the product.