Teams with a launch date set and no dedicated QA owner
The scope narrows to one build and one product surface, and the verdict arrives within five business days.
Release Readiness Review
A bounded QA review that examines one release-candidate build in five business days and delivers the release verdict as a document.
- Software QA
- Assessment
- Managed delivery
- Automation
01Overview
Service overview
Release Readiness Review examines one release-candidate build within an agreed scope, decides whether it can ship, and records that verdict as a document. Scope and price are confirmed in writing before work begins. The review gives a team with no dedicated QA owner the evidence to bring to the release meeting.
02Who it fits
Where it fits
Teams whose service runs but who cannot explain its edge cases
Missing requirements and exception paths are worked through, and the regression scope a single fix touches is written down.
Buyers who need independent acceptance evidence before delivery
From outside the delivery organization the agreed scenarios are executed, and each pass and fail arrives as acceptance evidence.
03What we deliver
Scope of delivery
01
Test case and scenario assets
Critical flows are agreed, then the scenarios that run inside them are written down and executed. The documents outlive the review, so the same assets carry into the next release.
02
Defect triage and verdict criteria
Every defect carries its severity and reproduction conditions, and what counts as a release-blocking defect is agreed first. That leaves less room for engineering and the business to read the same defect two different ways.
03
Release verdict memo
Scenario-by-scenario results, the areas that could not be covered, and the residual risk fit on one page. The verdict is READY, READY WITH CONDITIONS, or HOLD, and the memo is read as it stands in the release meeting.
How the service works
Verification that supports a release decision
Verify critical journeys and connect observed results and remaining conditions to the release decision.
Agree the risk scope
Verify scenarios and fixes
Record the decision and remaining risks
04Why this way
Points of difference
Each point lists the deliverable that backs it.
A verdict a person signs
Automation extends coverage, but a person stays accountable for the verdict. The evidence, the exclusions, the assumptions, and the residual risk are reviewed before Shin Minkyu, CTO at IXC, signs the release memo. He has worked in product engineering and QA since 2016, at Tricentis, Unity Singapore, Capgemini Singapore, and SOCAR.
Backed by
- Risk map and validation priorities
- Test strategy and acceptance criteria
Client work · Artist platform
Artist platform, company A — reverse-engineering undocumented code, then verifying all of it
We reverse-engineered the code to recover the requirements, then verified every function against what we recovered.
Learn moreScope and price fixed before work begins
How far the review goes and what it costs are settled in writing before kickoff. One build, one product surface, three critical flows, and up to 30 agreed scenarios is the standard scope, and any widening or narrowing of it is recorded the same way. Cost does not grow as the review runs longer.
Backed by
- Execution report and defect log
- Reusable test assets and a handover guide
Client work · Travel product management
Travel product management, company M — collector load and data consistency
We put load on the collector to find where it gives way, and checked consistency between the database and what the collector returned.
Learn more05How to start
From first call to kickoff
Every stage ends with an agreed scope and a deliverable in your hands.
Step 01
Assess risk
We review product flows and the release calendar together and name the highest-impact failure points within five business days of kickoff.
DeliverableRisk map and validation priorities
Step 02
Design evidence
We link requirements, tests, defects, and the release decision in one traceability sheet and fix the acceptance criteria within two weeks of delivery starts.
DeliverableTest strategy and acceptance criteria
Step 03
Execute and improve
We run validation against the agreed criteria and report defects and residual risk weekly in one fixed format.
DeliverableExecution report and defect log
Step 04
Hand over and embed
We hand test assets and working practices to the internal team and stay available for questions for four weeks afterwards.
DeliverableReusable test assets and a handover guide
06Contract options
Ways to work together
- Remote delivery
- Fixed price
| Package | Price | What is included |
|---|---|---|
| Critical Flow Review | $490 | One release-candidate build and one product surface, with one critical flow and up to 10 agreed scenarios. Includes a written findings summary; retesting is not included. |
| Release Readiness Review | $1,490 | Five business days: one build, one surface, three critical flows, up to 30 agreed scenarios, one retest, and a release memo signed by Shin Minkyu. |
| Extended Review | $2,490 | One broader release: up to two product surfaces, five critical flows, up to 50 agreed scenarios, and one retest. Timing and exclusions are agreed in writing before work begins. |
07Service levels
Service levels
5business days
Risk map fixed after kickoff
Weekly
Defect and residual-risk report
4weeks
Questions answered after handover
Internet banking document viewer, company N — pre-release review of an HTML5 replacement
Imagine a banking team replacing an internet-banking document viewer with HTML5 and approaching release.
What we doSet document rendering across browser and OS combinations and the print and save journeys as the critical flows, run the agreed scenarios, then re-verify the fixes once.
What it leavesThe release memo carried both the verdict and the areas that were left unchecked.
Artist platform, company A — reverse-engineering undocumented code, then verifying all of it
The development work we inherited had no documentation, only code.
What we doWe reverse-engineered the code to recover the requirements, then verified every function against what we recovered.
What it leavesWhat the product does, and how, went into documentation, and the point top-up and management feature was built on top of it.
Travel product management, company M — collector load and data consistency
About 1,900 travel products were being maintained by hand, one spreadsheet row at a time.
What we doWe put load on the collector to find where it gives way, and checked consistency between the database and what the collector returned.
What it leavesThe failures we found were in the data, not the features, and product-change handling now runs on its own on top of that.
Global test tool, company T — Japanese localization QA for a no-code test tool
A no-code test automation tool was heading for its Japanese launch and needed a team to own the localization verification.
What we doWe built and ran some 1,000 Japanese verification cases, hunting the places where wording and behavior diverge.
What it leavesSome 150 localization defects were caught before launch over seven months, and the verification cases remain as an asset for the next version.
Mobile app, company R — pre-release app security and server verification
An iOS and Android app heading for release needed its security checked from a position independent of the builders.
What we doWe verified the app and its servers together against some 70 security check items, reporting defects with severity and reproduction steps.
What it leavesSome 20 defects were found across the app and servers, and every one was confirmed fixed before release.
Completed
Down to the files left behind after "backup complete": verifying exhibition image data consistency
We checked down to the files left behind after the backup-complete mark. Originals were compared against copies, and omissions and duplicates were verified under interruption and re-upload conditions.
Completed
Until the article goes public: pre-release QA for a CMS newsroom
We verified the process an article passes through before it goes public. Drafting, approval, publishing, and permissions were reviewed, and the confirmed results were handed over together with what remained out of scope.
Completed
Checking requests beyond the app screen: a mobile app and server security testing case
Down to the requests that never appear on the app screen. Device, communication, authentication, and server permissions were inspected together, and the fixes were verified again.
09FAQ
Frequently asked questions
No. The memo records both what was checked inside the agreed scope and the areas that were not. It does not certify security or compliance.
We divide ownership first: what the in-house team keeps and what we take over is written down, while defect severity criteria and the reporting format stay unified so the release decision rests on one set of evidence.
Yes. We weigh run frequency against maintenance cost and automate the highest-priority journeys first, replacing volatile screen areas with API-level checks or leaving them to manual validation.
You receive the deliverable listed for each stage exactly as it is. Reports come as a document plus the underlying data, and test cases and automation scripts are handed over together with repository access.
Remote delivery is the default, and on-site work is also available. If the test environment is accessible only from your internal network, we first define account access and data-export restrictions, then agree on on-site staffing and duration.
We report defects and remaining risks weekly in a consistent format. Each defect includes severity and reproduction conditions, alongside release readiness, so approvers can decide from the same evidence.
We share the findings from the first stage, then agree scope and schedule on that basis before delivery. A finished request for proposal is not required: the current environment and the outcome you want are enough to start.
Software Quality & Release
2026-09-26 · 21 min read
Logged in, but seeing another customer's orders: multi-tenant authorization testing
Multi-tenant authorization tests must go beyond changing users and roles.
Software Quality & Release
2026-08-28 · 16 min read
How should you set the pre-release verification scope for an AI-built app?
Sorts authentication, authorization, data, payments, external APIs, secrets, and operational risk by failure impact across twelve areas, and says how deep each must be verified before release.
Software Quality & Release
2026-08-28 · 19 min read
What to agree on before accepting outsourced or SI deliverables
Splits acceptance into a functional gate and an operational gate, and sets source, repository, build, deployment, accounts, data, recovery, security, and ownership against evidence and HOLD conditions.
12Related resources
Resources for this service
Guides and checklists you can use during review and kickoff.
See all resources
Guides
2026.09.04
A guide to sizing and pricing outsourced software QA
Why a QA quote lands where it does, broken into six variables and the direction each one moves the effort.
Guides
2026.06.24
Pre-release QA review — a guide for buyers
What to weigh when a release date is set and you are deciding whether to bring in an outside review — timing, inputs, how scope is cut, and how long it takes.
Brochures
2026.09.04
Software QA services overview · 2026
What IXC takes on across six QA services, the order the work runs in, and the deliverable that leaves each stage.
Contact
Contact us
Tell us your current environment and target outcome, and our team will review it and reply.
Direct line
Phone lines are open weekdays 09:00–18:00
ServiceRelease Readiness Review
Collection and use of personal information
- Purpose · Responding to and following up on this inquiry
- Items · Name, company, work email, message, visit source (first page visited, referring site domain, campaign parameters)
- Retention · 36 months from the date consent is given
You may decline; the inquiry cannot be submitted without consent.
More ways to explore