In this guide
Say testing found 40 issues (an example number) and the release date is close. You cannot fix everything, and you do not have to. The question is not "is the app perfect?" but "is it safe and good enough to put in front of real users?" A short triage gives you the answer in an hour.
Step 1: Collect and merge
Put every issue in one list. Merge duplicates and keep one line each: what happens, where, how often. Delete anything you cannot act on, or move it to a "need more info" list (see cannot reproduce a tester's bug).
Step 2: Score severity and reach
For each issue, give two ratings.
Severity: what does it do to the user? - 3, Critical. Crash, data loss, cannot sign in, cannot pay, security or privacy problem. - 2, Serious. A main feature is broken or confusing, but there is a workaround. - 1, Minor. Cosmetic, rare, or a side feature.
Reach: how many users will meet it? - 3, almost everyone, on the main path. - 2, a clear group (a device type, a setting, a language). - 1, rare case.
Step 3: Triage matrix
| Reach 1 | Reach 2 | Reach 3 | |
|---|---|---|---|
| Severity 3 | Fix before release | Fix before release | Fix before release |
| Severity 2 | Later | Fix if cheap, otherwise decide | Fix before release |
| Severity 1 | Later | Later | Fix if cheap |
Severity 3 always blocks the release, even when rare. A rare crash that loses a user's data still costs trust. Anything in the "Later" cells goes on a list with a target version.
Step 4: Add effort
Look at what is left in the "fix if cheap, otherwise decide" cells. Estimate effort in three sizes: under an hour, about a day, more than a day. Take the quick ones first. A day-long fix for a Severity 2, Reach 2 issue is a real choice, not an automatic yes.
Step 5: Decide what ships
Ask three questions:
- Is any release blocker left open? If yes, you are not ready.
- Can the rest wait for the first update? Write it down with a target version.
- Can you reduce the risk instead of fixing it? Hide an unfinished feature, add a safe fallback, or limit the first release to fewer devices or countries.
If you cannot answer yes to the first and second, move the date. A short delay costs less than a launch with broken basics.
Tips for solo developers
- Time-box triage. One hour, no more.
- Fix in rounds. Blockers first, test again, then the cheap ones.
- Do not fix and add features at once. New code brings new bugs.
- Re-test the main path (install, sign in, the one core task) on at least one real device after the last change.
- Keep a crash view. For crashes, see how to read and prioritize crash reports; for non-crash feedback, how to prioritize app feedback.
Related
- Overview: App testing problems and fixes
- Too many feature requests from testers
- How to get crash logs from a tester's phone
Need a second set of eyes on the release candidate? AppReviewX gives you private, structured feedback from other developers; one feedback you write earns one credit. See how AppReviewX works