What Changed When I Stopped Just Finding Bugs

For my first couple of years in QA, I thought the job was finding bugs. I got good at it. I could take a new module and produce a long list of defects in an afternoon, and I measured a good day by the length of that list.

Then I was asked whether a release should ship, and I discovered the list was not an answer.

Finding defects is the entry fee, not the job

A list of forty defects, handed over on the afternoon before a release, is not information a manager can act on. It is work transferred to them. They now have to read forty tickets, guess at severity, and decide — and they will do it worse than you would, because you are the one who saw the failures.

The realisation that changed my work was this: the deliverable is not the defect list. The deliverable is a decision people can trust, with the reasoning attached.

That reframing rearranges everything. Finding a defect is the beginning of your responsibility for it, not the end. You have to know how much it matters, what it touches, what happens if it ships, and what would have to be true for you to be comfortable either way.

The first release I signed off

I remember how uncomfortable it was. Nine open defects, none critical, three that I did not fully understand. What I wanted to say was "there are nine open defects" and let someone else own it.

What was actually needed was a position:

Recommend shipping. Tier 1 invoice and payment cases pass, verified at the database. Six open defects are cosmetic and listed below. Two are medium — the export column order is wrong, and the filter resets on pagination — both have workarounds and neither touches stored data. One I cannot explain: the customer balance refreshes slowly on first load after login, and I have not reproduced it consistently. I would ship, and I would look at that third one first thing next week.

That took twenty minutes longer than pasting a list, and it is a completely different professional act. It says what I checked, what I found, what I think, and where I am uncertain. Someone can disagree with it on the substance — which is what you want, because that is a real conversation rather than a handover.

Writing down what I did not test

The habit I would most want to pass on: state your coverage boundaries, always, in writing.

Nobody tests everything. Everyone knows nobody tests everything. But if you do not say what you skipped, your sign-off implies completeness, and when a defect appears in an area you never covered, the gap between what people assumed and what you did becomes your problem.

So the report says: Tier 3 export formatting was not re-tested this cycle. Safari was not covered — no device available. Load testing was out of scope, last performance pass was two releases ago.

Every one of those lines is a chance for someone to say "actually, we need that." That is not admitting weakness; it is the mechanism by which the team decides how much risk it wants. It is also the difference between a tester who gets trusted and one who gets blamed, and it is why the out-of-scope section is the most valuable part of a test plan.

Learning to give a recommendation, not a list

Severity and priority separated properly is what makes a recommendation possible. Severity is technical impact; priority is business urgency; and the person who should decide priority is not the tester — but they can only decide it if you have supplied honest severity.

What I try to attach to each open defect at sign-off is one sentence about consequence. Not "the total is wrong" but "the stored invoice total is wrong for percentage discounts, so any invoice generated with one is incorrect and the figure flows into the monthly report." The first is a symptom. The second lets someone decide in ten seconds.

The same discipline at ticket level is what makes the difference between a report that sits in the backlog and a report a developer can act on today.

Saying no is part of it

The hardest part was learning that a sign-off you do not believe is worth nothing, and that stating a position clearly under pressure is the job rather than an act of obstruction.

The version that works is not refusal, it is precision about consequence: "I can't sign this off — the payment retry path double-charges, I have the query showing two captured rows for one booking, and it will affect real customers on day one. If we ship, we need the retry disabled first." Nobody argues with that, because it is not a preference. It is a described outcome.

What made this possible was having evidence rather than an opinion. Which brings me to the actual skill shift.

The skills nobody put in the job description

Three things moved my work more than any process change:

SQL. Being able to check the stored state rather than the screen roughly doubled the defects I could find, and it changed how my reports were received — a query result showing the inconsistent rows ends a debate that "the total looks wrong" would have started. Why I verify results in SQL is the longer version.

Testing the API directly. The interface is one client, and the best-behaved one you will ever have. Most of the serious findings — permission holes, unhandled input, non-idempotent creates — are invisible from the screen.

Reading the schema. Half an hour with the table list and the foreign keys tells you more about how a product actually works than a week of clicking. It is also how you learn which modules share data, which is the basis of any regression decision worth defending.

None of these were in a job description. All three were what let me stop asking developers to confirm things and start telling them what I had found.

What I would tell my earlier self

Keep getting good at finding defects — it is the foundation and it never stops mattering. But start practising the next part earlier than feels appropriate.

For every defect you file, write one sentence on why it matters. At the end of every test cycle, write what you covered, what you did not, and what you would do about it. Nobody has to ask you for that. Do it before it is your job and you will find it becomes your job, because the person who is already producing decisions is the obvious person to give the decision to.

That, more than any certificate, is what changes the conversations you get invited into. The rest of the route is mostly consequence.