Semantics are semantic rules that specify (combinations of) data that should be met in order to be accepted by the object to be tested. When testing semantics we test the validity of the data input.
Semantic rules deal with relationships between data. These relationships may be between the data within a screen, between data on various screens and between input data and existing data in the database. Semantic rules may be established in various documents, but are usually described in:

  • Functional specifications of the relevant function or input screen
  • The business rules that apply to the functions overall.

A semantic rule that describes the conditions of validity can generally be set out as follows:
IF (semantic rule) THEN valid input or processing
 ELSE error message

In the event that the semantic rule describes the invalid situations in which an error message should occur, this becomes:
IF (semantic rule) THEN error message
 ELSE valid input or processing

Since the semantic rules can be specified as decision points that consist of one or more conditions connected by AND and OR, one of the coverage types for the semantic test is selected from the area of decision points. For this we refer to the coverage type decision points.
In more detail
In practice, semantic rules are sometimes described in the form: “IF item X meets condition A, THEN condition ... should also be met” The pitfall here is that it appears as though the semantic rule only consists of the condition “IF item X meets condition A”. However, that is not the case. Everything that comes after the “THEN” also describes the conditions that should be met. In fact, this way of writing the semantic rule is an example of the “imply operator” in Boolean algebra. 
Now, a condition that is described by the imply operator can be converted simply into a compound condition with the same truth table:
“A → B” is equivalent to “(NOT A) OR B”
Modified condition/decision coverage can be applied to the resulting compound condition – that contains only the operators AND, OR and NOT – without difficulty.
The following example explains this further. Suppose that the following semantic rule is specified:
“When code_contribution = V THEN code_employment must be = F AND Age ≥ 55”
An imply operator has been applied here, whereby the rule actually looks like this:
“code_contribution = V → (code_employment = F AND Age ≥ 55)”. This can be converted into the following compound condition:
“(NOT code_contribution = V) OR (code_employment = F AND Age ≥ 55)”


“code_contribution ≠ V OR (code_employment = F AND Age ≥ 55)”