A guide to choosing a QA outsourcing partner · 2026

QA outsourcing is not one job. It splits into three. Advisory work sets quality criteria and release gates. Delivery work executes an agreed scope on your behalf. Automation moves the regression that repeats on every deploy into assets. The three are chosen on different terms and signed under different contract shapes. Call in an advisory-led supplier with the release date already close and the date arrives with nothing but an assessment document. Take execution capacity alone into an organisation where every team grades defects differently and the moment those people leave, the old state returns. Before the RFP goes out, write down in one line whether what is missing is a decision framework, execution hands, or repeat cost. Quotes received without that distinction price different jobs, so putting them side by side proves nothing. Choose the contract model around how clearly scope is defined and how likely it is to change. A defined deliverable can be quoted at a fixed price, while ongoing execution can be priced by duration and capacity. Separate automation build and maintenance. Multiple workstreams can share one contract if their scope and prices remain distinct enough to trace changes. Work that sits outside the three is separated up front too: performance, load, and resilience testing sound like delivery, but preparing the load model is larger than running it, and that makes it a distinct job. It is also worth asking whether one supplier can carry all three in sequence. When the criteria set in advisory are the ones delivery uses, and the cases delivery accumulates become the automation backlog, the handover losses between stages disappear.

Handing over a results table is not the same as deciding whether the product can ship. Receive only pass and fail counts and the work of reading those numbers into a release decision comes straight back to you. To hand over the verdict as well, check three things. First, whether the verdict vocabulary is defined in advance. Three fixed values — ready, conditionally ready, hold — keep interpretation from drifting in the meeting. Second, whether the areas that were not covered appear in the same document as the results. A report that leaves the uncovered space out makes a pass rate read wider than it is. Third, identify who writes and reviews the results and who approves release. In IXC's pre-release QA service, the Release Readiness Review includes a memo signed by CTO Minkyu Shin after he reviews results, exclusions, assumptions, and residual risk. Review and reporting roles for an outsourcing engagement are agreed for its scope. Internal and external QA both need agreed criteria and traceable results. External verification adds a perspective separate from development, and consistent evidence helps the release meeting reach a decision. Ask about the lifespan of the verdict document too. When an audit or an incident review reopens it, requirements, tests, defects, fixes, and approval records have to follow one line or the evidence gets rebuilt from scratch. Whether a recommendation to delay also states what would reopen the question belongs on the same axis.

An open-ended scope only moves the price one way. The items to nail down in writing are settled: number of builds in scope, number of product areas, number of critical flows, number of agreed scenarios, number of retest rounds. 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 so the close does not become an argument. The procedure for widening or narrowing scope belongs there as well. Without who requests, who approves, and how the figure changes, change requests accumulate verbally and arrive as one invoice at the end. If a proposal carries only duration and headcount while those five numbers are blank, that figure is still an estimate rather than a quote. Align each candidate's quantities and deliverables to identify how much of the price difference comes from scope. A time-and-materials contract does not exempt you from this. Even when resident capacity is engaged for months, what will be covered at what depth in that time has to be documented in the first week. Otherwise work attaches as requests arrive and the regression window that matters most gets squeezed into the last stretch. Decisions to narrow carry the same weight: an area dropped from this release is the first candidate for the next one, so the exclusion list is an input to the next plan rather than something discarded.

When the engagement ends, the people leave. What stays has to be written into the contract or you pay the same price again at the next release. Four things belong on that list: executed test cases and scenario documents, automation scripts with their environment configuration, a defect register carrying severity and reproduction steps, and the verdict criteria and release gate definitions. Fix the format alongside. Whether documents arrive with the underlying data, and whether automation assets transfer with repository access, decides whether any of it is reusable. If assets accumulate only inside a supplier's own tooling, they become unreadable the day the contract closes. Put the follow-up window in writing too. IXC transfers test assets and ways of working to the internal team and stays available for questions for four weeks after transfer. Without that window you hold the handover document and have nowhere to ask at the first failure. Handover is not an event crammed into the closing week. Agree the verdict criteria and reporting format with the internal team at kickoff and the same documents accumulate for the length of the engagement, so by the close what needs to transfer already exists. A supplier writing handover documents at the end is writing from memory rather than from the work. Where an in-house QA team already exists the question is division rather than handover: which areas the internal team keeps, which move across, and whose severity criteria and reporting format become the shared ones, all settled before kickoff.

Assess automation by both its coverage and the work required to run and maintain it. Script count alone does not establish its operational value. Three questions are. Is there a procedure that sorts a failed run into product defect, environment problem, and script decay? Is there a named owner and a cadence for isolating flaky cases and fixing them separately? Are the areas deliberately left unautomated recorded with the reason? Without those three, a red list nobody believes accumulates and the team stops reading results altogether. Tooling follows the product. Each layer has its established options — Playwright and Selenium on web, Appium on mobile, JMeter for load generation — and IXC picks against the target's specification. A proposal that asks you to fit the product to the one tool a supplier knows has the order backwards. Watch also for whether they offer the judgement to push a frequently changing screen down to the API level or leave it as manual verification. Where results accumulate is the same question. Attached to the pipeline, running on every deploy, with screenshots and logs collected in one place, a deploy owner reads the outcome without asking anyone. Manually triggered automation can still reduce repetitive work. Check whether it runs reliably at the required cadence and whether pipeline or scheduled execution is needed. Ask how test data is handled as well. Without a mechanism that creates preconditions — accounts, products, orders — at run time and rolls them back afterwards, data left by the previous run makes results wobble, and that wobble becomes the habit of ignoring the failure list.

Headcount and duration differ by project. What matters is whether the proposal says what set them. Start with onsite. A test environment that opens only on an internal network, data that cannot leave the premises, physical devices with a fixed storage location — those call for onsite work. Otherwise remote is the default; IXC works remotely by default and takes onsite engagements where they are needed. Choosing onsite, the right order is to settle account scope and what may not leave the premises first, then set headcount and duration. Four variables move the size: the number of platform and device combinations in scope, the deploy and regression cadence, the time left before release, and whether automation assets exist. More combinations multiply the number of runs; a short regression cycle repeats the same runs every month. If a proposal carries headcount and duration but none of these four, ask again. A supplier who cannot explain what set the figure will not be able to explain it when the scope changes either. Choosing remote, put the reporting cadence and the point of contact in the contract. Weekly defects and residual risk in a consistent format, with an escalation path for urgent items, makes physical distance a non-issue. Where the work is split with a team in another time zone, document the responsibility boundary so the same defect is not picked up twice or missed by both. Finally, mark the windows where the size changes. A heavy regression week and a stabilisation week need different capacity, so a shape where one lead stays for the length of the contract while execution capacity attaches per phase keeps the verdict criteria steady as numbers rise and fall.