With the coverage type "Checklist", all the situations are tested that are summed up in an unstructured list. 

This coverage type is applicable to, for example:

  • Testing requirements
    • The requirements describe what is required of the system, without going into detail about how exactly they are realised. For example: "Payment should also be possible in foreign currency." In principle, for every requirement 1 or more test cases are created to test that precise requirement. Some requirements are not testable and should then be removed from the checklist. For example: "With this system, the company's market share should increase by 20%." 
  • Testing use cases
    • The same largely applies here as to requirements, except that this concerns user scenarios instead of system requirements. 
  • Testing user-friendliness aspects
    • Examples of this are: understandable error messages; possibility of "undoing" the last action; maximum of 10 fields per screen. See also Nielsen's ten heuristics in "Usability". This delivers a checklist of things to be tested with every function or screen in the system and that can be checked off during the testing. 

It is a very simple coverage type in which the test cases are derived directly with no interim steps. Because there is no structure (therefore no dependencies between the defined situations), every line on the checklist can be checked separately and directly, and the sequence of the test cases is not important. However, the concrete working out into physical test cases is not always simple and can involve a lot of work. In addition, it should be realised that the checklist generally only achieves elementary coverage. For example, in the testing of requirements it only provides the certainty that every requirement has been tested once. This is not to say that it proves that the requirements have been correctly implemented in all the expected situations. 

It is also a coverage type that has little trouble with any changes in the test basis (and so the checklist itself). If a line is added to the checklist, a test case is added with which the relevant line is tested. 
This coverage type also offers the possibility of directing in a simple way how far the testing should go, and of measuring how far the testing has progressed: 

  • In the planning or preparation phase, the lines in the checklist are prioritised, e.g. with H(igh) – M(edium) – L(ow). Another common means of notation of priorities is the MOSCOW notation: Must have; Should have; Could have; Would have. In the execution phase, the lines (and so the associated test cases) are then executed in order of priority.
  • During test execution, the degree of coverage so far obtained can be reported on. This is measured as follows:
    • Degree of coverage = (Number of tested lines) / (total number of lines)
    • This strongly corresponds with progress (and is even exactly equal if test cases are 1-to-1 with the lines of the checklist):
    • Progress = (Number of test cases executed) / (total number of test cases).