Manual Testing

БЛОК 4. Тест-дизайн техники — 14. Risk-based testing

📚 25 вопросовПройти тест →
Лекция

БЛОК 4. Тест-дизайн техники — 14. Risk-based testing

Manual Testing

БЛОК 4. Тест-дизайн техники — 14. Risk-based testing

🧭 Введение: почему «проверить всё» почти никогда невозможно

В реальном проекте у QA всегда ограничены время, окружения и ресурсы. Если пытаться протестировать всё одинаково глубоко, команда не успевает закрыть критичные риски к релизу.
Risk-based testing помогает принять инженерное решение: что проверяем в первую очередь, что проверяем проще, а что осознанно переносим.
💡 Совет:
Когда времени мало, не сокращайте случайно. Сокращайте по риску.
✅ Вывод:
Risk-based testing — это не «меньше тестов», а «правильный приоритет тестов».

⚠️ Проблема -> решение

Проблема: одинаковая глубина проверки для всех сценариев создаёт ложное равенство. Ошибка в неважном tooltip и ошибка в оплате не должны получать одинаковый вес.
Решение — оценивать риск как комбинацию вероятности и влияния, затем строить план проверки по уровню риска.
🟢 Если совсем просто:
Чем больнее и вероятнее проблема, тем раньше и глубже её тестируем.
🎯 Как понять, что этап прошёл успешно:
У вас есть приоритизированный тест-план, где critical/high риски закрываются до релиза в первую очередь.

🛠️ Чем помогает и как работает

Risk-based подход делает релизное тестирование управляемым. Он позволяет объяснить команде, почему проверялись именно эти сценарии и какие риски остаются.
Как это работает:
  • Шаг 1: составляем список функций, потоков и зависимостей.
  • Шаг 2: для каждой зоны оцениваем вероятность дефекта.
  • Шаг 3: оцениваем влияние дефекта на бизнес/пользователя.
  • Шаг 4: формируем риск-уровень (critical/high/medium/low).
  • Шаг 5: назначаем глубину тестирования по уровню риска.
  • Шаг 6: фиксируем остаточный риск и релизное решение.
✅ Вывод:
Risk-based testing связывает технические проверки с бизнес-риском релиза.

📚 Ключевые термины (простыми словами)

  • Risk-based testing (тестирование на основе рисков) — подход, где объём и глубина тестов определяются риском.
  • Probability (вероятность) — шанс, что дефект появится.
  • Impact (влияние) — насколько сильно дефект повлияет на бизнес/пользователя.
  • Risk Score (оценка риска) — итоговый уровень риска из вероятности и влияния.
  • Risk Matrix (матрица рисков) — таблица, где риски разложены по уровням.
  • Critical Path (критичный путь) — поток, поломка которого блокирует ключевую ценность продукта.
  • Residual Risk (остаточный риск) — риск, который осознанно остаётся после тестирования.
  • Release Recommendation (релизная рекомендация) — вывод QA о готовности релиза с учётом рисков.

1. Что такое риск в контексте тестирования

Для QA риск — это не «ощущение», а конкретная оценка: насколько вероятно, что сломается, и насколько больно это будет.
🟢 Если совсем просто:
Риск = шанс проблемы * цена этой проблемы.
🎯 Как понять, что этап прошёл успешно:
Для каждого важного сценария указаны вероятность и влияние.
Назначение:
Отделить действительно опасные зоны от второстепенных.
Простыми словами:
Мы оцениваем, где ошибка наиболее вероятна и наиболее дорогая.
Для новичка:
Если дефект может повлиять на деньги, доступы или данные пользователя — это почти всегда high/critical риск.
Аналогия:
Как в медицине: сначала лечат угрозу жизни, потом мелкие симптомы.
Пример:
Фича: ОплатаProbability: mediumImpact: criticalRisk: high/critical
🔎 Как это происходит на практике:
  • QA обсуждает риски с PO/Dev.
  • Смотрит инциденты прошлых релизов.
  • Помечает критичные потоки в тест-плане.
Характеристики:
  • ✅ Прозрачная приоритизация.
  • ✅ Меньше случайных решений.
  • ✅ Легче защищать релизную позицию.
