Working with checklists
Working with checklists
Checklist – is a list which contains a number of necessary checks during testing of the software product. By checking the items on the list, a team or one tester can learn about the current state of the work performed and about the quality of the product. By working on a project using a checklist, the probability of re-checking for the same cases is excluded, and the quality of testing increases, since the probability of leaving some functionality unattended is significantly reduced. Therefore, it is very important to know the composition of the checklist elements and be able to use it effectively. As a rule, checklists are made in a Google spreadsheet to provide general access to all QA specialists.
What do checklists consist of?
Сhecklists are very simple. All of them contain a list of blocks, sections, pages, other elements that should be tested, for example:
Items can contain both a linear structure and a tree structure, with or without sections/subsections. They should be as concise as possible and at the same time understandable for a tester who isn't familiar with the application yet. The points must be clear so that they can’t be understood in any other way. All of the items must be in one language: Russian or English.
As a rule, each checklist has several columns. Each column is for testing on a separate platform. The device name, browser, and version should be indicated as well.
Several people could test the application at the same time. In this case, each tester takes one or two platforms and tests only on them. In this case, the tester who performs the specified amount of work should be indicated in front of each platform.
Passing the checklists, the tester marks the status in front of each tested item. The following status options are possible:
- «Passed» – test is passed successfully, no bugs found;
- «Failed» – one or more bugs found;
- «Blocked» – impossible to check, because one of the bugs is blocking the current test;
- «In Progress» – the tester is working on the current point;
- «Not run» – not yet tested;
- «Skipped» – will not be tested for any reason. For example, the current functionality has not yet been implemented.
After testing is complete, there should be no cells marked as «Not run».
All check-list bug reports should be added to the notes to the cell with the «Failed» status.
It is acceptable to add notes to some cells with different statuses, if necessary.
Status notes with links to bug reports are also required for cells with the «Blocked» . However, as a rule, the note in the cell with the «Blocked» status refers to a previously created bug report, which in one of the previous tests has already been marked as «Failed». In other words: an item once marked as «Failed» can be a blocker for several or all of the following items on the checklist. Let's take a look at this example:
Here we can see that there are 2 different bugs. Let’s say that the first one is for the Chrome browser – some function doesn’t work as intended. In this case we create a bug report and mark the current test as «Failed». All other tests will be marked as «Blocked», since it will be impossible to check them.
It is the same with the Firefox browser. The email letter can’t be sent and a bug report is created on this, so, all the tests related to email sending are marked as «Blocked» with a link to the same bug report.
Note, that a few main points that should be taken into account when working with checklists:
- After completing the passage of the checklist, there should be no cells with the «Not run» status.
- All cells with the «Failed» status and the «Blocked» status must have notes with links to bug reports.
- The «Passed» status set only for tests that are checked and do not contain bugs.
Checklist creation rules
To create an effective checklist, we will formulate several rules.- One point – one operation.
- Points are unequivocally defined.
- Drafting a checklist according to the details level.
Benefits of using the checklist:
- Checklists help to structure the information from the employee;
- With the correct formulation of necessary actions, the employee has an unambiguous understanding of the tasks. This helps to increase the learning speed for new employees;
- Checklists help to avoid uncertainty and errors that can be caused due to the human factor. Test coverage of the software product is increasing;
- The degree of employee interchangeability is increasing;
- Saving the working time. Having written a checklist once, you can reuse it, given the relevance of the information.
- avoiding forgetting the required tests.
- dividing tasks by skill level.
- saving the reports and test results.
- The list of tests (with necessary details level).
- Checking environment consist:
- a build on which testing were performed;
- a testing environment (if applicable);
- some information about the tester.
- Results of the test.
