Risk-based test planning

Risk-Based Testing

Test effort follows risk: find what this change could break and how badly, then choose the checks that would catch it.

Rate the risk

For each area the change touches, rate impact and likelihood as high, medium or low:

• Impact: money, data loss or corruption, security and privacy, legal exposure, a main user flow, many users.
• Likelihood: new or complex logic, many branches, concurrency, external dependencies, code that changes often or broke before, no existing tests, unclear requirements. High impact with high likelihood gets the deepest checks, first; low with low gets a smoke check or none. Write the ratings down, so every gap is a decision and not an accident.

Choose the checks

Pick from these where the risk is:

• Input: empty, missing or null; wrong type or format; boundaries (0, 1, the maximum and one past it, negative); very long, unicode, emoji, whitespace and special characters; duplicates; the same input sent twice.
• Sequence and state: steps out of order, going back, double submit, refresh mid-flow, an expired session, stale data.
• Interruption: a timeout, a slow or failing dependency, a retry after partial success, a crash between steps.
• Concurrency: two users or two requests changing the same record; the same job running twice.
• Access: what each role may do and what it must not; another user's or tenant's id in the request; signed-out calls.
• Data: tenant isolation, existing data after a migration, time zones, locales, rounding of money.
• Integration: contracts with callers and external services; webhooks arriving twice, late or out of order.
• Regression: the flows that share the changed code.

Levels and doubles

• Unit checks for pure logic, integration checks across a boundary (API, database, files), end-to-end checks only for the critical user flows. Most checks should be small and fast.
• Prefer the real implementation, then a fake, then a stub. Mock only slow, nondeterministic or side-effecting boundaries such as external APIs, email and payments.

Tests that check behavior

• Test through the public interface what users and callers care about, so tests survive refactors.
• Assert outcomes, not which internal methods were called; verify through the interface, not by reading the database behind it.
• Expected values come from the spec or a worked example, never from repeating the code's own computation.
• One behavior per test, named as a statement ("rejects an empty title"), in arrange, act, assert order.
• Each test creates and cleans up its own data; no order dependence, sleeps or real network.
• A new test counts only after it was seen failing for the right reason.

By phase

• Specification: turn acceptance criteria into testable statements and list the high-risk cases they must cover.
• Implementation plan: map each high- and medium-risk area to its checks and test level; name what will not be tested and why.
• Implementation: write the checks with the code, run them, and report coverage against the risk list.

Before you finish

• Risk areas rated; high risks have checks at the right level.
• Input, failure, access and concurrency cases chosen where the risk is.
• Tests assert behavior through public interfaces with independent expected values.
• What was not tested is stated with a reason.