Data Cycle Test (DCyT)

Description

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

The test situations are created from the coverage of the CRUD and from the integrity rules. Both will be further explained here.

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:
- Invalid
  The integrity rule is disobeyed. The process is invalid and should result in correct error handling.
- Valid
  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:

The rule “When creating an order, the value of quantity should not be below the boundary that is set in product” – is a semantic rule
The rule “The creation of an invoice is only permitted if the order concerned has already been approved” – is an integrity rule.

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.

Example

Data Cycle Test is applied to a subsystem that invoices orders and processes payments. The relevant part of the CRUD matrix is in the table below.

	Item	Payment agreement	Invoice	Ledger
Item management	C, R, U, D	–	–	…
Payment agreement man.	–	C, R, U, D	R	…
Ledger management	–	–	R	C, R, U, D
Invoice creation	R	R	C	U
Cash payment	–	–	C, U, D	U
Bank transfer	–	–	U, D	U
…	…	…	…	…

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:
IR1-1: Delete (D) payment agreement, while an invoice is outstanding with the relevant payment agreement
IR1-2: Delete (D) payment agreement, without there being an outstanding invoice with the with the relevant payment agreement

A brief overview notation for this type of test situation is, for example:

Test situation	Process	Entity	Condition	Valid Y/N
IR1-1	D	Payment agreement	Outstanding invoice	N
IR1-2	D	Payment agreement	No outstanding invoice	Y

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.

Example

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.

LTC01: “Item”

Function	CRUD	Action / Notes
Item management	C	Create new item ITM-01
Item management	R	Check ITM-01
Create invoice	R	Create invoice INV-01 in which ITM-01 occurs
Ledger management	–	Check INV-01
Item management	U	Change ITM-01 (e.g. price) in ITM-01B
Item management	R	Check ITM-01B
Ledger management	–	Check INV-01 is unchanged
Item management	D	Remove ITM-01B
Item management	R	Check ITM-01B (is removed)

LTC02: “Payment agreement”

Function	CRUD	Action / Notes
Payment agreement mgt.	C	Create new payment agreement PAG-01
Payment agreement mgt.	R	Check PAG-01
Payment agreement mgt.	U	Change PAG-01 (e.g. period) in PAG-01B
Payment agreement mgt.	R	Check PAG-01B
Create invoice	R	Create invoice INV-02 containing agreement PAG-01B
Ledger management	–	Check INV-02
Payment agreement mgt.	D	IR1-1. Error handling!
Payment agreement mgt.	R	Check PAG-01B still exists
Cash payment	–	Full payment of INV-02 so that INV-02 is removed (no longer outstanding)
Payment agreement mgt.	D	IR1-2. Permitted
Payment agreement mgt.	R	Check that PAG-01B is removed

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:
With LTC01, “Ledger management” is used to be able to check that the correct item appears on the invoice, but does not perform any processing itself on “Item”.
With LTC02, “Cash payment” is used to close invoice INV-02 so that integrity rule IR1-2 is complied with, but does not perform any processing itself on “Payment agreement”.

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.