I decided to continue showing test documentation samples, where we use rich-text and today I'll show how we use test documentation other than detailed test cases. The style of documentation we are using is sometimes referred to as checklists, because they don't describe in too much details the exact test steps, but only what should be validated. Nevertheless pass/fail/block are to be marked for each checklist item, that why it is called Check List.

We use this type of test documentation in at least two cases. First case is when we want tester to interact with requirements during testing process, so that details how how to test are extracted from requirements and checklist only helps to demonstrate the progress and a placeholder to keep notes what does not work.

Note: some semi-secure information is hidden behind black rectangles just-in-case.

Sometimes when there are too much items in checklist we organize them in in a tree structure and use different colors to make regression testing easier. Red mean that there is something left untested yet, we use to vary usage of other colors, in the following example we use black and blue to separate test ideas from test execution notes.

We also use this type of documentation to do frequently repeated tests, such as testing the same ideas for many different forms or to do frequent smoke/regression tests of the same functionality. As a result it is not necessary to provide more deatils - testers know the details, they are in their heads.

Yet to be continued with illustrations of Exploratory Test Notes kept with screen-shots and maybe more