Risk-Based Testing: как приоритезировать тесты по риску
Покрыть тестами всё приложение — нереально. Когда у тебя ограниченное время (всегда), приоритезация — единственный разумный подход. Risk-Based Testing (RBT) — формализованный способ её делать.
Концепция
Каждый элемент системы оценивается по двум осям:
— Likelihood (вероятность поломки): насколько часто может сломаться. — Impact (последствия): что произойдёт если сломается.
Risk = Likelihood × Impact
Тестируешь сначала высокий риск, потом средний, потом низкий.
Likelihood — что повышает вероятность поломки
- Новый или сильно изменённый код: статистика — новый код в 2-3 раза баггее старого.
- Сложная логика: cyclomatic complexity >10 → высокий риск.
- Зависимости от внешних систем: чем больше — тем выше шанс.
- Слабое покрытие тестами в прошлом: если модуль никто не трогал unit-тестами — много багов лежит.
- Команда без опыта в этой области: разработчик первый раз делает auth — больше шанс ошибиться.
Impact — что повышает последствия
- User-facing: критично если ломается то что видит юзер. Backend cron-job — менее.
- Revenue-related: IAP, корзина, оплата — высший impact.
- Безопасность: auth, permissions, шифрование — даже редкие баги критичны.
- Compliance: GDPR, PCI-DSS, медицинские данные — баг = штраф.
- Доступность: если упадёт, сколько юзеров не могут работать.
Матрица 3×3
| Low impact | Medium impact | High impact | |
|---|---|---|---|
| High likelihood | Medium risk | High risk | CRITICAL |
| Medium likelihood | Low risk | Medium risk | High risk |
| Low likelihood | Negligible | Low risk | Medium risk |
CRITICAL риски покрываются всеми возможными типами тестов (unit, integration, E2E, manual exploratory).
Medium и Low — basic покрытие, не отдельные ресурсы.
Практика для QA
1. Identifying
На этапе планирования релиза:
- Get list of changes (diff между прошлым и текущим релизом).
- For each module: какие части код изменились?
- Mark each: новая фича, рефакторинг, багфикс, переписан с нуля.
2. Scoring
Команда (QA + dev + продакт) пробегает по списку:
- Likelihood: 1-5 (где 5 = «скорее всего сломается»).
- Impact: 1-5 (где 5 = «продакшен в огне»).
- Risk score: умножаешь.
3. Prioritization
Сортируешь по убыванию score:
- Score 20+ (CRITICAL): глубокое тестирование — automation + manual + edge cases. На каждый scenario 5+ test cases.
- Score 12-19 (High): полное покрытие.
- Score 6-11 (Medium): smoke + happy path.
- Score <6 (Low): regression suite, может быть автоматизация на потом.
4. Documentation
Pisni risk register в Confluence/Jira:
Module: Payment
Change: New PayPal integration
Likelihood: 4 (новая внешняя интеграция)
Impact: 5 (money flow)
Score: 20 - CRITICAL
Mitigation:
- E2E test sandbox + production sandbox
- Refund flow tested manually
- Monitoring + alert on failed paymentsАнтипаттерны
❌ Risk score один раз и забыли. Risk меняется. Перепроводи оценку каждый sprint.
❌ Все critical. Если всё critical — ничего не critical. Будь жёстким.
❌ Игнорирование low risk. Это backlog, не «выбросить». Когда время появится — покрывай.
❌ QA в одиночку оценивает. Импakt знает продакт, likelihood — dev. RBT — командный процесс.
Что делать прямо сейчас
✅ Возьми последний релиз → составь список изменений → оцени каждое по матрице.
✅ Сравни — где у тебя реально были баги в проде с тем, что было High risk. Часто — точно совпадает.
✅ Используй это для следующего release planning — argument’и менеджеру «эти 5 фичей — High risk, мне нужно больше времени на них».
Подробнее: ISTQB Risk-Based Testing, Ministry of Testing — RBT articles.