A guide to sizing and pricing outsourced software QA

The first figures to catch the eye on a QA quote are duration and headcount. Both are outcomes rather than causes. The cause is scope, and scope is written as five numbers: builds in scope, product areas, critical flows, agreed scenarios, retest rounds. Quotes carrying those five compare against each other. Quotes without them never make it onto the comparison sheet. In practice most of the spread between candidates is a difference in scope rather than in capability. One firm assumed three critical flows and thirty scenarios while another assumed the whole product; of course the figures differ. So the order for building a budget is not to collect prices first but to write those five numbers yourself. If the numbers are hard to set, ask in reverse. Asking what each of the five could be within a fixed budget exposes how differently the same figure can be filled. Exclusions go in the same document. Items expected under the name of a review but that are really other work — security certification fitness, code quality grading — have to be cut out at the front, or the close brings both an argument and an extra invoice. The change procedure is part of the price too. Without who requests, who approves, and how the figure moves, changes accumulate verbally and arrive as one invoice in the final month. The cheapest thing that stabilises a budget is a rule that each change gets one line saying what grew and by how much. Product risk is what orders the scope: put the flows where failure stops revenue or corrupts data at the top and cut downwards from there, so wherever the budget runs out, everything above the cut is already covered.

A day of effort is spent differently depending on the type. Functional verification scales almost linearly with scenario count — writing and running both grow, so cutting the count cuts the figure by roughly the same proportion. Exploratory testing is not bought by count but by time. Digging into conditions absent from the specification leaves no countable unit in advance, so it is contracted as hours against areas. Regression is simple to run but broad and frequent, which makes its accumulated effort the largest. Performance and load work differently again. Pulling hourly arrival distribution and per-feature call ratios out of production logs and turning them into a load model is larger than the run itself, and the analysis that converts results into bottleneck locations and a fix order takes time as well. Fault injection and recovery verification need a separate environment and an agreed stop condition first, so one more preparation item sits on top. When a quote bundles these types into one line, ask for them split. Only split by type can you decide what to drop when the budget falls short. Preparation also sits in a different place per type. Functional verification starts running almost at kickoff. Performance and resilience work does not start until the environment and the data are in place. Leave that preparation window out of the schedule and execution slides back, turning idle days into cost. A product without documentation adds one item regardless of type: recovering the requirements by extracting the rules actually implemented from screens and code. Cut that from the quote and the execution team starts without knowing what counts as a pass.

This is the most frequently underestimated variable. Fix thirty scenarios, then add four combinations of browser, operating system, device, and resolution, and the run count is a hundred and twenty. At eight combinations it is two hundred and forty. Cutting combinations lowers the figure far faster than cutting scenarios. What decides the combinations is the real user distribution, not preference. Pull the top combinations from your traffic data and decide where to cut. Combinations you cut go into the exclusion list by name. Physical devices add items: acquisition, storage, and OS version management enter as effort, and if the devices sit at your premises the question ties back to onsite work. Where a cloud device service can stand in, device cost turns into runtime cost instead. Language and region settings multiply the mix again, which makes fixing the target regions early the single largest decision on a multilingual product. The other way to cut combinations is to move the check down a layer. A large share of items verified only on screen reach the same conclusion at the server interface level, and that layer runs once regardless of device mix. Working out which items genuinely have to be seen on screen per combination brings the run count down noticeably.

Verifying once and verifying on every deploy are different contracts. A pre-release review of a single build ends as a one-off figure. Pre-release QA offers that one-off review at three fixed prices. Critical Flow Review ($490) covers one release-candidate build and one product surface, with one critical flow and up to 10 agreed scenarios; retesting is not included. Release Readiness Review ($1,490) covers the same build and surface over five business days, with three critical flows and up to 30 agreed scenarios. One retest of agreed fixes and a release memo signed by Shin Minkyu are included. Extended Review ($2,490) covers one broader release with up to two product surfaces, five critical flows, up to 50 agreed scenarios and one retest. Regression is multiplied by the deploy cadence and becomes a monthly cost. Weekly deploys and several deploys a day diverge sharply in annual effort even with identical scenarios. So read a quote by separating the per-run figure and the annual repeat count from the total. Retest conditions attach here as well. Whether agreed fixes are re-checked once or every time a fix lands changes the run count, and the run count is the figure. Past a certain repeat count, automation build cost is recovered. That point is calculated by putting execution frequency, screen change cadence, test data preparation difficulty, and the time to diagnose a failure on the same table. An area that runs often but changes constantly never recovers the investment, so leaving it manual is cheaper. Narrowing the regression surface also lowers the figure: judging which features a single change touches selects what needs re-checking, so not everything runs on every deploy. Organisations without that judgement run everything every time in the name of safety, and that choice is the single largest driver of regression cost. Teams with a short deploy cadence should price the timing too — overnight and weekend runs, and immediate verification attached to an emergency deploy, are different conditions from routine runs and belong in the contract with a response time, or they end up settled by negotiation later.

Onsite costs more than remote, because travel, desk space, account provisioning, and clearing export rules attach as effort outside execution. So confirm the reason before requiring it. If the reason is a test environment that opens only on an internal network, first check whether restricted accounts and an access path can stand in. If the reason is data that cannot leave the premises or physical devices with a fixed storage location, onsite is right, and settling account scope and export restrictions before setting headcount and duration is what stabilises the figure. IXC works remotely by default and takes onsite engagements too; either way the earlier variables set headcount and duration. Automation splits in two directions. During the build window it costs more than covering the same scope manually, because more than scripts is being built — identifier conventions for automation, a layer that wraps screens as objects, the execution environment, and the test data mechanism. From then on the repeat portion disappears: a monthly maintenance effort attaches while the execution effort drops away. Where a quote carries automation as a single lump, ask for the build and the maintenance separated. Maintenance includes failure analysis. The time spent sorting a failed run into product defect, environment problem, or script decay is the real operating effort of automation, and without that procedure the failure list grows until nobody reads the results and the build cost is lost outright.

Cover the same scope over the same period and the figure still differs by what you keep. Receiving a one-page summary and receiving a signed release memo with per-scenario results, uncovered areas, and residual risk attached are different jobs. Attaching severity and reproduction steps to a defect register, linking requirements, tests, defects, and approval records into one traceability sheet, leaving test cases and automation assets reusable at the next release, writing an operating handover for the internal team — each is effort. How far to go depends on whether this verification happens once. Once, and the verdict document is enough; repeatedly, and leaving reusable assets lowers the figure from the second release onwards. For an organisation that has to answer audits or incident reviews, the traceability sheet stops being optional. Writing the deliverable list into the request for quotation makes the differences between the figures you get back explainable against that list. Put transfer terms in the deliverables too. Whether automation assets move with repository access, and how many days of follow-up questions come after transfer, is what makes the next release's cost predictable. IXC transfers test assets and ways of working to the internal team and stays available for questions for four weeks, and that window is fixed in writing with the deliverables before work starts.