How QA actually works under a real deadline

Severity and priority are not the same thing

The most common confusion on a launch week is treating “how bad is this bug” and “how soon do we fix it” as the same question. They're related, not identical. A cosmetic misalignment on a page nobody uses yet is low severity and low priority. A rare crash in the payment flow is high severity even if it only hits one in a thousand users, because the cost of that one occurrence is high. Sorting bugs on severity alone, or on how annoying they are to look at, leads to fixing the wrong things in the last 48 hours.

The triage conversation nobody wants to have

Every project heading toward a launch date accumulates an open bug list that doesn't reach zero. The uncomfortable but necessary step is a triage conversation where someone with the authority to decide actually looks at that list and sorts it into three piles: fix before launch, fix after launch, and accept as-is. Skipping this conversation doesn't make the decision go away, it just makes it accidental, decided by whoever happened to be free on the last day rather than by someone weighing the actual risk.

On our projects that's a named person, usually the project lead alongside whoever built the feature, not a group vote. Three questions do most of the work: does this block someone from completing the thing they came to do, how many people will actually hit it, and what happens if we ship it anyway. A bug that fails all three tests (doesn't block, rarely hit, low consequence) is a reasonable thing to launch with. A bug that passes any one of them usually isn't.

What actually gets tested, and in what order

Test coverage isn't a single number you either have or don't. It's a sequence, and the sequence matters more than the total. We test in this order, because each layer is only worth doing once the one before it is solid:

1. The critical path. The one or two flows the entire product depends on: sign-up, checkout, the core action a user came to perform. This gets tested hardest, earliest, and most often, including every awkward edge case we can think of.
2. The supporting flows. Account settings, notifications, secondary features. Tested thoroughly, but with less obsession over rare edge cases than the critical path.
3. The edges. Unusual inputs, slow connections, permission boundaries, what happens when two people do the same thing at once. Where most of the subtle, genuinely interesting bugs live.
4. The nice-to-haves. Polish, rarely-used settings, cosmetic detail. Tested, but it's the first thing we'll accept a known issue on if time runs short.

A regression suite (the set of automated checks that re-run before every release) grows out of this over time: every bug that escaped to production becomes a test that stops it escaping twice. Early in a build that suite is thin by necessity. By the time a product has shipped a few releases it should be catching most of the obvious regressions before a human ever looks at them.

The bug that ships anyway

Every launch I've worked on has shipped with at least one known issue. That's not a failure of QA, it's what a deliberate decision looks like from the outside. The difference between a healthy launch and an unhealthy one isn't the presence of known issues, it's whether they were actually known: written down, assessed, and accepted by someone with the authority to accept them, versus discovered by a customer with no one having looked at it first.

In practice that means a short, visible known-issues list going into launch, each one tagged with what it affects and roughly when it'll be fixed, plus someone actually watching error rates and support messages for the first 48 hours rather than assuming silence means everything's fine. Shipping with a known, small, well-understood gap is a normal engineering decision. Shipping with an unknown one is the thing that actually damages trust.

What good QA looks like from the outside

It doesn't look like zero bugs, that's not a realistic bar for anything non-trivial. It looks like no surprises: a launch where the team can name what's not perfect yet, roughly how much it matters, and roughly when it'll be dealt with, before a customer finds it first. The teams we trust most aren't the ones who never ship a bug, they're the ones who can tell you exactly which ones they decided to ship with, and why.

Common questions

Should we delay a launch for every bug found?

No. Delaying for every open issue means never launching, since no non-trivial product reaches zero bugs. Delay for the ones that block the critical path or carry real consequence; log and schedule the rest.

What's the difference between QA and testing?

Testing is checking that specific things work. QA is the wider judgment process: deciding what to test, in what order, what severity and priority a found issue gets, and what's an acceptable risk to launch with. Testing feeds QA; QA decides what to do with the result.

How much of the app should be covered by automated tests before launch?

The critical path should have strong coverage before launch, since that's where a regression is most costly. Full coverage everywhere else usually isn't worth the time this early, and the regression suite is expected to grow after launch as real usage reveals what's worth automating.

Who decides what ships with known issues?

One named person with the authority to decide, usually the project lead, informed by whoever built the feature. Not a vote, and not whoever happens to be in the room on the last day.

Does more QA always mean a safer launch?

Not past a point. Over-testing low-risk areas while the critical path gets the same attention as everything else is a worse outcome than concentrating effort where it actually matters.

If you want a second opinion on whether a build is actually ready to ship, talk to us. It's the same judgment we bring to our own development work, and it's often easier to see clearly from outside a project than from inside it.