Why Software Engineers Should Own Their Own Tests
Separate QA queues create learned helplessness. Why engineers should own test evidence, and how AI makes that ownership practical again.
Separate QA teams solved a real problem in an earlier era: developers shipped code, QA specialists caught obvious regressions, and release managers coordinated the handoff. It was better than no discipline at all. It also created one of the most persistent pathologies in software organizations: learned helplessness. Developers learned that "quality" lived somewhere after coding, tests became artifacts someone else would eventually write, and a bug found late in the cycle became a process inconvenience rather than evidence that the team had designed the wrong ownership model.
The strongest argument for developer-owned testing is not ideology. It is feedback economics. Engineers are the people closest to the code, the data model, the intended behavior, and the exact change set. The cheapest moment to decide how a change should be tested is while the person making the change still holds the whole mental model in working memory. Every handoff after that increases latency, ambiguity, and queue time.
AI matters here because it removes the most common excuse. Developers used to say, with some justification, that writing and maintaining browser tests was too slow and too specialized to own in the same pull request as the feature. That claim gets weaker every quarter. If a baseline test can be generated in under two minutes and selector maintenance can be partially automated, the cultural case for separate ownership collapses fast.
Separate QA Creates the Wrong Incentives
A separate testing queue changes behavior on both sides.
This is what "learned helplessness" looks like in practice. Engineers stop building testing instincts because the org design tells them they do not need those instincts. Then leaders wonder why every release needs heroics.
The exact timings vary by org, but the pattern does not. Every queue slows learning, and slow learning is the root cause of low-quality releases.
The queue also changes the emotional model of quality. When feedback arrives two days later from a separate function, it feels like external criticism. When it arrives in the same PR, it feels like normal engineering iteration. That difference matters. Teams with fast self-owned feedback loops are calmer, less political, and much harder to surprise at release time.
Topics: Leadership, QA Strategy, Career.
Read the full article · Get Started Free