SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsrisk-based-testing

risk-based-testing

Testing & quality

View repository

Updated 10-16 09:56

About this skill

Risk-Based Testing

References: Hans Schaefer, "Risk-Based Testing"; James Bach, "Heuristic Risk-Based Testing"; ISTQB Advanced Test Manager.

Applicable Scenarios

  • Not enough test time, need to decide what to test first
  • Assess the risk of "not tested" before release
  • Urgent fix verification (impact scope analysis)
  • Cross-module feature launch (risk point identification)
  • Basis for negotiating with PM on "what not to test"

Core Principles

1. 不能测所有东西
   接受这个事实是 RBT 的起点

  1. Testing is for "exposing risk" It is not to verify that development is right, but to verify "where it will go wrong"

  2. Risk = Probability × Impact Both dimensions must be quantified, not guessed

  3. Risk changes dynamically with time and changes Reassess every iteration

  4. Communication is more important than the matrix The matrix is a tool; the goal is to align with the team on "what risk is acceptable"


## 风险矩阵（5×5 标准模型）

```text
影响 ↑
  5 │ M  H  H  C  C
  4 │ L  M  H  H  C
  3 │ L  M  M  H  H
  2 │ L  L  M  M  H
  1 │ L  L  L  M  M
    └──────────────→ 概率
      1  2  3  4  5

L 低风险（接受）
M 中风险（监控）
H 高风险（必须测试 / 缓解）
C 关键风险（不测就不上）

Impact Dimension (Business Perspective)

Level User Impact Business Impact Fix Cost
5 Critical All users blocked, data loss Financial loss, compliance Emergency rollback + overtime fix
4 Severe Some users blocked Customer complaints, SLA breach Same-day hotfix
3 Medium Feature unavailable but has a workaround Experience degraded Fix in next version
2 Minor Intermittent / UI issue Almost none Schedule a fix
1 Negligible Edge scenario None Can be left unfixed

Probability Dimension (Technical Perspective)

Level Trigger Condition Historical Data
5 Extremely High Main path always triggers Same module had bugs in the previous version
4 High Common paths trigger Similar business has occurred
3 Medium Some users trigger Intermittent records
2 Low Rare combination triggers No history
1 Extremely Low Extreme edge scenario Theoretically possible

Risk Identification Checklist (James Bach Heuristic)

Business Risk

  • Involves money (payment / refund / deduction)
  • Involves privacy (PII / health data / identity)
  • Involves compliance (GDPR / MLPS / industry regulations)
  • Affects brand (user-facing / media-visible)
  • Affects SLA / contractual obligations

Technical Risk

  • New technology / new dependency (first use)
  • Refactoring (behavior should not change but is hard to prove)
  • Cross-service / cross-data center
  • Asynchronous / concurrent / distributed
  • Depends on third parties
  • Performance-sensitive (high QPS / large data)

Process risk

  • Multiple participants (communication gaps)
  • Tight timeline (rushing to launch)
  • Large differences between test and production environments
  • Data migration
  • Immature canary release strategy

Historical risk

  • Bug in a previous version of the same module
  • Incidents have occurred in similar business
  • Bugs have occurred in code written by the same developer
  • Historical bugs with unstable reproduction probability

Workflow

1. 识别风险点（用上面 Checklist）
   ↓
2. 给每个风险打分
   - 概率 P (1~5)
   - 影响 I (1~5)
   ↓
3. 排序
   按 P × I 倒序
   ↓
4. 分级处理
   - C（关键）→ 必测 + 多种方法 + 评审
   - H（高）→ 必测 + 标准方法
   - M（中）→ 选测 + 单一方法
   - L（低）→ 接受 / 不测 / 监控
   ↓
5. 与 PM / Tech Lead 评审
   - 哪些可以"不测"
   - 哪些需要额外资源
   - 哪些需要灰度 / 监控兜底
   ↓
6. 输出风险登记表

Risk register (deliverable)

ID Risk description Probability Impact Level Test strategy Mitigation measures Owner Status
R1 Payment idempotency failure causing duplicate charges 4 5 C Full-path + concurrency testing 5% canary + monitoring QA + Dev ✅ Tested
R2 Large order pagination timeout 3 4 H Performance test with 10,000 orders Indexing + pagination optimization DBA ⏳ In progress
R3 Mobile iOS 18 compatibility 2 3 M Main path manual testing Customer complaint monitoring QA Accept

Time allocation model (80/15/5)

80% 时间 → 关键和高风险（C + H）
  - 完整用例 + 多角度方法
  - 自动化优先

15% 时间 → 中风险（M）
  - 主路径用例
  - 选测，时间充裕再补

5% 时间 → 低风险（L）
  - 抽样 / 探索式 / 监控
  - 显式记录"接受"

Decision table: when to escalate risk

Trigger condition Action
C-level risk + insufficient time Delay launch / cut scope / request additional resources
H-level risk + bug found in testing Escalate to C, reassess launch
M-level risk + past incidents Escalate to H
Multiple H risks overlap Escalate overall to C handling

Combine with other tools

+ test-strategy：测试范围按风险分配
+ test-case-design：高风险路径多种方法覆盖
+ exploratory-testing：高风险区域 charter
+ regression-testing：高风险点纳入回归核心
+ quality-gate：C/H 级风险必须 0，否则不放行

Quality self-check

□ 每个风险都有概率 × 影响打分
□ 打分有依据，不是拍脑袋
□ C 级风险有缓解措施（不只是测试）
□ 风险登记表与 PM/Tech Lead 评审过
□ "不测"的低风险有显式记录和接受
□ 时间分配按 80/15/5
□ 历史 Bug 转化为风险点
□ 灰度 / 监控作为风险兜底（不只是测试兜底）

Common pitfalls

  1. Risk scoring by gut feeling——Different people rate the same risk H/L very differently; there must be a basis
  2. Only identifying technical risks——Miss the four dimensions of business, process, and history
  3. Risk register not updated——A pre-launch snapshot that no one looks at
  4. Solving C-level risks by "testing rigorously"——Should cut scope / canary / delay
  5. Allocating time evenly——80% of modules get 80% of time, but C-level gets only 5 hours
  6. Making decisions without communication——QA unilaterally says "not testing," PM is unaware
  7. Historical bugs not reused——Similar issues from the previous version were not included as new risks
  8. Mitigation measures = writing more test cases——Ignoring non-testing means such as canary, monitoring, and rollback

Supporting templates

  • templates/risk-register-template.md — risk register + probability-impact matrix + mitigation measure tracking

Collaboration with other skills

上游：
  test-strategy → 提供测试范围
  历史 field-journal → 提供历史风险

下游：
  test-case-design → 高风险用例细化
  exploratory-testing → 高风险区域 charter
  regression-testing → 风险点入回归
  quality-gate → 风险等级转化为放行条件
  test-report → 风险结论作为最终判断