Are We Really Quality Professionals?
Why a 25-year career shift made me rethink a title that millions of software testers take for granted
After roughly 25 years of working in software testing on a regular basis, I no longer work in testing at all. Today, I work for the Dutch government, where I assess large-scale projects to determine whether they are being managed effectively and advise them on how to improve their governance and control. In these reviews and advisory engagements, testing is only occasionally a topic of discussion.
When you step back from testing, as I have, you start noticing things that previously seemed perfectly normal. One of those things is the use of job titles by testers that include the word quality: QA Specialist, Quality Officer, Quality Engineer, and similar variations. For the sake of simplicity, I will group all of these titles under the umbrella term quality professional.
The reasoning behind these titles is familiar to most testers, and it was to me as well until recently. The argument goes something like this: by identifying defects and issues, testers help improve product quality, provided those issues are addressed. Therefore, we contribute directly to quality. In the minds of many testers, that makes us quality professionals.
There is no question that a system’s quality improves when the defects we identify are resolved. But does that automatically make us quality professionals?
From the perspective of my current role, the answer is no.
The concept of quality in my current environment is far broader than product quality alone.
Quality Assurance Beyond Testing
In my current context, every major project has a Quality Assurance Officer. This person organizes a wide range of activities aimed at assessing and, where necessary, improving quality. These activities include peer reviews, formal assessments, delta reviews, milestone reviews, and other independent evaluations.
The focus of these reviews can vary considerably. They may examine governance structures, project progress, stakeholder engagement, business feasibility, technical viability, or other factors that influence a project’s likelihood of success.
Interestingly, testing is rarely a primary focus of these assessments.
Occasionally, I interview someone involved in testing. This isn’t because testers have a special role in quality assurance activities, but because they often possess valuable insights into how a project is actually performing. They see problems, risks, and inconsistencies that others may overlook.
However, from a roles-and-responsibilities perspective, testers do not occupy a privileged position within these quality assurance activities. The primary objective of these reviews is project quality: determining whether a project is likely to achieve its goals successfully.
Quality at the Organizational Level
In my current environment, we also have Quality Officers. Their responsibility is quality at the organizational level, with a strong focus on processes rather than products.
Examples include:
Program and project management processes
Lifecycle management processes
Security processes
Privacy processes
Data management processes
In practice, these Quality Officers almost never deal with testing. Their focus is ensuring that organizational processes are defined, followed, measured, and continuously improved.
Three Different Types of Quality
This is why the claim that testers are quality professionals does not fit well within my current context.
Here, testers are simply testers. Their responsibility is to independently determine whether a system behaves as intended. That is an important responsibility, but it is also a specific and limited one. The responsibilities of the quality professionals around them are significantly broader.
You could argue that there are at least three distinct types of quality:
Product Quality: Whether the system itself meets expectations and requirements.
Project Quality: Whether the project is being managed in a way that maximizes the likelihood of success.
Process Quality: Whether the organization’s processes are effective, controlled, and continuously improving.
Testers certainly influence product quality, although they are by no means the only professionals who do so. Developers, architects, product owners, business analysts, and many others contribute as well.
When it comes to project quality and process quality, however, testers in my current context have little or no direct responsibility.
A Claim Worth Questioning
Perhaps that means we should be more careful when we describe ourselves as quality professionals.
If quality encompasses product quality, project quality, and process quality, then most testers operate primarily within only one of those domains. While our work can contribute significantly to better products, that contribution alone may not justify claiming ownership of quality in its broadest sense.
At least in my current environment, that claim is difficult to defend.
Testers are not quality professionals because they improve quality. They are testers because they provide independent information about quality, and there is a meaningful difference between the two.
Jan Jaap Cannegieter is an IT Advisor for the Dutch Government with over 30 years of expertise in software testing, quality assurance, and business analysis. A recognized international expert, he has twice featured as a speaker at the prestigious Pacific Northwest Software Quality Conference (PNSQC).
 | A guest post by
|