Когда использовать:
Всегда, особенно перед релизом и при дефиците времени.
✅ Вывод:
Риск-оценка — базовая часть зрелого QA-процесса.

2. Матрица рисков: практический инструмент

Risk matrix помогает быстро визуализировать приоритеты. Даже простая шкала 1–3 или 1–5 уже даёт хороший рабочий ориентир.
🟢 Если совсем просто:
Матрица рисков показывает, что тестировать первым, а что можно облегчить.
🎯 Как понять, что этап прошёл успешно:
Каждый ключевой сценарий имеет риск-уровень и связанный уровень тест-глубины.
Назначение:
Превратить субъективные обсуждения в структурное решение.
Простыми словами:
Это таблица приоритетов тестирования.
Для новичка:
Не обязательно строить сложную математику. Начните с «низкий/средний/высокий».
Пример:
Risk matrix (3x3):Impact \ Probability- Low / Medium / High Rule:- High*High => Critical- High*Medium => High- Medium*Medium => Medium
🔎 Как это происходит на практике:
  • QA заполняет матрицу по главным потокам.
  • Согласует оценки с командой.
  • На основе матрицы строит run order.
Характеристики:
  • ✅ Видно, что важно для релиза.
  • ✅ Упрощает коммуникацию на sync.
  • ✅ Помогает управлять scope.
Когда использовать:
На этапе тест-планирования и перед release decision.
✅ Вывод:
Матрица рисков — рабочий язык между QA, Dev и бизнесом.

3. Глубина тестирования по уровню риска

В risk-based подходе разные зоны проверяются с разной глубиной. Это нормально и правильно, если критерии прозрачны.
🟢 Если совсем просто:
Critical проверяем глубоко, low — быстро и выборочно.
🎯 Как понять, что этап прошёл успешно:
В тест-плане явно прописано, какую глубину получает каждый риск-уровень.
Назначение:
Оптимально распределить время QA по ценности и опасности.
Простыми словами:
Не все сценарии равны — и тестировать их нужно по-разному.
Для новичка:
Сначала закрывайте риски, которые могут «положить» релиз.
Пример:
Critical risk:- full happy+negative+boundary+edge- cross-env checks Medium risk:- core happy+selected negative Low risk:- smoke-level validation
✅ Вывод:
Глубина тестов должна соответствовать риску, а не быть одинаковой для всего.

4. Residual risk: что делать с тем, что не покрыли

Даже при хорошем плане часть рисков остаётся непокрытой из-за времени, среды или внешних ограничений. Это не провал, если риск зафиксирован и осознанно принят.
🟢 Если совсем просто:
Непокрытый риск нужно не скрывать, а явно зафиксировать.
🎯 Как понять, что этап прошёл успешно:
У релиза есть список остаточных рисков и согласованное решение по ним.
Назначение:
Сделать релизное решение прозрачным и ответственным.
Простыми словами:
QA честно показывает: что проверено, что не проверено, и чем это грозит.
Для новичка:
Фраза «не успели» без оценки риска — слабый формат коммуникации.
Пример:
Residual risk:- Mobile Safari payment retry not testedImpact: highMitigation: monitor + hotfix readiness
✅ Вывод:
Residual risk — обязательная часть зрелой релизной коммуникации.

5. Пошаговый алгоритм risk-based testing

Ниже рабочий шаблон, который можно применять в каждой задаче перед релизом.
🟢 Если совсем просто:
Список зон -> оценка риска -> приоритеты -> тест-глубина -> остаточный риск.
🎯 Как понять, что этап прошёл успешно:
Есть понятный документ с рисками, покрытием и релизной рекомендацией.
Алгоритм:
  1. Составить список функций и потоков.
  2. Оценить вероятность и влияние по каждому потоку.
  3. Построить риск-матрицу и уровни.
  4. Назначить глубину тестирования по уровню.
  5. Выполнить план в risk-based порядке.
  6. Зафиксировать остаточные риски и рекомендации по релизу.
✅ Вывод:
Алгоритм помогает junior QA принимать зрелые решения под дедлайн.

📊 Сравнение: обычный подход vs risk-based

ПодходЧто происходитРезультат
Равномерное тестированиеВсё проверяется «примерно одинаково»Критичные риски могут остаться без глубины
Risk-based testingПроверка по приоритету рискаКритичные зоны закрываются в первую очередь

