What do Quality Engineers do?
In What is Quality Engineering? I began laying down some of the foundations of what is a Quality Engineer:
A quality engineer is someone who works to solve quality problems and inefficiencies to improve software systems. Specifically by applying their knowledge of how quality is created, maintained and lost at the levels of products, processes and people. Or, to put it more succulently, a quality engineer enables software teams to build quality at the source.
In this post, I'd like to expand on what Quality Engineers do and explore ideas on how they work.
What is a Quality Engineer?
Many people view Quality Engineers as just another name for a Tester and believe they do the same job. While there may be some overlap, I see the roles trying to achieve different outcomes. A Tester approaching their work in the simplest way report on the system's quality through testing. Only reporting on quality is a massive simplification of what Testers do, and a good Tester will do much more than report on quality. But if you boil a Testers' work down, it is typically there to report on the system's behaviour. Everything else a good Tester does is what adds value to that reporting.
Whereas Quality Engineers work with teams and departments to enable them to build quality into their work. By trying to make the system in which people work healthier so that the environment is more conducive to better quality outcomes.
Quality Engineers do this by bringing a socio-technical system thinking mindset to their teams and departments.
Socio-technical Systems Thinking
From Socio-technical systems theory | University of Leeds:
...any organisational system can only be understood and improved if both ‘social’ and ‘technical’ aspects are brought together and treated as interdependent parts of a complex system.
System thinking
Software is built and maintained by people who work towards specific goals and metrics. They may follow certain processes and procedures to develop and maintain the software and use tools to help them do so. For instance, an IDE to write the code, Slack for communications and GitHub to manage their code. They may work in specific environments such as a company office, a shared workspace or from their dining room dinner table. All while following certain cultural norms and assumptions, e.g. starting and finishing work by a particular time or taking turns to speak in group settings.
Socio-Technical Systems Theory
These areas (people, goals and metrics, process and procedures, tools, environments, and cultural norms) are systems. We have systems of people, e.g. a group of multidisciplinary people forming a team to build and maintain the software. The processes and procedures we follow are systems such as scrum, extreme programming or kanban. Even the environments we work in are systems that rely on certain types of infrastructure to be present for them to function, e.g. electrical and water systems. Some of these systems are technical, e.g. tools and environments, while others are more social, e.g. people and culture.
Each of these sub-systems interacts with each other but not linearly. Instead, they are all interconnected and interdependent and so when you pull and push at one of them, the others will respond accordingly.
Complexity Theory
Each sub-system will interact with others, producing behaviours that are often hard to predict or replicate. And it's this interaction of sub-systems that leads to software being a complex process.
We can better understand that complexity by looking at how the sub-system interacts with one another. These interactions could be described as patterns of operating. A Quality Engineer's role is to work with the people in the system and identify which patterns are most likely to produce the desired quality attributes. But also which patterns maintain or destroy the quality outcomes we want.
In this way, quality is an emergent behaviour of complex software systems.
Quality is Emergent
One aspect of quality we often miss is that quality is an emergent system behaviour. You can not inspect the individual sub-systems and deduce the overall quality attributes of the more extensive system. You have to take a holistic view of the sub-system components and their interactions to understand how the system behaves and, therefore, how its quality attributes are likely to manifest. Taking a holistic view, in time, allows Quality Engineers to identify the patterns in which the system operates that are more likely to result in the quality attributes we desire.
An essential task for Quality Engineers is helping the people in the system create the conditions more likely to give us the quality attributes we want, which is how Quality Engineers enable teams to build quality at the source.
But how do Quality Engineers enable teams to build quality at the source if quality can only be observed after the fact?
Creating Healthier Systems through a Learning Mindset
A critical point about quality being an emergent behaviour is that we only know we've successfully created the patterns for quality attributes we want after we've done the work. This can lead people to conclude that the only way to assess quality is by using real-time end-to-end testing.
If you're working with unpredictable systems whose behaviour keeps changing, end-to-end testing is a good strategy to reduce uncertainty. But usually, this will not be the case for software systems. Software system's behaviour typically only changes if it receives input it was not built to handle, or something changes the code base. Both of which can be tested for using code-level tests. Making the software system more predictable and therefore lowering your uncertainty.
Where this gets tricky is the other parts of the system, e.g. people, culture, infrastructure, for instance, whose behaviour can be anywhere from certain (your office is pretty fixed) to uncertain (people can have bad days which affects their mood and performance levels). Putting tests around these sub-systems can be difficult, and taking a socio-technical system view means they can't be ignored as it's the only way to understand and improve a system.
This is where the idea of creating healthier systems comes in. We can't control or know all the variables that affect a complex socio-technical system. But we can observe the system, identify its patterns of operating and run experiments to see how we can increase the chances of the conditions we want to occur.
Another aspect we also need to consider is failure. Due to the complexity of the system, failure is highly likely. So we need to work with failure by constantly learning while doing the work. With the view of how we can make the system healthier than when we started. A healthier systems view brings a much more experimental and iterative mindset, enabling Quality Engineers to help software teams to build quality at the source iteratively.
Building Quality at the Source
Taking a socio-technical systems thinking approach makes it clear that no person could ever build quality into the system, let alone tell others how to do it. The only way to do so is through learning how the system creates the quality conditions in the first place and collaborating with all stakeholders involved to make it happen more often than not. Now this can appear to be an impossible task. But we should remember that this vast socio-technical system functions to create the product or services in the first place. So the organisation can do it.
By applying a Quality Engineering mindset to make the system healthier, we can nudge and boost aspects to produce the quality attributes we want, which can be the seeds that grow into a culture of quality throughout an organisation.