Your launch date is set, the demo looks great, and everyone is asking for the green light. Then someone asks the question nobody wants to answer: how much of this system is actually tested? For most custom builds, the honest answer is "the parts we demoed." That gap between what works in a scripted walkthrough and what survives real users is where launch risk hides.
A custom software qa audit is a structured, time-boxed inspection you run before go-live. It is not a re-test of everything and it is not a code review. It is an evidence-based check of whether your testing, defect handling, and release process are strong enough to justify shipping. Done well, it takes days, not weeks, and it either gives you a defensible go decision or surfaces the specific gaps worth delaying for.
This framework is the one we use when clients ask us to independently assess a build before launch. It assumes you already have a working product and a team that wants to ship.
Key takeaways
- A QA audit is an evidence review, not a re-test. You are checking whether the team can prove what they claim about quality.
- Coverage should be judged by risk, not by a percentage. Money paths, auth, data integrity, and integrations matter far more than UI polish.
- Defect data is the fastest signal: look at severity mix, age of open bugs, and whether criticals are actually closed.
- Release readiness lives in the boring parts: rollback plan, migrations, monitoring, and who is on call at launch.
- A short list of known, accepted risks signed off by a named owner is worth more than a vague promise that everything is fine.
What a custom software QA audit actually inspects
Think of the audit as three evidence streams: test coverage, defect history, and release mechanics. Each one answers a different question, and together they tell you whether the launch is safe.
1. Test coverage, judged by risk
Coverage percentages are easy to game and rarely reflect real quality. Instead, map your system's critical paths and ask for evidence that each one is tested at the right level.
- Money and entitlement paths: payments, refunds, subscription state, quotas, and permission changes.
- Authentication and authorization: login, session expiry, role boundaries, password reset, and token revocation.
- Data integrity: create, update, delete, and the failure cases in between, including partial failures.
- Integrations: third-party APIs, webhooks, and what happens when they time out or return errors.
- Migrations: schema changes and backfills, ideally rehearsed against a production-sized dataset.
For each critical path, ask three questions: is there an automated test, does it assert meaningful behavior rather than just that the code ran, and does it run in CI on every change? A path with no automated test and no documented manual procedure is an open risk, not a covered one.
2. Defect tracking and history
Bug trackers are honest in ways status reports are not. Pull the last few release cycles and look at patterns.
- Severity mix: are criticals and highs being found, or is everything labeled "minor"? Uniform severity is a sign of poor triage.
- Age of open defects: a cluster of high-severity bugs open for months usually means they are either not real or not prioritized. Both are problems.
- Reopen rate: bugs that come back after being marked fixed point to weak verification, not just weak coding.
- Escape rate: defects found in production that testing should have caught. A rising trend is a direct warning about coverage quality.
You do not need perfect numbers. You need to see that the team finds bugs early, fixes them properly, and learns from what escapes.
3. Release readiness mechanics
This is where launches actually fail, and it is the most commonly skipped part of a pre launch quality assurance process.
- Rollback plan: can you revert the deploy and the database change independently? Who decides, and how fast?
- Feature flags: can you disable a risky feature without a redeploy?
- Migrations: are they backward compatible, and have they been run against realistic data volumes?
- Monitoring and alerts: error tracking, latency, queue depth, and business-level signals like failed payments.
- On-call and escalation: a named person, a channel, and a documented path for the first 72 hours.
How to audit software testing coverage without trusting a number
The most useful question is not "what percent is covered" but "what would break first, and would we know?" Run these steps in order.
- List the top ten user journeys by business impact, not by how often they appear in the UI.
- For each journey, request the exact test that proves it works, with a link to the file and the CI run.
- Check the assertions. A test that only checks for a 200 response proves very little.
- Look for negative cases. Invalid input, expired sessions, duplicate submissions, and network failures.
- Confirm the tests run automatically on every pull request, and that failures block merges.
- Note the untested paths and assign each a risk level and an owner.
If your team cannot produce tests for a critical journey on request, treat that journey as untested regardless of what the dashboard says.
The pre-launch QA checklist
Use this as a working document, not a formality. Every line should have an owner and an evidence link.
- Critical user journeys identified and each mapped to an automated or documented manual test.
- Authentication, authorization, and session handling tested including expiry and revocation.
- Payment and entitlement flows tested including failure, retry, and refund paths.
- Third-party integrations tested against timeout and error responses, not just the happy path.
- Database migrations rehearsed on production-scale data with a tested rollback.
- Load behavior verified at or near expected launch traffic, including the first-hour spike.
- Open defects triaged: every critical and high either fixed or explicitly accepted by a named owner.
- Monitoring, alerting, and error tracking live in production before the deploy.
- Rollback and feature-flag procedures documented and rehearsed.
- On-call rotation and escalation path confirmed for the launch window.
Reading the release readiness signals
By the end of the audit you should be able to state, in one paragraph, what you know, what you do not know, and what you are accepting. That paragraph is your go decision.
Green signals look like this: critical paths have automated tests that run on every change, high-severity bugs are found before release rather than after, the rollback path has been exercised, and monitoring is already live. The team can point to evidence quickly because it exists.
Red signals are subtler. A team that cannot produce test evidence on request. A bug tracker where nothing has been marked critical in months. A migration that has only ever run on an empty local database. A launch plan with no named on-call owner. None of these are fatal, but each one means you are shipping on hope rather than evidence.
Turning findings into a go or no-go decision
Sort every finding into three buckets. Blockers are issues that would cause data loss, security exposure, or revenue failure, and they must be fixed before launch. Accepted risks are known gaps you choose to ship with, each with a named owner and a follow-up date. Backlog items are improvements that can wait.
This triage is what separates a useful audit from a blocker-generating exercise. Most teams find a handful of real blockers, a longer list of accepted risks, and a backlog. If you want an outside pair of eyes on that triage, the team at Avaton runs these audits and builds the fixes that follow them.
If you are planning a build or a launch and want the quality groundwork done properly from the start, it is worth looking at how we approach custom software delivery. You can also review examples of systems we have shipped to see how these practices hold up in production, and if you would rather walk through your own release plan, talk to our team before you commit to a date.
Frequently Asked Questions
How long does a custom software QA audit take?
For a typical pre-launch product, a focused audit takes a few days to two weeks, depending on system size and how much test evidence already exists. The work is mostly evidence review and targeted verification rather than full re-testing, so it scales with the number of critical paths and integrations, not with the total codebase.
Do we need a QA audit if we already have automated tests?
Yes, and especially then. Automated tests can exist without asserting meaningful behavior, or they can cover easy paths while missing payments and permission boundaries. An audit checks what the tests actually prove, whether they run on every change, and which critical journeys remain untested despite a healthy-looking coverage number.
What is the difference between a QA audit and a code review?
A code review examines how the software is written. A QA audit examines whether the software is proven to work, how defects are handled, and whether the release process can recover from failure. They overlap slightly, but a code review alone will not tell you whether your rollback plan works or whether monitoring is live in production.
Which metrics matter most in a software testing gaps review?
Focus on defect escape rate, the age and severity mix of open bugs, and the percentage of critical user journeys with automated tests that run in CI. Coverage percentage alone is the least reliable signal because it counts lines executed, not behavior verified, and it is easy to inflate without improving quality.
Can we launch with known defects?
Often yes, if the defects are low severity, well understood, and explicitly accepted by a named owner with a follow-up date. The rule is simple: never launch with an unowned critical or high-severity defect. A short, written list of accepted risks is a normal and healthy part of a pre-launch quality assurance process.
Cover: Photo by qmicertification design on Pexels