AppReviewX Log in

Risk-based testing: decide what to test first

Rank features by impact and likelihood of failure to spend limited testing time well. A simple scoring template you can copy.

updated ·2 min read

In this guide

You never have time to test everything. Risk-based testing means you test first what would hurt most if it broke and is most likely to break. This page gives you a simple scoring sheet to copy.

How the scoring works

For each feature or flow, give two scores from 1 to 3:

  • Impact (I): how bad is it for users or you if this fails? 1 = annoying, 2 = blocks a task, 3 = lost data, lost money or the app is unusable.
  • Likelihood (L): how likely is it to fail? 1 = old, stable, untouched; 2 = changed a little; 3 = new, changed a lot, or depends on something outside your control (network, payment provider, OS version).

Risk = I x L. Scores 6-9 are tested first and on several devices. 3-4 get one pass. 1-2 are checked only if time is left.

Copy-paste template

Feature / flow | I (1-3) | L (1-3) | Risk | Test depth | Done? | Notes
---------------|---------|---------|------|------------|-------|------
               |         |         |      |            |       |

Test depth suggestion: 6-9 = full path plus error cases on at least two devices; 3-4 = happy path once; 1-2 = smoke check.

Example (illustrative, not real data)

Feature I L Risk Test depth
Sign-in 3 2 6 Full path, wrong password, offline
Purchase / subscription 3 3 9 Full path, cancel, restore, two devices
Profile photo upload 2 3 6 Large file, no permission, slow network
Settings: dark mode 1 2 2 Smoke check
About screen 1 1 1 Only if time is left

Adapt it to your app

  • Add columns that matter to you, for example "device/OS" or "owner" if several people test.
  • Raise Likelihood after every change. Anything touched in this release is at least a 2, even if it was stable before.
  • Raise Impact for data and money. Anything that writes user data, deletes it, or charges someone is a 3.
  • Re-score after real feedback. If testers keep hitting problems in an area, its likelihood was too low. See how to prioritize app feedback for sorting what comes back.
  • Keep it small. 10 to 20 rows is enough. A long sheet that nobody updates is worse than a short one.

Limits: the scores are your judgment, not measurements. Two people may score differently; that difference is a useful conversation, not an error.

AppReviewX gives you private, structured feedback from other developers on the areas you ranked highest. One feedback you write earns one credit; new accounts start with 0 credits. Start free.