The data cycle test (DCyT) is a technique for testing whether the data are being used and processed consistently by various functions from within different subsystems or even different systems. The technique is ideally suited to the testing of overall functionality, suitability and connectivity.
The primary aim of the data cycle test is not to trace functional defects in individual functions, but to find integration defects. The test focuses on the link between various functions and the way in which they deal with communal data. The DCyT is most effective if the functionality of the individual functions has already been sufficiently tested. That is also an important reason why this test is usually applied in the later phases of acceptance testing.
The most important test basis is the CRUD matrix (see "CRUD") and a description of the applicable integrity rules. The latter describe the preconditions under which certain processes are or are not permitted, such as, for example, "Entity X may only be changed if the linked entity Y is removed from it". Besides this, functional specifications or detailed domain expertise is necessary in order to be able to predict the result of each test case.
The basic techniques used are:
- CRUD, for coverage of the life cycle of the data
- Decision coverage, for coverage of the integrity rules.
Reinforcement of the test can be achieved by the application of, e.g.:
- A more extended variant of the CRUD
- Modified condition/decision coverage or multiple condition coverage of the integrity rules.
Points of focus in the steps
In this section, the data cycle 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 that demonstrates, up to and including the designing of the logical test cases, how this technique works.
1 - Identifying test situations
Test situations in connection with CRUD
The following activities should be carried out:
- Determine the entities of which the life cycle is to be tested.
Usually, this concerns all the entities that are used by the system or subsystem (created, changed, read or removed). If there are too many enitities, a cohesive subset of entities may be selected
- Determine the functions that make use of these entities.
Here, too, the scope of the test should be determined: all the functions of the system under test, a cohesive subset of this, functions from other systems that are linked to the system under test
- Fill in the CRUD matrix (see "CRUD").
If the CRUD matrix is delivered as a test basis, the relevant part should be selected from this, based on the previous two activities. If it was not possible to get the CRUD matrix delivered as a test basis, the test team may decide to create this themselves, based on the functional specifications. This is obviously undesirable, but is a last resort
- Each process (C, R, U or D) that occurs in the CRUD matrix is a separate test situation that has to be tested.
Test situations in connection with integrity rules
The following activities should be carried out:
- Gather the integrity rules on the selected entities.
These are the rules that define under which conditions the processing of the entities is valid or not. Integrity rules are usually specified within the functional specifications, database models or in separate business rules
- Apply decision coverage. That means that for each integrity rule, two test situations are derived:
The integrity rule is disobeyed. The process is invalid and should result in correct error handling.
The integrity rule is obeyed. The process is valid and should be executed.
|In more detail|
Integrity rules (see integrity rules) should not be confused with semantic rule (see semantic rules), which define the conditions under which the value of the data themselves is valid or not. For example:
Therefore, the integrity rule determines whether the function is permitted in the first place. Thereafter, the semantic rules determine whether the input data offered to that function are valid.
The data cycle test is applied to a subsystem that invoices orders and processes payments. The relevant part of the CRUD matrix is shown in the table below.
For this part of the CRUD matrix, there is one relevant integrity rule: A payment agreement may not be removed as long as there is an outstanding invoice with the relevant payment agreement. This leads to two test situations:
A brief overview notation for this type of test situation is, for example:
The initials "IR" here stand for "Integrity rule".
2- Creating logical test cases
Create 1 or more logical test cases in such a way that:
- Each entity goes through a full life cycle (beginning with 'C' and ending with 'D')
- All the test situations from the CRUD matrix (every C, R, U and D) are covered
- All the test situations of the relevant integrity rules are covered.
See also "CRUD".
A test case thus describes a complete scenario consisting of several actions, each of which perform a process on a particular entity.
In the table in this example below the logical test cases for the entities "Item" and "Payment agreement" are set out, to illustrate the principle.
The table describe at each row which function should be used, which process (CRUD) on the relevant entity is covered by this and a brief explanation with additional information on the action to be performed.
LTC02: "Payment agreement"
A "-" in the column "CRUD" means that the relevant function is required in order to carry out a certain action, but that this does not perform any processing on the tested entity. For example:
3 - Creating physical test cases
In the translation of logical test cases to physical test cases, the following details are added:
- (Optional) Exactly how the relevant function is activated. This is usually clear enough, but sometimes it requires a less obvious sequence of actions.
- The data to be entered with that function. If the logical test case indicates that a certain entity has to be changed, then the physical test case should indicate unequivocally which attribute is changed into which value.
- A concrete description with each predicted result of what has to be checked concerning a particular entity.
- Extra actions that are necessary to facilitate subsequent actions in the test case. E.g., the changing of the system date or the execution of a particular batch process in order to give the system a certain required status.
4 - Establishing the starting point
The DCyT typically operates at overall system level, possibly across several systems. That means an extensive starting point has to be prepared that is complete and consistent across all the systems. The following, in particular, should be organised:
- All the necessary databases for all the systems involved, in which all the data is consistent
- A configuration (possibly a network) in which all the necessary systems are connected and in which all the necessary users are defined with the necessary access rights.
Such a starting point approximates the production situation and is complicated to put together. Ideally, an existing real-life test environment is used. See also "Defining central starting point(s)".
In particular, attention should be paid to the data in the starting point that are only valid for a limited time. At the start of each test execution, it should be checked whether these time-dependent data are still valid and whether, on the basis of this, changes should be made in the starting point.
An overview of all featured Test Design Techniques can be found here.