The flagship QA package
Know whether your release is safe to ship, with evidence
QA & Release Readiness is one week of structured testing that ends in a written call: ship, ship with known risks, or hold until specific defects are fixed. Testing covers your critical flows on the devices your users own, and the defect report gives your developers a prioritized list to work from.
What you get
What’s included
Test strategy for this release
What gets tested, on which devices, and what counts as a pass, scoped to your product and this specific release.
Critical flows tested end to end
Sign-up, payment, the main daily action and anything else that breaks trust when it fails, tested from first tap to final screen.
Exploratory testing
Someone paid to break things, trying the odd paths real users take: backgrounding mid-workout, losing signal, tapping submit twice.
Device and browser matrix
Agreed from your user analytics, with physical devices for the defects emulators miss, like permission dialogs, background sync and keyboard overlaps.
Prioritized defect report
Each defect with severity, environment, exact steps to reproduce, frequency and the reason it matters to users, so developers fix instead of investigate.
Regression checklist
A reusable list of what to re-test before every future release. Your team keeps it.
Written go/no-go recommendation
Ship, ship with listed risks, or hold, with the reasoning attached. The final decision stays with you.
A good fit if
- Teams with a launch or major release coming and nobody who owns testing
- Founders testing the app themselves on their own phone
- Products where repeat bugs are dragging down store ratings
- Health and mental-health apps that need crisis paths and submission risk checked before launch
Not included
- Fixing the defects we find, which falls to your developers or a separate engineering scope
- Security testing, privacy compliance or clinical safety sign-off
- Accessibility conformance certification
- Writing an automated test suite
How it runs
From kickoff to handover
- Step 1
Scope and matrix
We agree the critical flows, acceptance criteria, test data and device matrix with you, and write the test strategy.
- Step 2
Explore and log
Flow and exploratory testing across the matrix. Defects land in the report as they're found, each with reproduction steps.
- Step 3
Regression and fix checks
The regression checklist runs against every critical flow, and fixes your team ships during the week are re-tested.
- Step 4
Go/no-go
A release risk summary and a written recommendation, with the evidence behind it, before your release date.
Questions
Questions about QA & Release Readiness
What happens if the answer is no-go?
The report names the defects that block the release and why. The report is prioritized, so your developers fix the blockers first and leave the rest for a later release. Once the fixes are in, a smoke test or regression cycle confirms them.
Does this cover App Store and Google Play submission?
It covers submission risk as part of the release review. If you want a dedicated pass over the listing, metadata, permissions and the submission itself, App-store release readiness does that as its own package.
Can our developers keep shipping fixes during the week?
Yes. Fixes they ship are re-tested within the week where timing allows, and the go/no-go is based on the build you plan to release.
We have no test plan or acceptance criteria. Is that a problem?
No. Writing the test strategy is the first part of the package. If you ran a planning sprint with us, its acceptance criteria become the test plan directly.
Is one week enough for a large product?
For one release of a focused product, yes. The package covers the critical flows, not every screen. If the product is large or ships often, ongoing QA spreads the coverage across regular cycles.
More from QA & Release
Keep exploring
Often paired with this
Work with us
Ready to start QA & Release Readiness?
Tell us about your business. We'll confirm the scope and send you a start date.