I would like to share a model I have used for several years in my previous companies to describe the different perspectives on quality and how they relate. I also want to show where testing activities fit within these perspectives and where testers can use their skills.
Here is the model I call the “8 perspectives on quality”. (Below is a description of the rows and columns.
The three columns represent the stages of the product/software at a very high level: ideating (left), implementing (middle), and maintaining/supporting in prod (right).
The columns with colored letters refer to a particular point of view about quality:
The green boxes are an external view of the implementation, support/maintenance, and ideation phases of the software. These boxes represent the customers and users perspectives on these stages.
The blue boxes are an internal view of the implementation, support/maintenance, and ideation phases of the software. These boxes represent the perspectives of both the business and the teams regarding each stage.
The purplebox is an indicator that each team’s quality affects the boxes below (i.e. The teams’ work processes, methods, cultures, skillsets and maturity. The purple arrows indicate the relationship between the team’s quality attributes and the green and blue boxes.
The red box at bottom shows that the quality attributes of an org can have an impact on the attributes of a team (i.e. The org structure, values and principles, leadership support, leadership style, culture and leaning mechanisms as well as the systems for diversity and inclusion. The red arrows are similar to the purple arrows. They represent the relationship between the quality attributes of an organisation and the quality attributes of teams in the purple box.
Each coloured box contains details about the quality of the product from that particular point of view. This is a great time to go back and reflect on each detail within the model.
While you are reflecting, remember that each model box is subject to the Goodness Value and Correctness quality aspects.
Some of these perspectives can also clash…
I have had conversations firsthand about how an idea could be good for the business. It would increase conversions immediately. However, on the other hand, users would suffer long-term anxiety. Our testing revealed that it would make users anxious.
This is just one of many similar stories I have. Most common is the compromise between trying to deliver features quickly to business reasons at the expense of quality for users by not putting a thorough through towards balancing and the ETTO Principle.
It has helped me to see the many ways that different testing activities can be viewed from different angles.
These testing activities are not exhaustive. You might have other activities you could use in your context. These can be added to the model to help teams see the value of testing from all perspectives.
This leads to the question of…
As a tester, where do you fit in the model?
If you’re a tester for a developer, some of these might be familiar to you.
You might not like some of the things you see.
To demonstrate where my testing skills have been used throughout my career and to make an impact across these 8 areas, I’ve incorporated the roles into the model.
It’s evident that testers are familiar with the blue and green merged boxes in the middle column. A lot of the testing done by testers is related to the software’s implementation after all.
For me, however, the evolution of my role as a tester really boils down to us getting traction in the other boxes.
Consider yourself a DevOps tester, where you are closer to the worlds of observation and incident management ( The blue and green boxes on right).
Think about the growing movement in our craft to “shift left”. Many blogs about shifting left, while addressing the issue of shifting left, often only begin by testing requirements. My model is evolving to take the idea of the product/feature a little further. The principle remains the same. You can evolve your testing from these perspectives by testing ideas, AB experimentation and so forth.
Think about the role of quality coach/quality advocate, which clearly focuses upon the purple box.
Companies are increasingly taking on more senior leadership roles in quality management: director of quality, head of quality, or vice-president of quality. These roles are organisational strategic levels and cover a wide range of items in the red box.
My stance is that the more you spread across the boxes of the model, the better it fits my thinking about the role and responsibilities of the Quality Engineer. This is not “engineering” as in building things. More “to engineer” in the sense that you orchestrate the injection of quality into these things by assessing their quality and relaying the information from your testing . You can also share your ideas on how to improve them through collaboration and conversations within those activities.