В прошлом уроке мы разобрались, когда тестирование можно начинать и когда считать его завершённым. Но критерии входа не гарантируют, что всё пойдёт по плану уже В ПРОЦЕССЕ: сборка может задержаться, окружение — оказаться недоступным. Раздел тест-плана «Риски», отложенный ещё в уроке 13.1, как раз про это. Слово «риск» вам уже знакомо — в главе 4.6 мы оценивали риск того, что конкретное требование к промокоду содержит дефект. Сейчас разберём эту идею шире и добавим второй, совсем другой тип риска.
Чему научишься за этот урок:
— объяснять разницу между риском продукта и риском проекта;
— применять двухфакторную модель оценки риска (вероятность × воздействие);
— по описанию ситуации определять уровень риска и решать, что проверять в первую очередь.
Риск продукта: то, что мы уже видели
Риск продукта (product risk) — это риск того, что КОНКРЕТНАЯ функциональность содержит дефект, и то, насколько дорого он обойдётся, если проявится в проде. Важно не путать этот прогноз с severity (глава 6.6): там мы оцениваем серьёзность дефекта, который УЖЕ нашли, — постфактум; здесь же прогнозируем риск ДО начала тестирования, чтобы решить, что проверять внимательнее и в первую очередь. В главе 4.6 такой риск уже встречался: ошибка в лимите скидки промокода бьёт по деньгам компании напрямую, значит риск выше, чем у опечатки в подсказке к полю. Возьмём два новых примера. Функциональность «Оплата курса»: если платёж спишется дважды из-за повторного нажатия кнопки — это риск продукта высокий, ошибка касается прямых денег ученика и репутации платформы. Функциональность «Отзывы о курсах»: если отзыв с оскорблением опубликуется без модерации — на первый взгляд кажется, что риск продукта тоже высокий, ведь удар по репутации не менее неприятен, чем финансовые потери. Но давайте не гадать интуитивно, а посчитать по модели ниже — увидите, что вывод не так однозначен. В обоих случаях риск — это свойство самого продукта: что именно может сломаться и как дорого это обойдётся.
Риск проекта: совсем другое
Риск проекта (project risk) — это риск того, что САМ ПРОЦЕСС тестирования не удастся провести так, как задумано. Это не про качество продукта, а про способность команды вовремя и качественно протестировать. Типичные примеры: сборка приходит от разработчиков с опозданием, и на тестирование остаётся меньше времени, чем закладывали; тестовое окружение недоступно (стенд упал, база данных не разворачивается); требования меняются в последний момент, и часть уже написанных тест-кейсов устаревает; единственный тестировщик на проекте уходит на больничный. Ни один из этих примеров не говорит о том, что промокод или форма оплаты содержат дефект — они про то, что тестирование как таковое может не состояться или пройти в урезанном виде.
Risk-based testing: приоритет по уровню риска
Risk-based testing — подход, при котором порядок и глубина тестирования определяются УРОВНЕМ РИСКА продукта, а не порядком в списке задач или личным удобством тестировщика. Сначала и тщательнее всего проверяется то, что несёт наибольший риск продукта. Если времени не хватает на всё — а оно почти никогда не хватает на всё, — в первую очередь режут проверки с самым низким риском, а не случайные или те, что просто попались под руку последними.
Двухфакторная модель: вероятность × воздействие
Чтобы риск-ориентированный подход не превращался в интуицию «мне кажется, это важнее», риск оценивают по двум факторам одновременно. Вероятность — насколько вероятен дефект именно здесь: новая или недавно переписанная функциональность рискованнее давно стабильного кода; часто меняющийся код рискованнее того, который месяцами никто не трогал; сложная логика (много условий и веток) рискованнее простой. Воздействие — насколько дорого обойдётся дефект, если он всё же проявится: деньги (прямые потери или упущенная выручка), репутация (публичный скандал, жалобы), безопасность данных учеников. Высокий риск продукта — это сочетание ВЫСОКОЙ вероятности и ВЫСОКОГО воздействия одновременно; если хотя бы один фактор низкий, риск обычно ниже, чем кажется на первый взгляд.
ВОЗДЕЙСТВИЕ
низкое высокое
+-------------+-------------+
высокая | средний | ВЫСОКИЙ |
ВЕРО- | риск | риск |
ЯТНОСТЬ | (проверить | (проверить |
| во вторую | в первую |
| очередь) | очередь) |
+-------------+-------------+
низкая | НИЗКИЙ | средний |
| риск | риск |
| (сократить | (проверить |
| в первую | во вторую |
| очередь) | очередь) |
+-------------+-------------+
Пример: двойное списание при оплате курса -> высокая вероятность
(сложная логика повторных нажатий) x высокое воздействие (деньги) = ВЫСОКИЙ риск
Пример: опечатка в подсказке к полю промокода -> низкая вероятность
(простой статичный текст) x низкое воздействие (неудобство) = НИЗКИЙ риск
Пример на нашей платформе
Перед релизом одновременно готовятся два раздела — «Оплата курса» и «Отзывы о курсах», а времени у команды осталось мало. Применим двухфакторную модель к каждому. «Оплата курса»: вероятность высокая (логика повторных нажатий и обработки отказа банка сложная и недавно переписана), воздействие высокое (прямые деньги ученика) — риск продукта ВЫСОКИЙ. «Отзывы о курсах»: вероятность средняя (форма несложная, но принимает произвольный пользовательский текст), воздействие среднее-высокое (репутационный риск при публикации неприемлемого содержания, но не прямые деньги) — риск продукта СРЕДНИЙ. Risk-based testing подсказывает решение: в первую очередь и тщательнее всего проверяем «Оплату курса» — включая повторные нажатия, обработку отказа и граничные случаи с суммой; «Отзывы о курсах» проверяем базово (основной сценарий отправки и отображения), а часть менее вероятных негативных сценариев (например, экзотические спецсимволы в тексте отзыва) сознательно откладываем, если времени не хватит на всё. Это не значит, что раздел «Отзывы» не важен — значит, что при нехватке времени риск продукта у «Оплаты» выше по обоим факторам сразу.
Проверочный вопрос, чтобы не путать два риска: «если это случится, сломается продукт — или сорвётся сам процесс проверки продукта?» Двойное списание платежа — сломается продукт (риск продукта). Заболевший единственный тестировщик — сорвётся процесс проверки (риск проекта), даже если сам продукт при этом идеален.
Итог:
— риск продукта — риск того, что конкретная функциональность содержит дефект, и цена этого дефекта (уже встречался в главе 4.6);
— риск проекта — риск того, что сам процесс тестирования сорвётся: задержка сборки, недоступное окружение, смена требований, отсутствие тестировщика;
— risk-based testing расставляет порядок и глубину проверок по уровню риска ПРОДУКТА, а не по удобству или порядку в списке;
— риск оценивают по двум факторам одновременно — вероятность дефекта и воздействие, если он проявится; высокий риск — это высокие оба фактора сразу.
Контрольный вопрос. Что такое риск продукта (product risk)?
Подсказка: Речь про сам продукт и его функциональность, а не про процесс проверки этого продукта.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Единственный тестировщик на проекте уходит на больничный за неделю до релиза. Какой это тип риска?
Подсказка: Ситуация не про дефект в самом продукте, а про способность команды провести тестирование вовремя.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. По какому принципу risk-based testing определяет, что проверять в первую очередь?
Подсказка: Название подхода содержит слово «risk» не просто так.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Из каких двух факторов складывается оценка риска продукта в двухфакторной модели из этого урока?
Подсказка: Оба фактора названы в заголовке раздела урока про эту модель.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из перечисленных ситуаций в уроке относятся именно к риску ПРОЕКТА, а не продукта (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Один из четырёх вариантов — про дефект в самом продукте, остальные три — про срыв процесса тестирования.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. В какой главе курса (назови номер) уже встречалось понятие риска — там оценивали, что ошибка в лимите скидки промокода дороже, чем опечатка в подсказке? Ответь одной цифрой.
Подсказка: Это глава про тест-анализ, разложение требования на условия тестирования.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Требования к разделу «Оплата курса» меняются в последний момент перед релизом, и часть уже написанных тест-кейсов устаревает. Как двумя словами называется тип риска, к которому относится эта ситуация? Ответь двумя словами.
Подсказка: Дело не в том, что сама функциональность оплаты содержит дефект, а в том, что процесс подготовки к тестированию срывается.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Сравниваем риск продукта у двух функциональностей нашего курса. Функциональность А («Отзывы о курсах»): форма несложная, но воздействие в случае дефекта — среднее-высокое (репутация). Функциональность Б («Оплата курса»): логика сложная и недавно переписана (высокая вероятность), воздействие высокое (деньги). По двухфакторной модели (вероятность × воздействие), у какой из них — А или Б — риск продукта выше? Ответь одной буквой.
Подсказка: Сравни оба фактора у каждой функциональности — вероятность и воздействие — и подумай, у кого оба выше одновременно.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях разницу между риском продукта и риском проекта, приведя по одному примеру каждого (можно взять примеры из этого урока или придумать свои, но по духу похожие).
Критерий приёмки: риск продукта описан как риск дефекта в самой функциональности и его цена (пример: ошибка в оплате или в отзывах, ведущая к финансовым или репутационным потерям); риск проекта описан как риск срыва самого процесса тестирования (пример: недоступное окружение, опоздавшая сборка, заболевший тестировщик); явно указано, что это два РАЗНЫХ по природе риска, а не два примера одного и того же.
Подсказка: Вспомни проверочный вопрос из подсказки урока: «сломается продукт — или сорвётся процесс проверки продукта?»
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. У команды осталось мало времени перед одновременным релизом разделов «Оплата курса» и «Отзывы о курсах». Реши, что проверять в первую очередь и почему, явно применив двухфакторную модель (вероятность × воздействие) к обеим функциональностям, и укажи, какими проверками стоит пожертвовать в первую очередь при нехватке времени.
Критерий приёмки: для каждой из двух функциональностей отдельно оценены оба фактора — вероятность и воздействие (например, «Оплата»: высокая вероятность из-за сложной/новой логики, высокое воздействие — деньги; «Отзывы»: средняя вероятность, среднее-высокое воздействие — репутация); сделан явный вывод, что «Оплата курса» тестируется в первую очередь и тщательнее, так как риск продукта выше по обоим факторам; названо, что можно сократить в первую очередь — менее вероятные или менее критичные проверки у «Отзывов», а не случайный набор проверок у любого из разделов.
Подсказка: Оцени вероятность и воздействие отдельно для каждой функциональности, прежде чем сравнивать их между собой.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Что дальше
Мы разобрали два разных типа риска и то, как риск-ориентированный подход помогает расставить приоритеты, когда времени не хватает на всё. Но чтобы решение опиралось не на ощущение «кажется, идём по плану», а на факты, тестированием нужно управлять по ходу дела — отслеживать прогресс и вовремя замечать отклонения. Именно об этом — мониторинг, контроль и метрики тестирования — следующий урок.