✅ Must-Know для junior QA

  • Risk-based testing = приоритет по риску, а не по удобству.
  • Вероятность и влияние оцениваются отдельно.
  • Критичные потоки проверяются глубже всех.
  • Остаточные риски нужно явно фиксировать.
  • Release recommendation должна ссылаться на риск-картину.
  • Нельзя скрывать непокрытые high/critical риски.
  • Матрица рисков должна быть согласована с командой.

❌ Частые мифы

❌ Миф:
Risk-based testing — это «тестируем меньше». ✅ Как правильно:
Это «тестируем приоритетно и осознанно». 📎 Почему это важно:
Иначе сокращение становится хаотичным и опасным.
❌ Миф:
Оценка риска — задача только менеджера. ✅ Как правильно:
QA обязан участвовать в оценке рисков, потому что это основа тест-приоритета. 📎 Почему это важно:
Без QA риск-оценка теряет техническую точность.
❌ Миф:
Если что-то не протестировано, об этом лучше не говорить. ✅ Как правильно:
Непокрытые риски фиксируются как residual risk. 📎 Почему это важно:
Прозрачность снижает неожиданные инциденты и повышает доверие к QA.
❌ Миф:
Все баги одинаково важны. ✅ Как правильно:
Важность зависит от влияния и вероятности. 📎 Почему это важно:
Это определяет реальный приоритет исправления и тестирования.

❓ Часто спрашивают на собеседованиях

❓ Вопрос:
Что такое risk-based testing? ✅ Ответ:
Это подход, в котором приоритет и глубина тестирования определяются уровнем риска сценария.
❓ Вопрос:
Как вы рассчитываете риск? ✅ Ответ:
Через оценку вероятности дефекта и его влияния на бизнес/пользователя, обычно с матрицей уровней.
❓ Вопрос:
Что вы делаете, если не успеваете протестировать всё? ✅ Ответ:
Закрываю critical/high зоны, фиксирую residual risk по остальному и даю прозрачную release recommendation.
❓ Вопрос:
Что такое residual risk? ✅ Ответ:
Это риск, который остаётся после тестирования и осознанно принимается перед релизом.
❓ Вопрос:
Как объяснить команде, почему сценарий в high приоритете? ✅ Ответ:
Через риск-оценку: высокая вероятность и/или высокое влияние на ключевой бизнес-поток.

🚫 Типичные ошибки

Ошибка 1: Приоритизация «по настроению»

❌ Неправильно:
Ставить приоритеты без критериев вероятности и влияния.
✅ Правильно:
Использовать риск-матрицу и согласованные шкалы.
Почему:
Это убирает субъективность и споры.

Ошибка 2: Игнорируют low вероятность при high impact

❌ Неправильно:
Считать редкий, но критичный дефект «несущественным».
✅ Правильно:
Оценивать редкие high-impact риски как приоритетные.
Почему:
Именно они часто дают самые тяжёлые инциденты.

Ошибка 3: Не фиксируют residual risk

❌ Неправильно:
Завершить тестирование без списка непокрытых рисков.
✅ Правильно:
Явно документировать остаточные риски и mitigations.
Почему:
Это основа ответственного релизного решения.

Ошибка 4: Нет связи risk -> test depth

❌ Неправильно:
Critical и low сценарии тестируются одинаково.
✅ Правильно:
Глубина тестирования должна соответствовать уровню риска.
Почему:
Иначе ресурс тратится неэффективно.

🧩 Best Practices

  • Держите простую, но регулярную риск-матрицу.
  • Согласовывайте risk levels с PO и Dev до execution.
  • Явно привязывайте тест-глубину к risk level.
  • Перед релизом отдельно обсуждайте residual risks.
  • Используйте историю инцидентов для уточнения вероятности.
  • Всегда документируйте release recommendation в risk-терминах.

🏁 Заключение

Risk-based testing — это зрелый способ управлять качеством под ограничения.
Он помогает тестировать не «равномерно», а «разумно»: сначала то, что реально может сломать релиз.
Для junior QA это ключевой шаг от «исполнителя проверок» к инженеру, который влияет на релизные решения.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 4. Тест-дизайн техники — 14. Risk-based testing»

Пройти тест →