Limitations and Difficulties of the Checklists
The significant feature of checklists 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.
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.
There are some reasons for this:
- 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.
- 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.
- 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 diagnosis, correct re-verification, and other tasks easier to conduct.
Learn more from QATestLab
Related Posts:
About Article Author
view more articles
Interesting read. Software product development is a tedious task and testing is even more complicated. It is important to break each module into small elements and work on the permutations and combinations that might occur on the element. Deep understanding of clients expectation is crucial before creating a checklist.
It’s too good