The trade we used to make
Before any of us had Claude in the loop, the work was tedious in a specific way. Testing itself was fine - that is the job. The problem was everything the job needs to stay healthy: test cases written down, documentation kept current, tickets that a developer can actually act on, a project in good enough shape that the next person isn’t starting from zero.
Some context first. There are always multiple projects running at once - some in maintenance, some in heavy development. Most are startup products, and startup products breathe: a product ships, then sits quiet for months while real users generate the feedback that shapes phase two. Delivery QA is four of us, and nobody owns just one project - when a product goes into its quiet phase, you move to one that’s live, and when phase two kicks off, you come back to it. That rhythm is why the trade was so hard to avoid: your week is split across products at different stages, and every switch means loading a different product back into your head.
There was never time for all of it. So every week you made the same choice: test the build in front of you, or keep the documentation honest. Testing won, every time - testing had a deadline, and the product in front of us always got tested. It was the writing-down that slipped. It lived on Google Drive, it went stale, and maintaining it was a chore nobody could afford. Multiply that by four testers and a dozen-plus live projects and you don’t have a documentation problem, you have a documentation debt that compounds across the whole portfolio.
That is the part outsiders miss about QA capacity. The bottleneck was never the willingness to document. It was that the supporting work and the testing work drew from the same small pool of hours, and the supporting work always got cut first.
First, we used it like a chatbot
The first phase was cautious and obvious. “Claude, tidy up this ticket description.” “Claude, draft me a test case for this.” It helped, the way a faster keyboard helps. Low stakes, small wins, nothing about the shape of the work changed. We were using a chatbot on the side.
That phase had its own tax, though. Unguided, the model padded everything it touched - bloated ticket descriptions, test cases with hallucinated steps for screens that didn’t exist. At first we used it anyway and stripped the unnecessary content back out, which quietly ate the time it saved. It took a while to learn what actually makes it faster: giving it the context and the standard up front, instead of editing its guesses after.
Then we stopped chatting and started building
The shift that mattered was giving up on chat. Instead of asking an assistant the same thing over and over, we built a set of skills - small, standard-aligned tools that hand work down a chain, so the tester supervises instead of retypes.
- The tc-generator skill turns source code into human-readable test cases, written for a manual tester - what they click, what they see, what they verify. No selectors, no endpoints.
- A ticket-generator skill turns a rough, Slack-style note into a clean, correctly formatted bug ticket.
- A project-review skill runs our QA checklist across a project’s tickets and documentation and hands back one consolidated report.
The move from “we use Claude for descriptions” to “go Claude, faster” was exactly this: from asking a chatbot for text to running skills that do a QA task end to end against our own standard. Changes that used to sit on the backlog for weeks now happen in an afternoon, and at a higher quality than we managed by hand, because the standard is baked into the tool instead of living in someone’s memory.
The tool underneath it: TCMS
Skills produce test cases fast, but scattered test cases are just a faster mess. So we built an internal tool - TCMS - that pulls test cases together across every project. Testers run them, and the tool keeps the history: when a case last ran, whether it passed, what changed. That’s the part that turns generated documentation into documentation we actually keep. A test case there has a history behind it, not just a file that got written once and never looked at again.
The numbers moved in a way that still surprises me. Before AI, thin budgets meant thin written coverage almost everywhere - a project would carry a handful of documented cases while the real coverage lived in the tester’s head. That worked, until the rhythm of startup work tested it: a product pauses after release, the tester moves to a live project, and months later phase two starts with the coverage waiting to be rebuilt from memory.
On one production project, zero to a hundred written test cases took years of regular development; a hundred to 460 took two months. Some of the generated cases are smaller in scope - but they’re maintained, tracked, and organized in a way the hand-written hundred never were, because the skills write them to one standard and TCMS keeps their history. It’s not that anyone suddenly found the discipline; it’s that a first pass from the source now takes an afternoon, not a week. The floor came up everywhere at once, on every budget - and the project nobody had time to document is often the first one we document now.
One standard, every project
The last piece was consolidation. We rewrote and merged our QA SDLC document and the standards around it - test cases, documentation style, commits, the way of doing things - into one written source of truth. That sounds like housekeeping. It is the thing that lets AI help without drifting: when the standard is one document, a skill on Project A and a skill on Project B produce the same shape of work. Consistency across projects stopped being a matter of who happened to be testing.
What our meetings turned into
The clearest sign the change was real showed up in our team meetings. Four testers across a moving set of projects means we sit down together regularly, and for years those meetings ran on the same fuel: technical questions asked over and over. How do we name this. Where does that doc go. What tag do we use here. Which format for that ticket. The answers existed - in someone’s head - so every meeting spent its energy re-deriving the way of doing things instead of moving it forward.
Now the flow is written down and the tools carry it, so those questions mostly don’t reach the room anymore - you ask the standard, or the skill already did. What’s left is the meeting we never used to have time for: the bigger picture. We talk about direction, where we want QA to go, which new tools or approaches are worth a look, what’s working and what isn’t. In practice we gave a small QA department its own R&D loop - time to research and try things instead of just re-explaining them. That’s the part I didn’t see coming, and it might be the most valuable thing we got.
What did not get easier
None of this touched the actual test. AI drafts the test case, but a person still has to decide whether the case is the right one, and whether the product in front of them actually clears the bar. That judgment is still manual, still the slow step, and honestly it should be - we’ve measured what that means for a project’s budget.
The judgment isn’t the only thing we haven’t solved, either. A few pieces of this are still unfinished.
Mobile is where the tooling runs out. Our browser-driven exploration doesn’t reach a phone, and the agent that would is still an experiment - not something we’d point at a production build tomorrow. On mobile projects we’re mostly back to doing it by hand.
And we’ve defined the metrics that are meant to show QA’s value and started feeding them into a weekly board - but we’re at the start of that trend line, not the end. Some of it we can’t even measure yet, not until the trackers carry the right fields.
I’d rather say all that plainly than pretend the last six months tied a bow on it.
What we actually gained
The headline everyone reaches for is “AI makes the work faster.” For QA, that undersells it and slightly misses the point.
What AI removed was the trade. The documentation, the test cases, the tickets, the standards - the work that used to lose every time it competed with testing for hours - is now cheap enough that it stops competing. Quality across a project became something we maintain as a matter of course, not something we had to ration hours for.
For a four-person team spread across a shifting set of client projects, that hits in a very concrete place. When someone picks a project back up after its between-phase pause, or takes one over from a teammate, the documentation is actually there and actually current - the handoff takes minutes, not days. The thing that used to make us fragile was knowledge living in one person’s head on one project. That’s exactly the thing that got cheap to write down. We didn’t fix that by hiring; we fixed it by making the knowledge cheap to keep outside our heads.
The judgment didn’t shrink - it’s the job, and no model does it for you. What changed is everything around it. And once you’ve worked that way for a while, you plan QA differently: you stop spending your energy defending the supporting work, and start spending it on the calls that were actually yours to make.