CRUD

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. This is illustrated in a CRUD-matrix, as below example.

Creating a CRUD matrix

In order to create the CRUD matrix, all the functions in the system are reviewed. For each recognised function, one needs to determine: 

• Which entities are used by this function
• Which actions (C, R, U and/or D) are carried out on these entities.

The result of this is entered in the matrix.

The use of the CRUD matrix is preferably not delayed until during the testing, but should be delivered as part of the system development by the developer, for the creation of a CRUD matrix is not only useful to testers, but also to the developers themselves: the designing of an information system is usually reasoned from within the functions. Per function, it is described which data will be used. In the creation of a CRUD matrix, reasoning takes place from within the data. Per entity, it is described which functions will use the relevant entity in which way. By creating such a cross-reference table (CRUD matrix) anomalies and/or incomplete areas are sometimes brought to light that would probably not be found with a function-orientated approach, whereas they are now found at an early stage.

Testing 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.

The example below illustrates this:

Testing CRUD is often combined with testing Integrity rules.