Limitations and Difficulties of the Checklists

by Nataliia Vasylyna | February 10, 2012 1:30 pm

The significant feature of checklists[1] is that they are normally not very specific, especially those high-level ones. For instance, a high-level functional checklist normally includes the main functions to be conducted by software, but the list points are barely detailed enough for software testers to begin a specific test run.

The transformation from this testing model to the test cases and then to test runs is not an easy topic. It always involves well skilled software testing team setting up the system and testing environment to implement specific test cases[2].

Repetition of the equal test case in a later test run may only be secured with this supplementary data about setup and environment, but not deduced from the checklist item itself.

This may lead to obstacles when it is necessary to rerun the failing implementation to reconstruct the failure scenario for defect diagnosis, or when it is necessary to re-verify the software bugs fixes. Consequently, it is necessary to keep supplementary data for such goals.

With the enlarged demand for the automation, service, and functionality, modern software systems become larger and more difficult as well. Such systems consist of a lot of elements that are interplay with one another.

There are also a lot of various functions provided by the systems for many different users.

The structural complication and functional complication make it difficult to efficaciously use checklists for software testing and quality assurance[3].

There are some reasons for this:

1. It would be difficult to come up with checklists that cover all the functional (black-box) or structural (white-box) elements from various perspectives and at various levels of granularity. The result is missed areas of coverage.
2. In an endeavor to provide good coverage, a lot of overlaps between various points in the checklists may be introduced. The result is superfluous testing exertion when these checklists are used.
3. Several intricate interacts of various system elements are difficult or even impracticable to describe using checklists.

Well, the first two troubles can be resolved if we can derive a special kind of checklists, named partitions. Partitions can both reach full coverage of some specifically determined entities or interactions and avert overlaps.

The technicality and exactness involved in determining these partitions would also be helpful to receive a more exactly determined set of test cases as compared to common checklist, thus making defect[4] diagnosis, correct re-verification, and other tasks easier to conduct.

Related Posts:

• Software Testing Checklist – 5 Steps to Success[5]
• How Healthy Is Your Testing Process? A Full Checklist[6]
• Does Your Project Need a Test Plan?[7]

Source URL: https://blog.qatestlab.com/2012/02/10/limitations-and-difficulties-of-the-checklists/

---