Quality engineering consists of many activities. Some people seem to think it’s only about testing, but that’s just one aspect of the activities in the IT delivery process. In the 1980’s testing was seen as an activity at the end of the IT delivery activities to find the faults that were introduced in previous phases, and fix them. In four decades, I witnessed the evolution towards quality engineering where an IT delivery team takes joint responsibility for building-in quality from the start, in order to deliver business value with quality at speed. With this attitude, the main objective of testing is to demonstrate that the quality indeed is at the required level.
What is quality and why would we want it?
What is quality?
Quality is defined as: “the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.”
How much quality is enough?
In today's world many people and organizations rely on IT systems, many things would not be possible without IT systems. So, we need to be able to trust that these IT systems are working good enough to support business processes. This means that the quality must be at the level that fits the purpose and delivers business value.
If we want to know if our IT system indeed satisfies the needs, we must measure the quality. We need to define quality indicators and measure these indicators. Most of this measuring is a testing task. Since in Scrum or DevOps, quality is the responsibility of the whole team, this measuring of indicators can be done by any team member that has the required quality engineering skills.
Quality engineering is about taking joint responsibility
Quality engineering is defined as:
“Quality Engineering is about team members and their stakeholders taking joint responsibility to continuously deliver IT systems with the right quality at the right moment to the businesspeople and their customers. It is a principle of software engineering concerned with applying quality measures to assure the quality of IT systems.” (source: the TMAP book “Quality for DevOps teams”).
When applying an Agile mindset with or without a Scrum framework and/or when working in a DevOps culture, TMAP talks about High-performance IT delivery. This is defined as: “High-performance IT delivery is an approach that enables cross-functional teams to continuously improve the products, processes and people that are required to deliver value to the end users.”.
To measure the quality of the IT system we use indicators. Measuring indicators is done for example by testing. Testing is defined by TMAP as: “Testing consists of verification, validation and exploration activities that provide information about the quality and the related risks, to establish the level of confidence that a test object will be able to deliver the pursued business value.”
Quality is the responsibility of the team and high-performance IT delivery is today’s way of implementing IT delivery. What does that mean for the organizations and people involved?
High-performance quality engineering: Why?
Organizations today cannot exist without information technology (IT). In 2020 we learned that silicon chips (in smartphones, tablets, laptops, etc.) keep the world turning when people can’t travel to get together.
The first computer was created almost 80 years ago. And for about half a century IT was the territory of technical people only. Since the 1990’s businesspeople started to get used to what IT could do to achieve business value. Today they don’t want to be bothered by technical talk, they want business value and they want it fast. So, IT delivery teams need to adjust. It is exactly 20 years ago that the Agile manifesto was written by a group of visionary IT people. “We are uncovering better ways of developing software by doing it and helping others do it.” they said. Their vision has inspired many new approaches, but organizations still often struggle with implementing such new ways of high-performance IT delivery.
High-performance quality engineering: Who?
To properly implement a DevOps culture, the people need to organize themselves in cross-functional teams. The main goal of this type of organization is that teams are, to a certain degree, autonomous. Which means the team members together have all skills, knowledge, and facilities to perform their tasks. This makes that they can execute almost any of their tasks without support from outside the team. To be able to work as a truly cross-functional team all team members are allowed to pick up any task, so they regularly switch roles. A team member for example can pick up a development task at one moment in time and perform a testing task at another moment. Also, the team members apply various quality measures, such as “pairing” in which two team members pick up one task together. Applying such quality measures enables them to quickly deliver the right quality, and at the same time improve their skills by learning from each other.
And this brings us to one of the core concepts of high-performance cross-functional IT delivery teams: they constantly strive to improving the product (IT-system), process (for IT delivery) and people (both individual and team skills).
High-performance quality engineering: How?
To implement this continuous improvement focus in your Agile, Scrum or DevOps organization TMAP introduces the concept of “quality engineering”. Quality engineering is very broad, it encompasses quality assurance and testing, but also other engineering and IT delivery activities that relate to creating built-in quality. With today's wide variety of IT delivery models in mind, in our book “Quality for DevOps teams” we have described a common set of topics that are always relevant for quality engineering, regardless of the IT development, operations and maintenance approach that is followed by the organization. The way these topics are addressed in your situation depends on many factors, not in the least by the IT delivery model you use. I am convinced, however, that for effective and efficient QA & testing, all of these topics need to be addressed in one way or another.
While describing the topics we noticed a distinction should be made about the kind of activities a topic relates to. This resulted in two overarching groups: Organizing topics and Performing topics. The organizing topics are aimed at orchestrating, arranging, planning, preparing, and controlling the quality engineering activities. The performing topics are aimed at the actual operational quality engineering activities. (This division is not purely black-and white, some topics are mostly organizing and somewhat performing or the other way around.)
The future of quality
In the four decades that I am personally experiencing the development of quality in information technology, I have seen that IT systems have become much more connected and complex. Therefore, quality assurance needed to evolve from “finding errors and fixing them” towards quality engineering where teams take joint responsibility for “built-in quality”.
And now that the focus is on business value, you may wonder, what will be next?
My expectation is that the IT-world will see a further evolution toward “purpose”. Business value is rather materialistic, purpose addresses doing good for the company, society and our planet as a whole. In the near future we will see how this will further develop the quality engineering practice. In this new development of quality engineering new technology will also play a major part, especially Artificial Intelligence (AI). These intelligent machines will go through three stages of supporting quality engineering. Currently AI is mainly good in descriptive analytics; machine learning algorithms analyze massive data sets and derive information from that. Next there will be predictive analytics, that (based on the analysis done in descriptive analytics) will predict the future level of quality. Finally, we will see prescriptive analytics where AI supports quality engineering by prescribing what actions need to be taken to ensure that the quality stays at the pursued level. And even AI may trigger actions automatically if the quality is at risk!!
My conclusion is that the quality of IT systems remains as important as ever, but other IT systems will automatically guard that quality and people in IT only need to use their imagination to invent new applications of IT to pursue purpose!
Happy quality engineering!!
[This article was also published in SQ Mag nr. 12]
Published: 5 October 2022
Author: Rik Marselis
