The Importance of Checklists for Efficient Software Testing

What is a checklist and why is it important? 

A checklist is a fundamental element of software testing. It includes a number of tests that help to determine whether the product is ready for deployment. And if not, it helps to find out which components must be reworked. There is no way to be completely sure of the product quality without a checklist. And here is why:

  • You might spend an eternity testing an app and still won’t be able to say if it’s ready to be released or not with 100% certainty. To prevent that from happening you need to have a fixed set of tests that cover functionality of the future software entirely.
  • You won’t be able to come to a conclusion concerning the software being ready for deployment. Only with the help of a checklist you’ll be able to see the percentage of app functionality that works properly.
  • Let’s not forget about the “human factor”. It’s almost impossible to keep everything in mind and therefore name the product components that have already been tested and others that haven’t.
  • You can’t provide an exact time estimation for testing without a fixed set of tests.
Any checklist is created based on a Software Requirement Specification (SRS). When creating a list of tests, you should follow three basic rules:

  1. Tests included must cover all of the product functionality. There shouldn’t be a single requirement left unattended.
  2. The number of tests must be minimised. The more requirements you can check with one test the better.
  3. A set of tests mustn’t repeat the requirements, but check them.

When should a checklist be created?

Right before the development process takes off – in the final stages of the SRS creation. A QA Engineer’s input must be taken into consideration before the coding begins. Otherwise you risk wasting resources and time on reworking the existing modules or releasing a product that does not meet the customer’s expectations.

How do we do it in Magora Systems?

  1.  When the initial Specification is created, a QA specialist comes in. He or she studies the document, contributes valuable suggestions, and asks specific specifying questions.
  2.  After the Specification has been approved by the client, a set of tests required for the product are created. For recording the test results there are a few options available. The most convenient would have to be using a table that includes 3 columns: Test ID, Check, and Expected Results.

    Some use Excel for checklists, others utilise Google Drive Tables (a better option, as document can be dynamically updated and every participant can access it). We use Sitechko – a specialised tool for creating and editing checklists. It allows all the team members to view an up-to-date checklist version at any time and, furthermore, generate multiple types of reports for different testing configurations.

  3. As soon as the product is passed on for testing, a specialist must begin the testing for all the supported configurations according to the checklist subsequently. At times results of the expertise might show that additional tests need to be included into the checklist.


  4. After all of the tests have been completed, a specialist creates a Bug Report and a Product Status Report.

  5. When problems are found during testing have been eliminated/fixed, a tester must initiate Verification and Regression Testing. The results of these procedures must be included into the checklist as well.
  6. Completed checklists are stored in the Sitechko service. A history of all the testing iterations and reports can be accessed at all times.

Lyubov N.
October 20, 2014
You message has been successfully sent

Still have questions? We are ready to help

Please fill in at least one field!