In my last blog post, I shared my views on quality regarding goodness, value, and correctness. In this post, I’d like to share a model that I’ve been using for a few years in my past few companies, to describe different perspectives of quality and how they relate, as well as where testing activities fit across these perspectives, and where testers can apply their skills too.

Here’s the model, which I’m calling the “8 perspectives of quality”. (Below the model is the description of what the rows and columns represent).

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 coloured columns relate to a specific point of view regarding quality:

The green boxes represent an external view regarding the ideation, implementation, and support/maintenance of the software (i.e. the users’ and customers’ perspectives regarding these stages of the product).

The blue boxes represent an internal view regarding the ideation, implementation, and support/maintenance of the software (i.e. the teams’ and business’ perspectives regarding these stages of the product).

Underpinning that, the purple box represents the point of view that the quality of each team’s attributes affects the quality of the boxes above (i.e. the teams’ processes, ways of working, culture, skillsets, maturity, communication and collaboration styles, diversity, etc). The purple arrows represent the correlation between the quality of the team’s attributes affecting the quality of the green and blue boxes.

And finally, the red box at the bottom represents the point of view that the quality of the org attributes affects the team attributes (i.e. the org structure, values, principles, leadership support and leadership style, the culture, the leaning mechanisms, and even the org systems around recruitment, diversity, and inclusion, etc). And likewise with the purple arrows, the red arrows represent the correlation between the quality of the organisation attributes affecting the quality of the teams’ attributes in the purple box.

Within each coloured box lies some details about quality in that context of point of view at that point in the product’s stage. Now’s a good point in time to browse back up to reflect on the details in each box within the model.

And while you reflect, also take note that the Goodness, Value and Correctness aspects of quality also apply to each box in the model too!

Additionally, some of these perspectives often clash…

I’ve been in conversations, firsthand, about how an idea that seemed good for the business and would admittedly increase conversion immediately, as proven through a short-term AB test, however on the other side, it was also discovered to be detrimental for users in the longer term, with our testing discovering that the feature would cause anxiety for users over time.

There are many related stories like this that I have. The most common probably relates to the balance between trying to deliver features quickly for business reasons, at the detriment of the quality for users, by not putting a through towards balancing the ETTO Principle.

I’ve found that overlaying different testing activities on the model helps people to understand the several ways in assessing quality across the different perspectives.

In no way are the testing activities I’ve listed in the boxes exhaustive. There are many more activities that you might use in your own context that you can overlay onto the model to help your teams understand the value of testing across the different perspectives.

Which leads nicely into the question of…

Where do you fit in this model as a tester?

Some of this might be remarkably familiar with what you do in your role if you are a tester of a developer.

Some of it might not… And you might feel like your job doesn’t fit there.

To show where I have used my testing skills throughout my career, to make an impact across the 8 areas, I’ve overlaid the various roles into the model:

I think it’s obvious that most testers will commonly associate with the middle column’s blue and green merged box – a lot of the test done by a tester does relate to the implementation of the software after all…

However, for me, the evolution of the role of a tester is really about us gaining traction into the other boxes.

Think about being a tester in a DevOps culture, where you’re much closer to the world of observability and incident management (the blue and green boxes on the right).

Or think about the increasingly common movement within our craft about “shifting left” – yes, many of the blogs you’ll see about shifting left often still only really begin with testing the already formed requirements. Whereas my model is evolving that this a bit further to the idea of the product/feature. But the principle is the same. Evolving our testing across these different perspectives through testing ideas, testing through AB experimentation, etc.

And think about the role of a quality coach or quality advocate, which clearly focuses on the purple box.

And it’s becoming more common for companies to be taking on senior leadership quality roles: “head of quality” roles, “director of quality” roles, or even “VP of Quality” level roles. These organisational strategic level roles spanning the vast array of items in the bottom red box.

From my stance, the wider you span across the boxes in the model, this is what fits with my thinking around the role of the “Quality Engineer”. Not “engineering” in the sense of hands-on building something. More “to engineer”, in the sense of orchestrating the injection of quality into all these things, through assessing the quality of them and relaying that information you discover from your testing, along with sharing your ideas on how to improve the quality of them through conversations and collaboration within those activities.