Quality was, is and remains a challenge within the IT industry. The DevOps team must actively work on quality engineering. Quality engineering consists of a great number of possible activities, the so-called quality measures. After all, quality must be built in, not tested in! Within quality engineering, testing is the instrument that can provide insight into the quality of information systems, so that test results deliver a contribution to the improvement of the quality of information systems and thus to delivering the pursued business value.
All quality measures may relate to all DevOps activities
Quality measures do not apply to one specific DevOps activity; they are integrated with all DevOps activities.
Applying these measures leads to a situation whereby:
- there are measurement points and units that provide an indication of the quality of the products and processes
- it is clear to each team member which requirements his work must meet and that he can evaluate them based on the quality criteria
- it is possible for an independent party to evaluate the products/services based on the above-mentioned standards
- the product owner and other stakeholders can trace the causes of weaknesses in products or services and consider how they can be prevented in the future.
Three groups of quality measures
Quality measures are divided into preventive, detective and corrective measures:
- Preventive quality measures
Preventive quality measures are meant to build quality in from the start. Thus they are aimed at preventing a lack of quality. These can be, for example, documentation standards, methods, techniques, training, collaboration techniques such as pair programming, etc.
- Detective quality measures
Detective quality measures are aimed at demonstrating the quality level (also called measuring the quality level). These quality measures are static testing (reviews, code analysis) and dynamic testing (test design, test execution, assessing the outcome).
- Corrective quality measures
Corrective quality measures are aimed at improving the quality level, such as refactoring code to improve maintainability, feature toggles to facilitate responding to problems, or the investigation of anomalies and fixing problems that have been exposed by means of testing.
It is of vital importance that the various quality measures are cohesive. No single quality measure is an independent activity; it is only a small cog in the quality management wheel. Testing, for example, is only one of the forms of quality control that can be employed. Quality control is in turn only one of the activities aimed at guaranteeing quality. And quality assurance is, in the end, only one dimension of quality engineering.
For more information about how to assign quality measures please refer to Quality Engineering Strategy. A list with over a hundred examples of quality measures can be found in the Quality Engineering Strategy template.
Overview of quality measures
The quality measures can be used as part of quality engineering. Also, they contribute to covering risks, as described in "Quality risk analysis & test strategy".
For a detailed description of these quality measures we refer to Quality measures and skills.
The quality measures that are described are:
- Root cause analysis (RCA)
- Specification and Example (SaE)
- Test-driven development (TDD)
- Pair programming
- Test design techniques
- Feature toggles
- Parallel testing