The Test Plan

Assessment requires evidence that module tests are designed properly, run properly, and have been successfully run. Documented test results are also required.  In order to meet these requirements it is generally a good idea to document a test plan for each module.  Information that applies to all module tests can be documented in a common place and referenced from the test plans (e.g., hardware set up, etc.).  Including blank test result fields in the test plan is a good idea if you plan to copy the test plan file to use to test a specific version of the module.  Some of the fields in a test plan might be:

• Module Name
• Module version (blank results field)
• Date of the module (blank results field)
• Platform Identification
• Platform version (blank results field)
• Test tools and their versions
• Name of the tester (blank results field)
• A list of Test Cases

A Test Case might contain the following information:

• Function name
• Test Case ID
• List of input values
• List of expected output values
• Pass/Fail Criteria
• Actual output values (blank results field)
• Pass/Fail indication (blank results field)
• Notes (blank results field)

The IEC 61508 does not require that specific test steps (test procedures) for each module test be documented, as long as inputs and outputs for each test case are identified, and all test cases are properly identified.  Boundary value analysis and Equivalence Class analysis can be used to reduce the number of test cases.

Boundary value analysis is simply the process of identifying values of inputs with unusual properties.  A “special case” input of this type should be the basis for a test case.  Equivalence classes simply reduce the number of test cases by asserting that a subset of all possible inputs would exercise the code the same way, and therefore a test of each value is not necessary.  As a simple example, suppose an unsigned short integer (16 bits) is passed into a function.  The function’s specification states that only the values from 0 to 10, inclusive, are valid, and are used as a multiplication factor in an algorithm.  Test cases might then be specified for inputs of 0, 1 (multiplicative identity), 2, 6 (equivalence class), 10, 11 and 0xFFFF.  Most of these values come from boundary value analysis of the range defined for the input.  The value, 6, is included as a general representation of the “normal” values.  .

As a variation of this example, if the meaning of the valid values is unique for each value (i.e., each unique value means the function operates differently from the others), each value would have to be tested in its own test case (i.e., the principle of equivalence class does not apply, except to values greater than 11)..

Check back next week for the final post in this series.