The behavior tables build up the tree by defining the events in lines on different indention levels. The rows on the same indention are events that describe alternatives, and rows on the next indention are the continuation of the previous line. A line is executed successfully when the event on that line has been processed. An example of a successfully executed event is when a message has been received. A line can consist of one or a number of the following:

• send statement, states that a message is being sent
• receive statement, states that a message is being received
• assignment, there is an assignment of values
• timer operations; start, stop, or cancel a timer
• time-out statement
• Boolean operations, qualifying the execution

A plain send statement is always successfully executed. A receive statement is successful if a message of the correct type has been received and the value matched. A value assignment is always successful, as is a timer operation. A time-out statement is successful if the timer has timed out. A Boolean statement is successful if the expression is judged to be true.

All the leaves in the event tree are assigned a verdict that can be "pass," "fail," or "inconclusive." Pass means that the test case completed without the detection of any errors. Fail means that an error was detected (i.e., that the behavior of the IUT did not conform to the predefined specification). Inconclusive means that there was insufficient evidence for a conclusive verdict to be assigned, but that the behavior of the IUT was valid.

A verdict can be either preliminary or final, allowing for flexibility in the specification. A final verdict will terminate the active test case and return its verdict. A preliminary verdict will not terminate test case execution, but it will flag either pass, fail, or inconclusive. This preliminary verdict can be inspected during test execution, like any variable.

Figure 15. The TTCN Test Case Corresponding to the Event Tree in Figure 14

To describe what is happening in the test case, the dynamic behavior can be explained in plain language:

• The test case lifts the hook.
• The test case checks if a dial tone is heard.
• If a dial tone is heard, it enters the digits.
• It checks if a call tone is heard.
• If a call tone is heard, it checks if the line can be connected.
• If it can, it drops the hook and sets the verdict as pass.
• If a call tone is not heard, a busy signal is heard.
• Then the hook is dropped and the verdict is set as inconclusive.
• If a dial tone is not heard, the verdict is set at fail, and the test case is terminated (and a leaf in the tree has been reached).

Comparing the TTCN test case to the corresponding informal description in plain language shows that they are very similar, and that, for this simple case, there is basically no difference in readability. However, as tests grow more complex, the plain language format will be increasingly difficult to read, and the TTCN test case will be far more understandable.