Что такое Риск-ориентированное тестирование (RBT)

Любовь

Представьте: вы запускаете новую IT-систему для логистической компании. Через неделю — демо для ключевого клиента. В системе сотни функций: от создания заявки до отслеживания груза и формирования отчетов. Как проверить всё самое важное, если время ограничено?

Ответ — Риск-ориентированное тестирование (Risk-Based Testing, RBT). Это стратегический подход, который говорит: «Тестируй не всё подряд, а то, что важнее всего для бизнеса и клиента».

Проще говоря, RBT — это когда мы сначала думаем, а потом тестируем.

Простая формула риска

В основе RBT лежит простая, но мощная формула:

Риск = Вероятность × Влияние

Вероятность — насколько вероятно, что в этом модуле системы что-то сломается? (Например, из-за сложного кода, частых изменений или интеграций с другими сервисами)
Влияние (Ущерб) — какой ущерб понесет компания, если этот модуль перестанет работать? (Финансовые потери, срыв сроков доставки, потеря клиентов)

Чем выше оба показателя, тем выше риск и тем больше тестового внимания заслуживает эта часть системы.

Но сразу же возникает главный вопрос: как именно мы оцениваем Вероятность и Влияние? Что стоит за этими цифрами?

📌 Откуда берутся цифры? Согласованные критерии команды

Цифры 1, 2, 3 — это не случайные значения, а результат качественной оценки, основанной на заранее согласованных критериях. Команда договаривается, что они значат.

Пример шкалы для Вероятности (Probability):

3 (Высокая):

Изменения в сложном, "старом" (legacy) коде.
Код писал новый или неопытный разработчик.
У функции уже была история с дефектами.

2 (Средняя):

Стандартная доработка существующей стабильной функции.
Изменения в коде средней сложности.

1 (Низкая):

Косметические изменения (текст, цвет).
Изменения в простом, хорошо протестированном модуле.

Пример шкалы для Влияния (Impact):

3 (Критическое):

Блокер: Приложение падает, данные теряются.
Финансовый ущерб: Прямые потери денег (например, ошибка в расчете стоимости).
Безопасность: Утечка данных клиентов.
Репутационный ущерб: Потеря доверия ключевых клиентов.

2 (Среднее):

Основной сценарий работает с ошибкой, но есть обходной путь.
Значительные неудобства, но функционал доступен.

1 (Низкое):

Опечатка, неидеальное выравнивание.
Проблема на редком устройстве.

📊 Как мы принимаем решения? Матрица рисков

Чтобы понять, что "6 — это высокий риск", а "9 — критический", команда создает и согласовывает Матрицу Приоритетов Рисков.

Как читать эту матрицу и принимать решения:

🟥 Красная зона (Критический/Высокий риск, 6-9):

Действие: Обязательно к исправлению перед релизом. Эти риски неприемлемы. На них тратится большая часть времени тестирования. Релиз блокируется, пока они не будут устранены.

🟨 Желтая зона (Средний риск, 3-4):

Действие: Желательно исправить. Мы тестируем эти области, но если не успеваем, можем принять осознанное решение о выпуске. Дефекты часто попадают в бэклог.

🟩 Зеленая зона (Низкий риск, 1-2):

Действие: Исправляем по остаточному принципу. Можем спокойно выпускать. Тестируем в последнюю очередь.

💡 Практический пример из логистики

Сценарий: Калькулятор стоимости доставки.

Вероятность = 3 (Высокая): Сложный алгоритм, часто меняющиеся тарифы, интеграция с API топливных коэффициентов.
Влияние = 3 (Критическое): Ошибка в расчете ведет к прямым финансовым потерям (компания понесет убытки) или к потере клиента (завысили цену).
Риск = 3 × 3 = 9 (КРИТИЧЕСКИЙ!). Это красная зона. Тестируем в первую очередь, самые строгие тесты.

Сценарий: Раздел "Справочник типов груза".

Вероятность = 1 (Низкая): Простой справочник, данные меняются редко.
Влияние = 1 (Низкое): Временная недоступность справочника не критична, тип груза можно вписать вручную в примечании.
Риск = 1 × 1 = 1 (Минимальный). Это зеленая зона. Тестируем в последнюю очередь.

Какие плюсы у этого подхода?

Экономит время и деньги. Фокус на главном.
Повышает качество продукта. Критичные баги будут найдены и исправлены в первую очередь.
Улучшает коммуникацию. Все в команде понимают, почему мы тестируем одну функцию тщательнее другой.
Помогает в условиях острой нехватки времени. RBT — ваш лучший друг при "горящем дедлайне".

А есть ли минусы?

Главный минус — субъективность начальной оценки. Поэтому так важны коллективные обсуждения и согласованные критерии. RBT сознательно принимает риск упустить баг в "зеленой" зоне ради эффективности.

Вывод

RBT — это не слепое следование формуле, а образ мышления и структурированный процесс. Главная ценность — не в самих цифрах, а в процессе обсуждения, который заставляет всю команду задуматься о том, что в продукте действительно важно, и принять коллективную ответственность за риски.

Вместо паники «мы ничего не успеем проверить!» вы получаете четкий, обоснованный план действий, который максимально защищает бизнес от самых серьезных проблем.