Pre-release QA review — a guide for buyers

Before whether comes when. A review starts once a release candidate build exists. Hand over a build that is still growing features and the scenarios already executed are void against the next build, and that re-run lands on the schedule. So the first cell of the count-back is the code freeze. Agree the start date around the candidate build and access readiness. The standard review takes five business days; schedule defect fixes, the agreed retest, and release approval separately. If time is short, agree the critical flows, exclusions, and available fix time together so the results can inform the release. Contracting and access provisioning take days of their own. Internal network accounts, a test environment, sandbox keys for payments or third-party integrations rarely arrive the day they are requested. Fixing the review start date at the same moment the release date is fixed keeps this stretch inside the schedule. The reverse also holds: with no date set there is no reason to hurry. Wider scope covering regression serves better, and that is a term engagement rather than this service. The same logic applies to products that ship continuously. Running every sprint build through a single-shot review repeats the kickoff each time, and the cost climbs faster than the volume of work. Single-shot review fits a dated major release, an independent check before accepting delivery, and the moment a product built without verification finally gets stood up.

Teams with in-house QA may add external review for a perspective separate from development. Both internal and external results need agreed criteria and reproducible evidence. A buyer accepting delivery compares the supplier's results with acceptance requirements and decides which areas need independent rechecking. The split with an internal team is settled in writing before kickoff. Which areas the internal team keeps and which move across are separated, and the defect severity scale and report format are unified into one. If two organizations grade the same defect differently, the release meeting argues about grades instead of evidence. The common split leaves functional regression inside and gives the release candidate to the outside team. Where there is no dedicated owner at all, the ruling criteria get set together first — without an agreed definition of what blocks a release, a result sheet still leaves the meeting circling.

Three things. First, the release candidate build and the environment it runs in — access path, accounts, test data and how to reset it. Second, the core flows: the buyer names the paths whose failure would push the release. Signup, payment and order completion, where money and trust sit, usually come first. Third, the material for judgment. Requirements or screen specs are taken as they are; without them, reconstructing requirements backwards from the screens enters the scope. Missing documents do not stop a review, but the same price covers less ground. Defect history from the previous release and a list of recently touched areas change the ordering — recent changes and places that have broken before move up the run order. This matters most for a product built quickly with generative tooling. When the people who produced the code cannot explain its exception paths, the work begins with conditions no requirement ever recorded, and that pass takes a large share of the execution time. Late inputs do not extend verification; they extend waiting. Confirming once, before the start date, that access actually opens is the cheapest way to hold a schedule.

Five numbers set price and duration together: builds in scope, product areas, core flows, agreed scenarios, and retests. The narrowest shape covers one build and one product area with one core flow and ten scenarios, and carries no retest. The standard shape runs five business days over one build and one product area with three core flows and thirty scenarios, and retests the agreed fixes once. The wide shape reaches two product areas, five core flows and fifty scenarios. Those five numbers and the fee are fixed in writing before kickoff, so cost does not grow as verification runs long. Exclusions go in the same document. Security certification and compliance conformance are not ruled on, and code quality is not assessed. Cutting away the items expected under the word "review" that are in fact different work keeps the closing conversation clean. Performance, load and failure-recovery testing separate here too: building a load model is preparation larger than the execution itself, so it does not sit inside this price.

First, the test case and scenario assets — what was checked inside each core flow, and under which conditions, stays as a document and runs again on the next release. Second, the defect log, where every defect carries a severity, reproduction conditions and the flow it surfaced in. Third, the release decision memo: scenario results, areas left unchecked and residual risk on one page, closing with release, release with conditions, or hold. A person signs the ruling. After reviewing results, exclusions, assumptions and residual risk, CTO Minkyu Shin signs the release memo. Release with conditions states in the same field what has to be satisfied; hold states what has to be in place before the question returns. Keeping the unchecked areas on the same page as the ruling is the point of the document — a report that omits what it did not verify makes the pass rate read wider than the work.

A review buys a ruling, not a result sheet. If only pass and fail counts come back, the job of reading those numbers into a release decision returns to the buyer. Three things to confirm in a proposal. First, are the ruling values defined in advance — fixed values such as release, release with conditions and hold keep interpretations from splitting in the meeting. Second, do the unchecked areas appear in the same document as the results. Third, who signs. Asking about the signer's background, and whether that person actually reads the project, separates suppliers who sell a ruling from suppliers who sell execution. When comparing quotes, look first for the five scope numbers. A quote carrying only duration and headcount, with those five blank, is still an estimate rather than a price. Press for the numbers and most of the spread between candidates turns out to be scope, not skill. Retest inclusion and handover terms belong in the same conversation: unless executed scenarios and the defect log come across as document files with the underlying data, the next release pays for the same work again.

The five numbers usually answer the question of how long. Four variables still stretch the same five numbers. First, the count of environment combinations: browsers and operating systems, devices and app versions multiply, and one scenario runs several times. Products with wide supported matrices, as in finance or the public sector, stretch the furthest. Second, defect density — when defects come thick, narrowing and recording reproduction conditions outgrows execution time. Third, the cost of building preconditions: a product where accounts, items and orders must be assembled by hand each time carries a longer clock on identical scenarios. Fourth, how fast fixes land, since a retest starts only after development ships the corrected build. When the date is tight, narrowing to a single product area beats cutting the number of flows. A narrower area also shrinks preconditions and environment combinations, which raises execution density, and the area set aside becomes the first candidate for the next release's review.