Risk-Based Testing — Deciding What NOT to Automate

The idea, in one line

Spend your testing effort where a failure would hurt most. Every automated test is code you write once and maintain forever, so spreading effort evenly across the app is a beginner move. Risk-based testing helps you spend it on purpose.

How to score it

Risk is two things multiplied together:

• Probability — how likely is this to break? Score it 1 to 5.
• Impact — how bad is it if it does? Score it 1 to 5.
• Risk = probability x impact. The bigger the number, the more testing it earns.

See it work

# Rank features by risk to decide how much to test each
features = [
    {"name": "checkout_payment", "prob": 4, "impact": 5},
    {"name": "profile_avatar",   "prob": 2, "impact": 1},
    {"name": "help_footer_link", "prob": 1, "impact": 1},
]

for f in features:
    f["risk"] = f["prob"] * f["impact"]

# Highest risk first -> most testing effort
for f in sorted(features, key=lambda f: f["risk"], reverse=True):
    plan = "automate deeply" if f["risk"] >= 8 else "smoke or skip"
    print(f'{f["name"]:16} risk={f["risk"]:>2}  -> {plan}')

Read it top to bottom: you scored each feature, multiplied, sorted highest-risk first, then drew a line — deep automation above it, a quick check or nothing below.

Advanced — the technique follows the risk

Risk doesn't just decide whether to automate — it decides how hard. High-risk logic earns the rigorous tools from the last two lessons: full decision tables and boundary sweeps. Low-risk inputs get a single value from one bucket. Same toolbox, effort matched to what's at stake.

Grounded in Guru99's Risk-Based Testing guide (probability x impact)