Notes on Documenting Acceptance Tests

Email Notifications

SHARE
Request to reuse this

This blog extends my previous notes on what may constitute a document for acceptance tests. The points are brief, and may not reflect what is practiced in your region or project.

Typical information required:

1. Indicate the rational for each test case or that for the test suite - specifically to ascertain compliance to specified or contracted requirements.
2. State how to perform the test for each test case
3. Present the expected outcome from the test case
4. Capture the actual result of each test case
5. Record observations and comment -on deviations from expected outcomes.
6. Attest the test results.

The acceptance test document may include appendices to conclude the test: 

• Evidence of completion of prerequisite tests 
• Evidence of readiness for testing e.g. prerequisite tests were conducted satisfactorily.
• Evidence of calibration e.g. the appliance and-or test tools were recently calibrated and readied for testing.
• Evidence of license - if any is required from the authorities or license owners.
• Statement from the customer - is prepared and ready to accept the deliverables (e.g. on completion of testing with positive results).

There was an incident where the external auditor of the customer, questioned the unfilled frames and scribbles outside of fill-in frames on hardcopy test forms. This occurred despite the testers having been briefed on protocols. The problem here is that incomplete filling and off-witted remarks on a formal test document can cast doubt or uncertainty on the test outcome. 

As such I would emphasize the inclusion of a chapter or section on procedures for completing test cases, i.e. specifically on executing specified tests and filling-up test case forms. Regardless of whether the forms are hardcopies or digital (such as using a purpose driven app on a tablet). I would place this as the first section of the test procedures. It should define information e.g. as follows –

• Capture pertinent details of personnel involved in the tests.
• Provide guidelines on acceptance testing policies, and procedures in completing test cases (note specified test cases are defined in a separate section). This section may include an overview of processes leading towards ratifying the test results (the reason being that each test set or group may have different requirements).
• Sign-off that the chapter has been read and understood before proceeding with the tests.
• Other information may include processes for negative test results (given that time is the essence for work at this stage).
• Additional information could be to indemnify the parties involved in the tests (note that some tests may be conducted live e.g. running hot, a module from DevOps).

See also my notes for training on –

• User acceptance testing
• User acceptance testing - documentation issues
• User acceptance testing - documentation