What 13 Years in QA Taught Me About Shipping Software

Thirteen years is a long time to do one thing. Long enough that the lessons stop being about the thing itself and start being about everything around it.

Here's what 13 years in QA actually taught me — not about testing, but about shipping software.

"Done" is a fiction

In development, "done" means the feature is built. In QA, "done" means the feature works in the conditions users will actually experience — not the conditions you built it in.

Those are different things more often than developers expect.

After enough time in QA, you stop treating "done" as a state and start treating it as a confidence level. The question is never "is it done?" The question is "how confident are we that this works in production for real users under real conditions?"

That shift — from binary state to confidence level — changes how you communicate, how you scope work, and how you make release decisions.

Risk is the actual product of QA

QA doesn't produce test reports. It produces risk assessments.

A test that passes doesn't tell you the feature works. It tells you the feature works in the specific conditions you tested. The gap between those two statements is where bugs live.

The most valuable QA skill isn't writing test cases. It's modeling the gap between tested conditions and real conditions, and making explicit judgments about which gaps matter and which don't.

This is why senior QA engineers are valuable in ways that test automation isn't — they can say "this test suite doesn't cover the case where the API returns partial data, and that's the case most likely to happen on a slow connection." That's a judgment call, not a test execution.

The best bug report is one you never have to file

Prevention is asymmetrically more valuable than detection. A bug caught in architecture review costs 30 minutes. The same bug caught in QA costs 2 days. In production, it costs customer trust and an emergency fix.

After years of writing bug reports, you develop a strong preference for never writing them at all. This leads to:

• Asking "what breaks?" during design discussions, not after development
• Flagging ambiguous requirements before they become ambiguous code
• Treating edge cases as design inputs rather than things to handle after the fact

The best QA engineers make themselves partially obsolete by moving quality upstream. The best developers do the same thing.

Reproducibility is everything

A bug you can't reproduce is a bug you can't fix. A bug that happens intermittently is worse than a bug that happens always, because intermittent bugs survive releases, accumulate user reports, and erode trust gradually.

This makes reproducibility a first-class engineering concern. Logging, state capture, error context, request IDs — all of these exist to make production bugs reproducible from a report alone. Code that logs nothing is code that will produce unfixable bugs.

After enough time tracking down "sometimes it doesn't work" issues, you start writing code that makes its own state visible. Not for debugging during development — for debugging months later with nothing but a log file.

Shipping nothing is also a risk

Early QA career: the job is to find bugs. Shipping with known bugs is failure.

Late QA career: the job is to make the best risk decision given the available information. Sometimes shipping with a known low-severity bug is the right call. Sometimes delaying for investigation has its own cost.

This reframe — from "find all bugs" to "make the best risk decision" — is what separates senior QA thinking from junior QA thinking. Software is never perfect. The question is always which imperfections are acceptable at what cost.

The same thinking applies to product decisions, architecture decisions, and scope decisions. Everything is a risk tradeoff. The people who make the best ones are the ones who've made enough bad ones to understand what they cost.

The compound value of consistency

Inconsistent releases — sometimes thorough, sometimes rushed — produce inconsistent quality. Users calibrate their trust based on the worst releases, not the average.

Consistent release discipline produces predictable quality. Not perfect quality — predictable quality. Users know what to expect. Crashes are rare enough to be notable.

This is the actual value of process: not the specific steps, but the consistency. A lightweight release checklist followed every time beats an exhaustive one followed when you remember.

After 13 years, the habit of consistency is worth more than any individual technique. Build the process, trust the process, ship with confidence.