«Часто слышу вопрос: как протестировать всё за короткий срок? Давление сроков, изменение приоритетов, тревога перед релизом — в такие моменты мне помогает подход, который приносит ясность: тестирование на основе риска.
В этом посте я хочу рассказать на примере, как я применяю этот метод в условиях жестких сроков.
Что такое тестирование на основе риска
Тестирование на основе риска (Risk-Based Testing, RBT) — это стратегия, которая помогает расставить приоритеты в тестировании, исходя из уровня риска.
Всё начинается с двух простых вопросов:
– Какова вероятность ошибки в этом месте?
– Если ошибка случится, насколько серьёзно она повлияет на бизнес?
Перемножив эти показатели, вы получаете оценку риска, которая показывает, на что обратить внимание в первую очередь. Это важно в проектах с ограниченным временем и ресурсами.
Моя оценка рисков в случае фичи User Journey
В одном из недавних релизов мы внедрили новый движок правил (rule engine), который определяет, может ли пользователь пройти определенный путь в приложении, в зависимости от условий. Это напрямую влияло на пользовательский опыт и бизнес-логику — а времени на тестирование было всего несколько дней.
Я решила применить тестирование на основе риска, чтобы максимально эффективно использовать отведенное мне время.
Требования
Изменение должно было:
– Не повлиять на существующих пользователей
– Позволить входить новым подтвержденным пользователям
– Исключить пользователей, которые не соответствуют обновленным критериям
Анализ рисков
- Негативное влияние на существующих пользователей — средняя вероятность × высокий уровень воздействия → оценка риска: 6 (приоритет 1)
- Новые подтвержденные пользователи не входят в систему — высокая вероятность × средний уровень воздействия → оценка риска: 6 (приоритет 1)
- Пользователи, не соответствующие требованиям, остаются в системе — средняя вероятность × средний уровень воздействия → оценка риска: 4 (приоритет 2)
- Ошибочные сообщения в интерфейсе — низкая вероятность × средний уровень воздействия → оценка риска: 2 (приоритет 3)
Как я тестировала
– Сначала проверила, что существующие пользователи не затронуты.
– Затем убедилась, что новые подтвержденные пользователи успешно проходят в поток.
– Проверила, что неподтвержденные пользователи блокируются, и видят правильные сообщения об ошибках.
– В конце сверила логику на сервере с отображаемыми сообщениями в интерфейсе.
Все сценарии тестировались вручную как на UI, так и на бекенде.
Результаты я обсудила с командой и дважды проверила все критические пути с высоким риском.
Итог
Когда времени мало, важно тестировать умно — а не всё подряд. Тестирование на основе рисков помогает сосредоточиться на действительно важных вещах. Это не просто метод — это изменение мышления.»
