I have just come back from presenting at CAST 2026 in Cocoa Beach, and something that’s been bugging me for a while finally clicked.
Somewhere in every testing event I have been to in the last fifteen years, someone makes the case that testers are undervalued, and the case is usually made well. I saw a version of it on LinkedIn a few days after I got home. Manual QA is seriously underestimated, the argument goes, and the reason is context rather than raw bug-finding. If you work with the same product long enough you start remembering things that were never properly documented. You know which part of the system is fragile. You remember the weird bug from six months ago. You know that one feature only works because of an old workaround nobody wants to touch, and that changing one small thing here can break something completely unrelated over there.
The room agrees, as the room always does, and that is the part I have started paying attention to, because everyone in the room is a tester.
In twenty years I have never heard an engineering manager make this argument. Not in a hiring conversation, not in a workshop, not in a corridor at a conference, not once and not unprompted. The people who decide whether a testing role exists next year are not the people making the case for it, and after two decades of watching this I no longer think that is an oversight in how we communicate. I think it is the argument itself.
Everything in the argument is true
The case is stronger than the eye-roll it usually gets from the automation crowd.
Spend long enough on the same product and you end up carrying a mental model of it. I still remember an integration that swallowed errors silently, and the only reason anybody knew was that one of us had been there the first time it did it and had never trusted it since. None of that was written down anywhere. It was not really the sort of thing you could have written down in advance either, it was just something a person knew, the way you know which floorboard creaks in a house you have lived in for ten years. That takes a long time to build up and there is no shortcut into it.
And the strongest part of the argument is the part most people skim past. That knowledge makes you useful long before anything is ready to test. The most valuable thing a person with that model can say in a design discussion is not “this is a bug” but “are we sure this won’t break that other flow?”, and the earlier that question gets asked the cheaper the answer is. I have watched that single question save weeks. It is a real contribution, it happens at the point where changes are still cheap, and organisations that do not have anyone asking it pay for the omission later.
So I am not disputing the observation.
What I am disputing is what we have decided it proves, and the fact that we have been deciding it in a room with the door shut. Automation arrived and the community explained that only a human brain could make the decisions good testing needs. Agile arrived and the community explained it again. Shift-left, DevOps, and now AI, each time with the same shape: a new thing threatens the boundary of the role, and the response is a restatement of why the role is more necessary than ever. The wording modernises but the argument does not move.
The engineer six years in knows the same things
Take the context argument seriously for a moment and follow it where it goes, because it does not arrive where the people making it want it to.
If accumulated product knowledge is the justification for a role, then everyone who has accumulated it has an equal claim, and plenty of people have. The developer who has been on the same service for six years knows precisely which module is held together with a workaround, because they wrote the workaround and have been hoping nobody touches it ever since. Ask the SRE who has been paged at three in the morning for the same subsystem eleven times and you will get a more exact account of how it fails than anything in the test plan, and the support lead who fields the same complaint every quarter can usually tell you which flow has broken before you have finished describing the ticket. None of them are testers, and every one of them is carrying the thing we keep describing as our distinctive contribution.
Bryan Finster put the point more sharply than I would have: “That knowledge comes from being responsible for the entire SDLC, not a specialist slice of it.” The model of the system comes from tenure and from ownership, not from job title, which is why an engineering manager hearing “our tester knows which parts are fragile” does not hear a case for a role. They hear a description of a competent colleague, and they think, correctly, that this is what they expect from everyone on the team. They already expect every person there to think about risk, about the business and about the customer. We have been presenting the baseline as a differentiator to an audience that set the baseline.
We have been making the case to ourselves
There is a second reason the argument has never travelled, and it is less comfortable than the first.
It was never addressed outward. It gets written by testers, published in testing newsletters, presented at testing conferences and discussed in testing communities, and the feedback it receives comes from people who were already convinced. Better positioning will not fix that, because it is a closed loop, and the loop has a market.
You can see the shape of it in how training gets sold. There are testing courses pitched directly at people who feel under attack by technologists who think everything can be automated, and what they offer is the arguments and the confidence to push back. That is reassurance sold as a product, to an audience whose willingness to pay goes up the more threatened they feel, and I do not think anybody involved is being cynical about it. It is a market responding accurately to demand, which is exactly why it should worry us: the demand is real, it is large, and it is being met with better arguments rather than with different work.
And when the argument does get made outward, it does something the people making it do not expect. Say it to someone with budget authority. Tell them that critical knowledge about how your system behaves exists only in one person’s head, that it was never documented, and that the team depends on that person being in the room when decisions get made. You have not described an asset. You have opened a bus-factor conversation. In any other context we would recognise that sentence immediately as a single point of failure, and it goes on a risk register. The mitigation for an item on a risk register is not to protect the person, it is to remove the dependency on them.
Testers have been let go in large numbers over the last few years, and I do not want to make more of that than it is, because it is not proof that the context argument is wrong and I have watched that particular overstatement discredit better arguments than mine. Organisations cut valuable things constantly, and one of my own survey respondents described a test engineer being laid off because management thought they could lower costs through AI, which is a story about a bad decision rather than a story about a bad tester. The layoffs are a symptom of a system that is broken in several places at once. What they do tell us, and the only thing I want to draw from them, is that fifteen years of this argument has not reached the people who sign off headcount. We have been persuasive to each other while the decisions were being made somewhere we were not speaking.
Documentation goes stale because nothing makes it stay true
The strongest objection to everything I have just written is that tacit knowledge cannot be externalised, and it deserves a proper answer rather than a dismissal, because the objection is largely correct.
Documentation decays, and everyone reading this has opened a wiki page describing a system that stopped existing two releases ago. Half the onboarding documents I have ever been handed walked me through a deployment process nobody had run since the migration before it. “Write it down and share it” is advice the industry has been giving for thirty years and it has never fully worked, so the person carrying the model in their head is not merely hoarding: they are, in a lot of organisations, the only working copy. My own audience says this about themselves more clearly than I could. When I surveyed them about AI tools, 41% described losing control of context, and one of them put it like this: “I have a lot of tacit knowledge I have a hard time expressing in its entirety to the agent.”
That is true, and it still does not get you to a role.
Part of the answer is the one I have already made: irreducible tacit knowledge argues for tenure, and tenure is not a job title. But the more interesting part is that the objection assumes documentation means prose, and it has not updated for current tooling.
Prose documentation goes stale because nothing forces it to stay true. There is no mechanism anywhere in the system that notices when a wiki page stops describing reality, which is why the decay is structural rather than a discipline problem that better people would solve. A specification that executes does not have that property. If the knowledge that this feature only works because of an old workaround is written as a test that runs on every commit, then the moment somebody removes the workaround the build goes red and the knowledge asserts itself, without anyone having to remember it or having to be in the room. That is what an acceptance test is for: a statement about how the system is supposed to behave, executed continuously, which cannot stop being true without the pipeline announcing it to everyone.
Dave Farley’s guidance on this is blunt, and I quote it in full because the middle clause tends to get lost: “Don’t have separate QA team. Quality is down to everyone. Developers own Acceptance Testing. QA people are valuable, but don’t have them write acceptance tests separate from developers.” Alongside it: “Do think of your tests as ‘Executable Specifications’.” Nobody in that quote disputes that QA people are valuable; what Farley disputes is the separation.
So when the defence says the knowledge cannot be written down, what it means is that the knowledge cannot be written down in the form we used to write things down in. The fragile subsystem, the six-month-old bug and the workaround nobody wants to touch are all statements about how the system behaves under specific conditions, which is precisely the category of thing an executable specification exists to capture. Leaving that knowledge in one person’s memory is a choice, and it is now a choice with fairly good tooling arguing against it.
What it costs to keep singing
I have called this singing in the dark because that is what it sounds like from a few steps back: a profession keeping its own spirits up, at volume, in a room where nobody else can hear it.
The observation underneath the argument holds up, so the damage is not in the claim being false. It is in what we spent making it, because fifteen years of conference talks, newsletters, courses and posts, all directed at people who already agreed, is fifteen years we had to change something and used to reassure each other instead. Meanwhile code is being produced faster than at any point in my career and the quality of it is more questionable than it has ever been, which means we need more testing than we have ever needed. We do not need more testers. Those two sentences are compatible, and the profession has spent a decade and a half refusing to sit with them in the same room.
What I keep hearing from testers, when they say what they actually want, is to be seen as a valuable contributor rather than as the bottleneck. That wish is the engine underneath the whole context argument, and the argument is a bad way to get there, because knowledge locked in your head does not reach anyone outside it as value, only as a dependency. The same knowledge, executing on every commit, is visible to every person who runs the build, and it keeps being visible on the days you are on holiday.
If you want something to do with this rather than something to agree with: take the single piece of system behaviour that only you know about, the one you would mention in a design review if you happened to be invited, and turn it into a test that runs on every commit. Not a document and not a Confluence page, a test that goes red when somebody breaks the thing you know about. Then do it again next week. That is the version of “we hold the context” that survives contact with someone holding a budget, and it is the only version I have seen change anyone’s mind.
I would like to be wrong about this, and I am not being rhetorical. If your manager has made this argument, or your CTO, or anyone who was not already a tester, I want to hear about it. That is the conversation I have been trying to have for twenty years, and I have mostly been having it with myself.
