DevOps Test – Test patterns

Test patterns Introduction

Actually, the creation of test cases is for a large part waste. If all test cases are compared well with each other, test patterns can often be recognized. Inversely, if test cases were to be derived from a pattern, the coverage of test cases could be much higher. This article addresses the aspect test patterns.

Test patterns – Definitions

Pattern

A pattern is a generic solution for a generic and recurring problem. By analysing the problems a DevOps team faces and the way they solve their problem, patterns can be created and shared with other DevOps teams by telling stories. This article gives some test patterns for the way in which DevOps teams can be organized.

Test patterns – Concepts

Pattern language

Patterns can often be linked to a pattern language. This means that test patterns together provide a generic solution for higher generic problem.

Test patterns – Best Practices

Test cases are used to test objects for their functionality and quality. An object can be a product or service. However, objects are not unique. For example, a table in a database is a set of objects: Primary key, Foreign keys, Attributes, Index and Constraints. If a table is to be tested then there are certain types of test cases to be considered. For a next to be table tested, then all test cases can be reconsidered. It is better to assume that a table is tested based on test patterns. This article deepens on that pattern idea.

Pattern maturity

Learning to work with test patterns takes time. But soon, much time and money can be recovered. The following stages can be identified:

1. Pattern recognition
2. Test Patterns risk
3. Pattern test case
4. Generate test cases

Ad 1. Pattern recognition

Define a pattern for an object that need to be tested frequently and that include many test cases. Define a name for the test patterns. Create a checklist to make sure the test set for the object is complete. At least the next time that such an object has to be tested there is already a checklist to test the completeness, see the example table 1.

Example Pattern TableCreation

Object	Checklist
Table	Data model adjusted and provided with a version
Table	DDL script created and provided with a version
Table	Table was created
Table	Index has been created
Table	Trigger was created
Table	View was created
Table	Basic DML scripts have been created

Table 1, Example Pattern TableCreation.

Ad 2. Pattern risk

Analyse a well-tested object for which parts have been tested. Perhaps a good start has been made in the previous step (pattern recognition). Then determine which risk aspects are now controlled by the test cases. In general, this is an extension of step 1, in which mainly the deliverables are checked. This step goes further and therefore requires an expert’s view. The next time that such an object has to be tested, there is already a list of risks that must be controlled.

Example Pattern TableCreation risks

For a table, identify the following components and identify risks. For example, double entry of the same unique key or filling in a null value for a non-null attribute. Then attach the risks per component to a table. The question of whether a risk should be tested depends on the probability * impact. Because eventually the test cases are generated, the effort of controlling the risks over a longer period will be nil.

Object	Part	Risk
Table	Data model	Wrong cardinality
Table	Data model	Synonyms
Table	Data model	Homonyms
Table	Data model	No version management
Table	DDL script	No version
Table	DDL script	Incorrect database used
Table	Table	Failure to comply with the naming convention
Table	Table	Wrong rights are set
Table	Attribute	Does not allow null values
Table	Index	Is not clustered
Table	Index	No unique index
Table	Trigger	Does not delete child records
Table	View	Includes too few fields
Table	DML	Has no exception handling

Table 2, Example Pattern TableCreation risks.

Ad 3. Pattern test case

Define a test frame for each object and each risk. A test frame is a test case whose unique value is replaced by variables. Put all test frames in a test frame set. The next time an object needs to be tested, it is sufficient to fill in the variables of the test frame set.

Example Pattern TableCreation logical test cases

Table 3 shows the logical test cases of the identified risks from Table 2. These logical test cases must still be converted to physical test cases. In order to define the physical test cases reusable, they must be provided with variables.

Object	Part	Risk	Test case
Table	Data model	Wrong cardinality	Manual: Check the relationships between the entity types.
Table	Data model	Synonyms	Manual: Verify the entity type and attribute types name on uniqueness in the corporate data model.
Table	Data model	Homonyms	Manual: Verify the names of the entity type and attribute types if they already exist under a different name.
Table	Data model	No version management	Automatic: Check if the data model extraction contains a version number.
Table	DDL script	No version	Automatic: Verify that the DDL script has a version.
Table	DDL script	Incorrect database used	Automatic: Verify that the DDL script begins with Use <database>.
Table	Table	Failure to comply with naming convention.	Automatic: Verify that the names of all objects comply with the naming convention.
Table	Table	Wrong rights are set	Automatic: Verify that the specified roles have rights to insert, update, delete and select records.
Table	Attribute	Does not allow null values	Automatic: Verify that the attributes correctly allow or nullify.
Table	Index	Is not clustered	Automatic: Check the DDL statement for the occurrence of one index that is clustered.
Table	Index	No unique index	Automatic: Enter two records with the same key values.
Table	Trigger	Does not delete child records	Auto: Delete a record and check if the underlying table has a child record.
Table	View	Includes too few fields	Automatic: Compare the data model script with the DDL script.
Table	DML	Has no exception handling	Auto: Make an error on an integrity rule and check the error message structure.

Table 3, Example Pattern TableCreation logical test cases.

Ad 4. Generate test cases

The final step is that by completing the pattern and variables the test system generates the test cases. Possibly supplemented with additional unique test cases.

Pattern language

The pattern of a table can be extended with the pattern of an ETL function et cetera. Based on the fact that patterns are used always in a certain combination a patterns language can recognized and used.

Discuss with us about this article on LinkedIn.

More information

Related Books:

DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807

Related training sessions:

• DevOps Foundation
• DevOps in practice
• DevOps Master
• Masterclass DevOps Operations
• Masterclass DevOps Application Development
• Masterclass DevOps Architecture

Related Article:

Service Management