How to build high-quality systems with Google's theory of quality
How engineering teams can use Google's theory of software quality to enable them to build quality into their products.
Key insight
Helping engineering teams understand their nuanced views of quality can help them better see how to build quality in.
Top three takeaways
1. Google's research into developer’s views on quality can help Quality Engineers support engineering teams to build quality into processes and products by categorising quality attributes into process, code, system, and product quality.
2. Collaboratively categorising quality attributes can create a shared understanding of quality between stakeholders and help engineering teams see how their views of quality connect and why those attributes matter to those people.
3. People quality attributes such as teamwork and collaboration are foundational quality attributes to the other software quality categories, which can help improve the flow of work between them.
🎙️ I will be speaking at Testing Peers Con in Nottingham on March 17th about Psychological Safety and its link to speaking up, complexity, and high performance. Psych Safety is something that I’ve been working on for the last 2 years and plays a big part in my theory of building quality into people. The tickets for the event are priced at only £20, so it would be great to see you there if you can make it.
In the last issues of the Quality Engineering Newsletter, I shared What quality attributes do developers care about based on research carried out by Google.
From that post, I concluded:
Google's research into developers' views on quality is valuable in helping shed light on a key stakeholder's view of system quality. Through interviews and literature studies, they identified several quality attributes developers think about when considering quality. Categorising those attributes into the process, code, systems, and product quality gives engineers a framework for thinking about quality and how they can influence other system attributes.
So, how can Quality Engineers looking to build quality into their people, processes, and products use this research? Firstly, what does this research give us?
A nuanced understanding of building quality in Products
Breaking product quality down into three distinct areas of code, systems and product has quite a few benefits when considering building quality in at the product level.
Code quality allows engineering teams to focus on what they have direct control over. Concentrating on their area of control helps aid discussion on how they can make their code more maintainable with the objective of increasing their velocity.
System quality helps teams to start thinking about what quality attributes their organisation cares about. Breaking down quality into its attributes can help teams begin to connect how code quality affects system quality. This nuanced view of quality also helps the organisation see what the team doesn't control and what their dependencies are in a way that links to what the organisation values.
Product quality helps teams and organisations start thinking about quality attributes their end users care about. Teams can use product quality attributes to see how changes to the code and system could improve product quality for end users and customers.
What I like about these three different quality categories is that it's looking at quality from three different perspectives. Code quality is quality as perceived by developers. System quality is quality as perceived by the organisation, and product quality as perceived by the end users. These three categories bring a more nuanced view of quality to engineering teams.
How can Quality Engineers make use of Google's Theory of (Software) Quality
Wikipedia lists nearly 90 different software quality attributes that a system can possess. Depending on your engineering team's context, some of those attributes will be more valuable to them than others. For instance, your organisation may require traceability due to regulatory requirements, or your end user may need certain accessibility features.
To help understand what matters to who run a workshops with your primary stakeholders, ideally with representatives from developers, testers, delivery, product and actual end users if possible. To identify what quality attributes they value. Then, as a group, categorise the identified attributes into process, code, system, and product quality.
Taking the engineering team through this process creates a shared understanding of quality between the stakeholders. It helps them see how their individual views of quality connect and why those attributes matter to those people.
Creating shared meaning by categorising quality attributes can become a useful tool when stakeholders want to discuss what matters to them and see how it connects to others. For instance, engineering teams could use process and code quality metrics to help influence product managers. Helping them see that they need more time to improve quality at the code level, which will influence the system quality that the organisation values. Product managers can use product quality attributes to help frame the value of new features and help other stakeholders understand that they are not just pet projects but are there to improve perceptions of end-user quality.
What's missing from the Theory of (Software) Quality
I believe that Google's Theory of (Software) Quality is possibly too narrow as it heavily focuses on quality from the developer's perspective. Because of this narrowed view of quality, this theory is more about software quality than a quality of general software systems. A general quality of software systems would also encompass more of the socio-technical system within which the software is created.
I think a key aspect missing is the people quality attributes. The parts that happen before process quality. Here, I'm thinking about behaviours that support teamwork and collaboration, such as psychological safety, working across discipline boundaries and learning from failure.
People quality (for lack of a better term) is a foundational quality attribute of the other software quality categories. People quality attributes help support and amplify each of the other quality attributes. While you don't have to have them, they help improve the flow of work between them.
How I've been using Google Theory of (Software) Quality
I have been using the Google Theory of (Software) Quality in my one-on-one discussions with different disciplines in engineering teams. I find it helpful to use the four categories as a mental framework to visualise the various discipline concerns in these four quality buckets. I then use open questioning to broaden my colleague's perspective into the adjacent categories.
For example, I recently spoke with a Test Lead who was concerned about the end-user quality of a product, as the developers were mainly focused on making the code more maintainable. By asking the Test Lead open questions on their views of system quality and discussing how the developers focus on code quality, we could connect how each perspective was valid. From there, we found ways on how they could bring that product quality perspective to the engineers via system quality. Therefore helping both disciplines get what they wanted. Instead of each thinking, the other was overly concerned with an incorrect aspect of the system.
Another approach that I think will be fruitful is working with Delivery Managers. They are typically focused on process quality, so helping them better connect how process and code quality intersect could get better buy-in from engineering teams when suggesting changes to ways of working.
I'd also like to leverage this theory into conversations about how people quality support all the other quality attributes. I plan to use it to get more buy-in from engineering team leads on workshops such as the Five Behaviours of Teamworking for their teams (See Step 5 in Quality Engineering - The study of how quality is created, maintained and lost to learn more).
Conclusion
To be fair, Google's Theory of Quality does start to look at other aspects of software systems quality via process and product quality. I also think this research is really valuable, and it is great to see people looking into what quality means. I'm looking forward to seeing what else comes out of this research. I will also be going back through the literary review the Google researchers did as they linked to other studies on quality that could provide further insights into quality engineering.
It would be great to see what connections the researchers could draw (if any?) from Google's past research on team effectiveness via Project Aristotle and how those behaviours affect software quality.