The Tester Advantage
Software testing is treated as the entry-level door into engineering. I think it's the best seat in the building, and I'd argue it made me a better engineer than a CS degree would have.
There is a quiet condescension toward testing in this industry. It's the role people take to "get into tech," the thing you do until you can do real engineering. I spent years in it — Applause, Ubertesters, Smule, Practical SQA — and I've come around to the opposite view.
Testers have the best information in the building. They're just not usually asked for it.
What you can only learn from the failure side
Developers see the system they intended to build. Testers see the system that exists. Those are different systems, and the gap between them is where every production incident lives.
Spend a couple of years in that gap and you accumulate a specific kind of knowledge:
- Which abstractions leak. Not in theory. You know which ones, in this codebase, under what conditions.
- Where the team's blind spots are. Every team has a category of bug it ships repeatedly, and it maps directly onto what that team believes is obviously fine.
- What "done" actually costs. You watch the distance between "the PR is merged" and "this works for users" over and over until you stop confusing the two.
That last one changed how I build more than anything else. You cannot spend years watching features get declared finished and then break, and still believe that writing the code is the hard part.
The moment it flips
At Practical SQA I was writing test cases in Python against every sprint's web release. Front end, back end, full coverage, every cycle. It was good work and I was reasonably fast at it, and about a year in I had the realisation that anyone doing repetitive work eventually has:
I was the bottleneck, and I was a bottleneck made of a person doing the same thing by hand.
So the work changed. Instead of writing the test cases, I started building the thing that ran them. Later, at Estate Sales Near Me, that became a full Playwright framework for a large Next.js application — provider signup, listing creation, Stripe checkout, social integrations — wired into GitHub Actions with automated Stripe CLI tunnel setup, plus browser overlays that showed pass/fail state directly in the UI while debugging.
That last detail is the one I'm actually proud of. Not because it was technically hard, but because it came from knowing exactly what a person staring at a failing CI run needs to see. You only know that if you've been the person staring at the failing CI run.
The through-line
Testing teaches you that software is a claim, and the claim needs checking. Automation teaches you that the checking itself should be a system. Put those together and you arrive somewhere specific: the most valuable thing you can build is rarely the feature. It's the machinery that makes the feature trustworthy without you.
That's the line that runs straight from writing Python test cases to building agent systems at codmir. An AI agent that writes code is not interesting on its own. An agent that writes code and can be verified is a completely different proposition — and the verification half is the part I learned in QA.
The industry treats testing as the entrance. I'd call it the foundation.