Earlier this week I left a comment on a LinkedIn post about testing in an AI-assisted workflow. The post itself was fine, better than most. It argued that when the same AI writes both the function and the test, the two share the same blind spots, so you should write the test first and decide what “correct” means in human terms before any code exists. I agree with that. What stopped me was a separate reply from the author, where he explained that the job was to “write all the tests you can think of” and that writing tests first was really for “core flows only.”
That is not TDD. TDD is not a coverage strategy you sprinkle over the important bits. It is a design discipline: you write one failing test, write just enough code to pass it, refactor, and repeat, and the tests drive the shape of the code as it emerges. Coverage falls out as a side effect. The person defending the practice had taken a real idea and hollowed it out, kept the ritual and lost the reason for it.
I am not writing this to correct one commenter. I am writing it because that hollowing-out is the testing profession in miniature.
Forty years of relabelling
Testing has met every shift in software the same way, by repackaging what it already knew under whatever word was current. When automation arrived, the manual tester became an “SDET” and then an “automation engineer.” When agile arrived, we became “agile testers.” When the org charts were redrawn, “QA” turned into “QE” on a few thousand business cards while the work underneath stayed exactly where it was. The certification bodies took a fixed body of knowledge, wrapped it in a syllabus, and sold it back to us as professional currency.
This kept people employable, and I do not want to be glib about that, because employability matters. But recycling is not learning. A profession that adapts by renaming itself produces very little that is genuinely new, and if you go looking for the new ideas testing has contributed to software in the last two decades, the pile is thinner than any of us would like to admit.
The boundary that made the role is gone
The tester role only ever made sense because of a boundary. Someone else built the thing, and you checked it. That division of labour is what a job title needs in order to exist at all.
The boundary is dissolving in front of us. Developers write their own tests as a matter of course. AI writes tests too. AI writes the code those tests are meant to catch, which is how you end up with the auditor auditing themselves and passing with flying colours. If the tester’s identity was the act of producing the checks, that identity is being automated, and a role whose defining activity has been automated does not survive on sentiment.
The thing that was always valuable was never the production of checks. It was the judgement underneath them: what is worth testing, what “correct” actually means here, where the real risk sits. That judgement has no natural home once the role carrying it dissolves, and preserving it is the problem worth solving.
A lot of what we are defending deserves to go
A great deal of what gets defended as “manual testing” is not good work. It is a person following steps from a spreadsheet, running hundreds of test cases where half are out of date, generating a fresh batch of false positives every time someone new joins the team, ticking boxes so that somebody somewhere can demonstrate that quality was inspected. The people doing it are usually miserable, because nobody listens to them and they know full well they are there as a formality.
When the machines came for the mining jobs, people smashed the machines. Those jobs were brutal and dangerous, and the people who held them fought to keep them, because a job is a job and society is arranged so that you need one. We look back now and we are glad those jobs are gone. Manual regression testing is waiting for the same shift, and I do not understand why so much of our collective energy goes into defending the job rather than into the thing that should actually make us angry: that these people were parked in a checkbox role and never developed, never given work that used their judgement. Removing an ineffective job is not an attack on the people in it. Leaving them there was.
We never agreed what we were for
Grant all of that, and you arrive at the question the profession has never answered. If not “tester,” then what, and defined how?
“Quality engineer” is the usual answer, and it is a defensible one, but only if we treat it as a real discipline rather than a QA analyst with a better title. Defining it properly is the whole job, and we have never done it. Alan Page wrote recently about how most of our disagreements are foundational rather than tactical, and how we argue about conclusions while the real disagreement sits buried in assumptions nobody ever chose on purpose. His example is quality itself. If you believe quality is a testing output, you hire testers and build QA gates. If you believe it is a property of the whole system, you redesign your feedback loops instead. Same word, completely different organisation, and we have never agreed which one we mean. (Why You Believe What You Believe is worth your time.)
We circle the same arguments for years because we are reasoning from a foundation we never built.
I want to build the foundation, and I need your help
I have been making this argument for years, at PeersCon, at Agile Testing Days, at HUSTEF, at Motacon among others, in talks and in workshops, and argument on its own only carries you so far. What I want now is to build the thing in the open: a shared repository for the foundations a serious quality-engineering discipline would need, the definitions we have never agreed and the philosophical basis Page says is missing.
This needs people who have set quality strategy for a whole organisation and people who are elbow-deep in a test suite this afternoon, because the two see different parts of the same problem and neither view is complete on its own. Wherever you sit, if you have a stake in this, you have something to bring.
If any of this resonates, or if you think I have it wrong and can say why, I would like to hear from you. I have put up a short form to gauge interest and work out who wants to help build it.