1. The Test Case Design document shall be the complete set of test cases to be performed during testing.
2. The Test Methods shall be implemented in the Test Case Design document.
3. All System/Unit test cases shall receive baseline approval before coding begins.
4. All coding shall receive baseline approval before testing begins.

1. All Test Case Design specifications shall be applied during testing.
2. All tests cases, unit and system, performed during testing shall be documented using the Software Test Report. These will be filed in the module's Software Development File.
3. The Unit/System Test Report shall be used for either system and unit tests.
4. Copies of the STR's will be sent to QA&I and the group conducting the tests.

1. All problems or errors found during testing shall be documented by a PTR. These reports will be filed in the module's Software Development File.
2. The PTR shall serve as a basis for further investigation of the problem.
3. Copies of the PTR's will be sent to QA&I and the group conducting the tests.

Test Methods

Testing Tools are now available. The Metre-2.3 software testing tool tests for McCabe's cyclomatic complexity and path analysis. A condensed list of command line instructions are displayed at the Testing Tools link. The Metre testing tool shall be used to gather metrics for the system and unit testing.

System Testing

The System Test Plan for Prototype II is the basis of systems testing for prototype II. System test case design starts after the requirements specification is baselined. The test cases generated shall directly reflect the requirements of the functional specification. The system test case designer(s) shall design appropriate test cases to validate the correctness of the system. The black box testing techniques shall primarily be used at the system test level. This technique is a comparison of the actual output with the specified output, regardless of the structure of the code or the code unit under test.

To this end, an Equivalence Partitioning/Boundary Value technique shall be implemented. The four primary types of inputs will be:

1. A Simple Case - A test value that establishes the basic correctness of the process. This shall be the starting point of all system and maintenance tests.
2. Legal input values - Test values within the boundaries of the specification equivalence classes. This shall be input data the program expects and is programmed to transform into usable values.
3. Illegal input values - Test equivalence classes outside the boundaries of the specification. This shall be input data the program may be presented, but that will not produce any meaningful output.
4. Special Cases - Input cases that are not identified by the specification. Such as nonsensical data(i.e. negative numbers or characters), depressing several input keys at once, or any other test case the test designer feels has a good chance of exposing an error.

The Equivalence Partitioning Technique is a test case selection technique in which the test designer examines the entire input space defined for the unit under test and seeks to find sets of input that are, or should be, processed identically. Included in the input space are legal situations that have both syntactic and semantic meaning to the program, and illegal situations that are either syntactically or semantically meaningless to it. These sets of input are equivalence classes. Similarly, in the Boundary Value techniques, the test designer first identifies the range of expected inputs(e.g. equivelence classes), then tests the input values inside and outside that range.

For example,

The legal input boundary is 0 to 100,
you have three input values 5, 50, and 100, all are legal, but processed differently,
so you have three equivelence classes within the bounded values.
The boundary values outside the expected range are values < 0 and > 100.
so you have two more equivelence classes outside the bounded values.
In all you have five equivalence classes and therefore five test cases.

After each successful installation of an approved module/program, a system test will be conducted. The system test cases shall ensure the functional/specification requirements are met. Test data/cases shall be derived from the specifications.

Unit Testing

Unit test case design begins after the high level design is approved by a Peer Technical Review. The unit test cases shall be designed to test the validity of the program's correctness. White box testing will be used to test the modules and procedures that support the modules. The white box testing technique ignores the function of the program under test and will focus only on its code and the structure of that code. To accomplish this, a Statement and Condition technique shall be used. Test case designers shall generate cases that not only cause each condition to take on all possible values at least once, but that cause each such condition to be executed at least once:

1. Each decision statement in the program shall take on a true value and a false value at least once during testing.
2. Each condition shall take on each possible outcome at least once during testing.
3. Each program shall be tested for complexity based on McCabe's measurement.

The Metre-2.3 software testing tool is available to find the number of paths in a program and to find its cyclomatic complexity. Metre tests both McCabe's cyclomatic complexity and Extended complexity. When the cyclomatic complexity exceeds ten, the opportunity for coding errors increases dramatically. If this situation arises, it shall be required to re-evaluate the structure of the code in question and attempt to decrease its complexity. The extended complexity metric will give you the number of paths in the code. This will assist the designer to develop test cases that encompass all possible paths.

The measurement of cyclomatic complexity by McCabe is designed to indicate a program's testability and maintanability. It is a graph theory cyclomatic number, indicating the number of regions in a graph. As applied to software, it is the number of linearly independent paths comprising the program. As such it can be used to indicate the effort required to test a program. To determine the paths, the program procedure is represented as a strongly connected graph with a unique entry and exit point. The general formula to compute cyclomatic complexity is:

• M = V(G) = e - n + 2 * p where

• V(G) = cyclomatic complexity( # of paths ),

• e = edges, n = nodes, p = # of unconnected parts of the graph.

  As an example, a simple program might contain two IF-THEN-ELSE statements. The image to the right is a graphical representation. Point A represents an entry point and the two paths of the first IF statement. B and C represent the actions taken in the IF-THEN-ELSE statement. B is the THEN process and C is the ELSE process. D is the exit point of the first IF-THEN-ELSE statement and the entry into the second. E and F are the processes of the second IF-THEN-ELSE statement. The second IF-THEN-ELSE statement is completed and the the program terminates at G.

  A node(n) is a point on the graph, e.g. A. An edge(e) is the path between nodes, e.g. A-B. The disconnected point(p) is G.
  If we count the edges, nodes, and disconnected parts of the graph, we see:

• e = 8, n= 7, p = 1

• V(G) = 8 - 7 + 2 * 1= 3 distinct paths.

The cyclomatic complexity metric is additive. The complexity of several graphs considered as a group is equal to the sum of the individual graphs' complexities.