Description
The elementary comparison test ( ECT) is a thorough technique for the detailed testing of the functionality. The necessary test basis is pseudocode 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. The basic technique used here is:
Variations on the ECT can be created by the application of the following basic techniques:
 Decision points: multiple condition coverage
 With this, the possibilities within the decision points (specifically selected, if necessary) can be tested in more 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 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 pseudocode below gives a detailed functional description of this: IF Age < 18 years OR driving licence suspended

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 pseudocode 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 pseudocode.
The decision points in the pseudocode 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:

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 D11, D12, 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  


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:
NB! The parameter "Age" occurs in the decision points D1, D2 and D3. This leads to the following mutually exclusive test situations: D21 with D33; D23 with D33. 
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:

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 nonconflicting 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:

4  Establishing the starting point
No remarks.
Example  


An overview of all featured Test Design Techniques can be found here.
In Quality for DevOps teams, and the syllabus for TMAP: HighPerformance Quality Engineering the coverage type MCDC and the test design techniques Semantic testing and Elementary Comparison Testing are combined.
Read here how these techniques are to be used in a combined way.