|APPROACH||Coverage based - Data|
Integrity rules describe the preconditions under which certain CRUD 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 coverage of Integrity rules has a strong relationship with the coverage type CRUD (Create, Read, Update, Delete). They can very well be applied together.
Since the integrity rules can be described as decision points, decision coverage can be applied.
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. This means that for each integrity rule, two test situations are derived:
- Invalid: The integrity rule is not met. The process is invalid and should result in correct error handling.
- Valid: The integrity rule is met. The process is valid and should be executed.
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
A brief overview for this type of test situation is, for example:
IR: Integrity rule
Wiki's - Coverage types:
- Right paths / fault paths
- Decision points
- Equivalence classes
- Boundary value analysis
- Orthogonal arrays and pairwise testing