[ First post on my rehosted blog – Welcome to 2026 ]
To me the last many years in leading testing activities has been in directing and leading “all the testing“. And by all the testing I mean no matter the format of the testing activity (test automation, test cases, checklists) and no matter the form of testing (security, scalability, integrations and functionality). A recent podcast by Vernon and Richard reminded me that we as Quality Engineers need to consider not only the actual IT system, but rather the system of quality.
Defining the System of Quality
I often understand the “system of quality” as the outputs and deliverables – but there is more needed for considering the full system of quality. From my work in the pharma/health/life science sector I find it similar to the organizational Quality Management System (QMS). Many companies that boast ISO27001 compliance has a QMS for all the company procedures, standards and operations. The system of quality might be part of a corporate quality management body of knowledge.
You can, though, absolutely have “System of Quality” without a formal quality management system. A system of quality can be as simple as the team wiki, where you collect the ways of working. Writing things down and maintaining them are a start to be aware about it and changing things deliberately. Come to think of it, there is always a “system of quality” – there are always factors to how quality as a construct is handled. The key lesson here is how elaborate and conscious you are about it. It’s both the explicit and implicit behavior about performing the quality engineering work. It doesn’t have to take much effort to elaborate.
One of the hardest truths in systems thinking is that your current system is producing the outcomes it’s designed to produce.
Alan Page, https://angryweasel.substack.com/p/quality-is-a-system?
The most overlooked viewpoint on “quality work” is that it’s both implicit and explicit. Quality is the perception of a relationship between a consumer and the product. Like culture and many other organizational attributes we can perceive the property, but rarely objectify it properly. As the old saying goes: Not everything that can be measured counts – and not everything the counts can be measured.
Properties of the System of Quality
There are at least the following properties in a system of quality – the people, the organization, the processes, the outputs, the technologies.
| Explicit Properties | Implicit Properties | |
| The People | Quality Engineers and Testers Software engineers Stakeholders Customer and Users | People prioritizing time, money and effort |
| The Organization | The formal hierarchy The culture and team diversity | The informal hierarchy The psychological safety |
| The Processes | Ceremonies and Project gates Procedures and guidelines Recuring meetings | What happens when no one is looking? How strict are the processes enforced? |
| The Outputs | Test results Test cases and user stories Pipelines and scripts Documents Resolved bugs | The interpersonal communications Future relationship building |
| The Tools and Technologies | Test (case) repository Work & collaboration solution Bug tracking Document management location | What you journal in the repositories and solutions |
To affect the quality outputs of any delivery team you will make real impact before you prioritize to address the properties above – both the explicit and the implicit. The key lesson here is that in order to make an impact on the quality attributes of the solution being delivered – don’t look at the quality attributes. They are merely the outcome of the System of Quality. It doesn’t matter format the testing and quality work has and what type of testing is being performed.