Elementary Comparison Test (ECT)

Description

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.

Test approach:	Coverage-based – condition oriented
Test variety:	Functional testing
Test basis:	Pseudo-code or a comparable specification in which the multiple decision points and functional paths are structurally worked out in detail
Coverage type:	Modified condition decision coverage (MCDC) and other coverage types possible, see below.

The ECT aims at thorough coverage of the decision points into test cases that run from start to end of a process flow. The coverage is based on combining decision outcomes triggered by different condition values. (This is in contrast to testing process flows with path testing where only the coverage of paths and path combinations is relevant, ECT will result in more test cases than path testing for the same process flow).

ECT is normally used with the test technique Modified Condition Decision Coverage.
When the quality risk level is very high, the ECT may be used with the test technique Multiple Condition Coverage.

Points of focus in the steps

In this section, the elementary comparison test is explained step by step. In this, the generic steps, see "Introduction" are taken as a starting point. An example is also set out, showing at every step how this technique works.

Example

In this example, we take a function (task) in which the data referring to the car owner are entered in a screen and subsequently, upon request, a calculation is made of the premium that the car owner should pay for his vehicle insurance. Depending on a number of variables, the level of the premium is established. The pseudo-code below gives a detailed functional description of this: IF Age < 18 years OR driving licence suspended

IF		Age < 18 years OR driving licence suspended
THEN		Error message
ELSE	IF	Age < 25 years AND years holding driving licence < 3
	THEN	Premium := 1,500
	ELSE	Premium := 800
	ENDIF
	IF	Car age < 2 OR (car age ≥ 5 AND damage in last 3 years ≥ 2,500)
		OR age ≥ 70
	THEN	Increase premium by 500
	ENDIF
ENDIF

1 - Identifying test situations

It is set out per step below how the elementary comparison test is applied to this function:

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).

Example

There are three decision points, which are shown structurally below:

D1	IF		Age < 18 years OR licence suspended
	THEN		Error message
D2	ELSE	IF	Age < 25 years AND number of years holding driving licence < 3
		THEN	Premium := 1,500
		ELSE	Premium := 800
		ENDIF
D3		IF	Car age < 2 OR (car age ≥ 5 AND damage in 3 years ≥ 2,500) OR age ≥ 70
		THEN	Increase premium by 500
		ENDIF
	ENDIF

Per decision point, the basic technique for 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.

Example

D1 A OR B	1 Error message	0
A: Age < 18	1 0 (1)	0 0 (3)
B: Driving licence suspended	0 1 (2)	~~0 0~~

D2 A AND B	1 Premium = 1,500	0 Premium = 800
A: Age < 25	1 1 (1)	0 1 (2)
B: # years with driving licence < 3	~~1 1~~	1 0 (3)

D3 A OR (B AND C) OR D	1 Premium + 500	0
A: Car age < 2	1 0 1 0 (1) (or 1 1 0 0, but that gives a logical contradiction, or 1 0 0 0)	0 0 1 0 (4)
B: Car age ≥ 5	0 1 1 0 (2)	~~0 0 1 0~~
C: 3 years-damage ≥ 2,500	~~0 1 1 0~~	0 1 0 0 (5)
D: Age ≥ 70	0 1 0 1 (3) (or 0 0 1 1, or 0 0 0 1)	~~0 1 0 0~~

NB! In D3, the combination "A = true and B = true" gives a logical contradiction and therefore may not occur in the test situations: Car age should be simultaneously lower than 2 and higher than, or equal to, 5. This contradiction would otherwise show up when the test cases are made physical.

Detailed working out of the derived test situations:

Test situations D1	D1-1	D1-2	D1-3
Age	< 18	≥ 18	≥ 18
Driving licence suspended	N	Y	N

Test situations D2	D2-1	D2-2	D2-3
Age	< 25	≥ 25	< 25
# years with driving licence	< 3	< 3	≥ 3

Test situations D3	B3-1	B3-2	B3-3	B3-4	B3-5
Car age	< 2	≥ 2	≥ 2	≥ 2	≥ 2
Car age	< 5	≥ 5	≥ 5	< 5	≥ 5
3 years-damage	≥ 2,500	≥ 2,500	< 2,500	≥ 2,500	< 2,500
Age	< 70	< 70	≥ 70	< 70	< 70

NB! The parameter "Age" occurs in the decision points D1, D2 and D3. This leads to the following mutually exclusive test situations: D2-1 with D3-3; D2-3 with D3-3.

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.

Example
The test situations are reproduced in the figure below.

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 by one 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 (directly obtainable from the tables in step 2) 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.

Example

The table below describes test cases TC1 to TC7 incl., which give the required coverage:

Test situation	Value	Next	TC1	TC2	TC3	TC4	TC5	TC6	TC7
D1-1	1	End	X
D1-2	1	End		X
D1-3	0	D2			X	X	X	X	X
D2-1	1	D3				X			X
D2-2	0	D3			X		X
D2-3	0	D3						X

D3-1	1	End			X
D3-2	1	End				X
D3-3	1	End					X
D3-4	0	End						X
D3-5	0	End							X

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. For example, test situation D2.1 requires "Age < 25" and test situation D3.3 requires "Age ≥ 70". These test situations are mutually exclusive.

Mutually exclusive test situations

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.

Example

In the table below the physical test cases are shown, including the predicted results:

Test case	TC1	TC2	TC3	TC4	TC5	TC6	TC7
Contains test situations	D1-1	D1-2	D1-3 D2-2 D3-1	D1-3 D2-1 D3-2	D1-3 D2-2 D3-3	D1-3 D2-3 D3-4	D1-3 D2-1 D3-5
Age	16	33	35	19	72	24	20
Driving licence suspended	N	Y	N	N	N	N	N
# years with driving licence			2	0	1	5	2
Car age			1	12	6	3	20
3 years-damage			6000	4300	50	2700	2200

Result:
Error message	X	X
Premium			1300	2000	1300	800	1500

4 - Establishing the starting point

Example

The premium sums should be entered in the database. The details of the car owner are entered online and the premium is then calculated immediately.

Another example you can find in the Syllabus paragraph 7.7.3.
An overview of all featured Test Design Techniques can be found here.

Test design techniques