Approach Coverage based - Data
Test variety
  • Functionality
  • Suitability
  • Connectivity
Test basis
  • CRUD matrix
  • Functional design and/or
  • Detailed domain knowledge


The data that are stored and maintained in the system under test have a life cycle. This starts when an entity is created and ends when it is removed. In between, the entity is used by updating it or consulting it.

An overview of the life cycle of the data, or entities, is obtained with the aid of a “CRUD matrix”. This is a matrix in which the entities are shown horizontally on the axes and the functions vertically. The matrix is filled in using the letters C(reate), R(ead), U(pdate) and D(elete). If a function executes a particular action in connection with an entity, this is shown in the matrix by means of a C, R, U and/or D.

  Invoice Article ...
Management of articles -

C, U, D

Create article C


Desk payment

C, R, D

- ...
... ...



Testing of the life cycle

The testing of the life cycle consists of 2 parts: the completeness check and the consistency test. These are explained below:

Completeness check

This is a static test, in which it is examined in the CRUD matrix whether all 4 possible actions (C, R, U and D) occur with every entity. In other words, has the entire life cycle been implemented for every entity? The lack of an action does not necessarily mean that the system is wrong. However, the reason for it at least requires investigation.

Consistency test

This is a dynamic test aimed at integration of the various functions. This checks whether the various functions use an entity in a consistent way. In other words, is the relevant entity being corrupted by one function in such a way that it can no longer be used by the other functions correctly?
Test cases are derived by putting together an entire life cycle of an entity. This is done as follows:

Every test case starts with a “C”, followed by all the possible “U”s and ending with a “D”. If there are further possibilities of creating or removing an entity, additional test cases are designed
After every action (C, U or D), an “R” is carried out once or more. This is to establish that the entity has been correctly processed and is usable for the other functions (has not been corrupted)
In respect of the relevant entity, all the occurrences of actions (C, R, U and D) in all the functions should be covered by the test cases.

With this, CRUD is fully covered in principle.

More thorough coverage of CRUD can be achieved by requiring that combinations of actions also be fully covered. For example, by requiring that after each “U” all the functions with an “R” should be carried out.

Testing CRUD is often combined with testing Integrity rules.