What is the elementary comparison test?
The elementary comparison test ( ECT) is a thorough technique for the detailed testing of the functionality. The necessary test basis is pseudo-code or a comparable specification in which the decision points and functional paths are worked out in detail and structurally.
The ECT aims at thorough coverage of the decision points and not at the combining of functional paths. A often applied coverage type is: Decision points: modified condition/decision coverage.
Variations on the ECT can be created by the application of the following coverage types:
- Decision points: multiple condition coverage. With this, the possibilities within the decision points (specifically selected, if necessary) can be tested in more depth.
- Decision points: condition coverage through condition/ decision coverage.With this, the possibilities within the decision points (specifically selected, if necessary) can be tested in less depth.
- Boundary value analysis. With this, the possibilities within the decision points (specifically selected, if necessary) can be tested in more depth.
- Pairwise testing. With this, the testing of possible combinations of functional paths is added.
It is a preferred technique for testing functions deemed very important and/or complex calculations.
Points of focus in the five general steps
1. Identifying test situations
The test basis consists of pseudo-code or a comparable formal function description which can be copied directly in this step. If not, an extra activity should be carried out in order to convert the existing specifications into pseudo-code.
The decision points in the pseudo-code are provided with unique identification.
It is usual to use the codes D1, D2, etc. for this (or D01, D02, etc. if there are many decision points).
Per decision point, a coverage type (e.g. MCDC (modified condition/ decision coverage)) is applied. The resulting test situations are numbered. The combination of this number and the decision point provides a unique identification of the test situations (such as D1-1, D1-2, etc.). The numbering begins with the test situations from column “1” (True) and then from the column “0” (False).
For each decision point, the test situations are worked out in detail in a separate table. The rows of the table contain the data or parameters that occur in the conditions of the decision point. A column then indicates which requirements are set on each parameter for the relevant test situation.
Graphic demonstration of test situations
For some testers, the creation of logical test cases is made easier with the aid of a graphic demonstration of the test situations – a Graph.
With this, each decision point and end point is represented by a circle and each test situation by a line that goes from one circle to another.
A logical test case runs through the graph from beginning to end, linking a chain of test situations. The graph also supplies insight into the minimum number of test cases necessary to cover all the test situations. This is determined by the maximum number of parallel lines in the graph.
2. Creating logical test cases
A test case runs through the functionality from start to end and will come across one or more decision points on its path. With each decision point, the test case will test one of the defined test situations.
The logical test cases are combined with the aid of a matrix. The rows contain the test situations and the columns contain the logical test cases. With each test case, it is indicated byone or more crosses which test situations should be tested by this test case. This matrix simultaneously serves as a check on the complete coverage of test situations.
In order to take account of the nesting of decision points, the columns “Value” and “Next” have been added. These indicate for each test situation what the outcome of the decision is and to which subsequent decision point (or end process) this leads. This helps to prevent the tester from placing a cross at a test situation where the test case does not go.
Mutually exclusive test situations
Each test situation sets particular requirements on one or more parameters. If a parameter occurs in several decision points, it is possible that a test situation in one decision point sets requirements on that parameter that conflict with the requirements of a test situation in another decision point.
A logical test case may not contain “mutually exclusive test situations”, for that makes the test case inconsistent and therefore unexecutable. Such a test case will be discovered automatically, as soon as the test case has to be made physical (see next step). The problem can then be simply resolved, by replacing one of the “mutually exclusive test situations” with a non-conflicting test situation. In this connection, it can be advantageous to first translate each logical test case into a physical test case in order to discover possible mutually exclusive test situations, before starting on the following logical test case.
In order to reduce the probability of test cases occurring with mutually exclusive test situations, the optional step of an extra analysis could be carried out in advance:
- · Inventory which parameters occur in several decision points, and (per parameter) which decision points they are
- · Sum up the combinations of mutually exclusive test situations.
3. Creating physical test cases
With a physical test case, all the parameters (data) have to be given concrete substance, so that the relevant test situations are covered by this.
Physical test cases can be handily described with the aid of a matrix that is built up as follows:
- · Each column describes a physical test case.
- · The first row indicates per test case which test situations should be covered.
- · Thereafter, there is a row for each parameter of which the test case consists.
- · Finally, one or more rows are added with which the predicted result is described in concrete terms.