This post is a (more detailed) response to a post on LinkedIn by my good friend and colleague Antti Niittyviita. My intention is not to chide or scold him. Instead, I want to shine light on a problem in the way many people talk carelessly about the craft of testing, and to express my ongoing dismay. It’s not a new problem, but it sure is a persistent one.
Antti says…
I had a meeting recently. A leader, frustrated, said, “Our product quality isn’t cutting it. We need better Quality Assurance.”
It struck me. This is a common narrative, but is it right?
Quality in software isn’t a QA output. It’s deeper.
Quality is the byproduct of the whole development process.
Think about it. Quality isn’t an add-on. It’s not a final step. It’s the essence of creation. Part of all that you do as an individual or organisation.
Every design decision, every line of code, it’s all a part of quality. Right?
QA does it’s part by finding, hilighting and empowering the team to fix problems that potentially have negative consequences for the quality in the end.
The confusion between testing and assuring quality expressed in Antti’s post here is a natural outcome of people in software development who stubbornly refuse to drop the bogus, pretentious, and profoundly misleading title “Quality Assurance”.
As Antti is trying to point out, quality assurance doesn’t come from “QA” — a pandemically common misnomer for testing, testing activity, and testers themselves. Idioms are a normal and natural part of speech, but we must be careful with them. Trouble arises when there’s confusion between an idiom and what the idiom’s words actually mean.
Today I learned that when we go way back, “idiom” comes from the Greek word idioma, meaning to make one’s own, to appropriate. I’m imagining some daffy test manager deciding to appropriate the term “quality assurance” in a self-aggrandizing way to grab credibility — or perhaps some irresponsible project manager deciding to make quality assurance the testers’ own responsibility —and lo, yet another deceptive and confusing software development term was born. However it might have started, branding testing as “quality assurance” conflates a precursor for a set of activities with the entire set of activities.
In the Rapid Software Testing namespace, we have adopted and adapated Jerry Weinberg’s way of putting it: quality is value to some person or persons who matter. Quality depends on making or doing things that provide value to people, and on addressing problems that threaten that goal. Quality in software isn’t a byproduct of a quality assurance process; it’s the product of that process, as expressed in a socioptechnical system that includes software.
If you intend to develop a product that is valuable to people and there are problems achieving that value, then some kind of change to your quality assurance process is exactly what’s required to address the problems.
Antti says “Quality in software isn’t a QA output”. Yet quality in software is precisely an output of a QA process—a quality assurance process. Unless words and meaning have suddenly decided not to share the room, a quality assurance process is a process that assures quality. It stands to reason that if the leader in Antti’s story is frustrated about quality, then better quality assurance is exactly what the leader needs. What Antti means is that quality in software is not an output of testing.
That makes perfect sense. Neither a financially sound company nor a good fiscal year is an output of auditing; an assessment and a report on the company’s finances is, whether that company is in good shape or not. Neither the auditors nor the report will keep the company on a good footing. Management and workers’ actions — including their responses to audit reports — will.
Healthy people are not an output of a pathology lab in a hospital; a diagnosis of their condition is, whether they have a disease or not. No one in the pathology lab will make the patient better, but armed with the lab’s test results, the doctors and the patient can target potential health problems more accurately.
Responsible, ethical government is not an output of investigative journalism, nor of a government auditor; journalists assess and report on the state of the government; auditors on its spending. Neither a report nor the people who wrote it will change the government, but the government can use the report to target overspending, corruption or policy lapses — or the voters can use the report to inform a choice about who should be in change of things.
Testing isn’t quality assurance; testing informs quality assurance. Testing’s role in the development process is to examine and experiment with the product— and with ideas about it — to find out where and when things might be going wrong, and what those things might be.
Testing does not assure the quality of the product. Testing helps to assure awareness of the quality of the product. By seeking and finding problems, testing helps to make assurance part of quality assurance possible and timely.
Some people seem to suggest that if we do software quality assurance well enough, we won’t need testing. Good luck with that. Without testing — without experiencing, exploring, and experimenting with the product, and without critical evaluation of it — we’ll be in the dark about risk and the possibility that we’ve failed to achieve a high-quality product. Without testing, problems can remain invisible to the development team until — surprise! — the product brings harm, loss, diminished value, or bad feelings to people.
Until we have tested our beliefs about the quality of our product, our beliefs are just beliefs, hopes, wishes, dreams, or fantasies. We test those beliefs by challenging them; by testing the product shallowly when it’s expedient, and deeply when necessary; by thinking critically, to reduce the risk that we’re fooling ourselves.
Some of us have been pointing this out for a generation or so: calling testing “QA” — as an abbrevation for Quality Assurance — undermines people’s capacity to get clear on either one. It’s 2024. Can we all please stop doing that?
Excellent advice! I appreciate you sharing this blog. eager for more inspiration.