Test cases

Definition

A test case is used to examine whether the system displays the desired behaviour under specific circumstances. It must therefore contain all of the ingredients to cause that system behaviour and determine whether or not it is correct. A well-known way to describe system behaviour is ‘Input → Processing → Output’.

A test case consists of a description of the starting point (also known as initial situation), the test action and the predicted result:

Starting point (initial situation)
- This covers everything that is needed to prepare the system for receiving the required input. This includes not only the data that are needed for the processing, but also the condition in which the system and its environment must be. For instance, one might think of setting a specific system date, or running specific week and month batches that bring the system to a specific status.
Actions
- This means all of the activities that must be executed to activate the system to the processing. It might be a simple command (‘Run …’) or entering specific data on a screen. But it can also be a complex sequence of entering parameters, activating a specific function, manipulating other data, starting up another function, etc.
Predicted result
- This covers all of the results that the tester must check to establish whether the system behaviour conforms to the expectations. Often, predicted result is incorrectly thought to be limited to the output that appears on screen or is stored in databases. But the system can also produce output that is transmitted to other systems or peripheral equipment. Furthermore, more than just output data may have to be checked to established that the system is working correctly. For instance: ‘How quickly should the output appear?’, ‘What is the maximum allowed memory load and is it released afterwards?’, or ‘Should the system produce interim signals or messages, such as the hourglass or beeps?’

See the figure below for the generic structure of a test case.

In other words, executing a test case roughly goes through the following steps: ‘Prepare this → Do this → Check that.’

Contrary to a test situation – which addresses an isolated aspect – a test case is a complete unit that can be executed as a separate test.

When designing test cases, we first create logical test cases that are then worked out into physical test cases. Both terms are explained in further detail below.

Logical test cases

A logical test case describes, in logical terms, the circumstances in which the system behaviour is examined by indicating which test situations are covered by the test case.

Physical test cases

A physical test case is the concrete elaboration of a logical test case, with choices having been made for the values of all required the input and settings of the environmental factors.

The physical test case describes in practical terms what has to be done. The 3 basic elements of a test case are recognisable: What needs to be prepared? (Initial situation) What does the tester have to do? (Action) What is the expected result? (Predicted result).

The step from logical to physical test case is more than just inserting concrete values. It is also a step from ‘theoretical’ to ‘practical’. In this step, the tester needs to look beyond the system specifications on which the logical test cases were based and ask himself: ‘Do I now know everything I need to execute this test case in the Execution phase?’

Physical test cases generally contain a specific description of:

The initial situation.
Everything that is needed to receive the in- and output of the system, such as:
- Database with the required data.
- (Test) environmental parameters like the system date.
- State of the system under test.
Action
- Actions needed to activite the system behavior, like running a batch program or entering data in a GUI.
Prediction of the result.
- Do we get the right message on the screen.
- Do we receive the right data in the database.

Please insert in this col ‘Sidebar Inserter‘ and select your sidebar(s).