Зачем Тестирование на Основе Рисков?
Ни один проект не имеет неограниченных ресурсов. Невозможно тестировать всё одинаково. Тестирование на основе рисков отвечает на ключевой вопрос: На чём сосредоточить усилия?
Ответ: на областях с наивысшим риском — где дефекты наиболее вероятны И где их последствия наиболее серьёзны.
Понимание Риска
Риск = Вероятность × Влияние
- Вероятность: Насколько вероятно существование дефекта в этой области?
- Влияние: Если дефект есть, насколько серьёзны последствия?
Факторы Вероятности
| Фактор | Повышает Вероятность |
|---|---|
| Сложность кода | Сложные алгоритмы, много условий |
| Новая технология | Первый опыт с фреймворком или API |
| Опыт разработчика | Джуниор или новый член команды |
| Частота изменений | Часто модифицируемый код |
| Точки интеграции | Несколько взаимодействующих систем |
| Жёсткие сроки | Код, написанный под давлением |
| История | Область с множеством прошлых дефектов |
Факторы Влияния
| Фактор | Повышает Влияние |
|---|---|
| Финансовые транзакции | Потеря денег, неправильные списания |
| Безопасность/приватность | Утечка данных, несанкционированный доступ |
| Критичность безопасности | Физический вред пользователям |
| Основной пользовательский поток | Вход, оформление заказа, ключевые функции |
| Регуляторные требования | Нарушения compliance, штрафы |
| Репутация бизнеса | Публичные сбои |
| Целостность данных | Необратимая потеря или повреждение данных |
Продуктовые vs Проектные Риски
Продуктовые Риски
Потенциальные проблемы качества ПО:
| Риск | Вероятность | Влияние | Уровень |
|---|---|---|---|
| Ошибка обработки платежей | Средняя | Критическое | Высокий |
| Поиск возвращает неверные результаты | Низкая | Высокое | Средний |
| CSS сломан на мобильных | Средняя | Среднее | Средний |
| Опечатка на странице помощи | Низкая | Низкое | Низкий |
Проектные Риски
Угрожают процессу тестирования:
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Тестовое окружение недоступно | Высокая | Высокое | Резервное окружение, Docker |
| Требования меняются в середине спринта | Средняя | Высокое | Процесс контроля изменений |
| QA-инженер заболел | Низкая | Высокое | Cross-training |
| API третьей стороны недоступен | Средняя | Среднее | Mock-сервисы |
Матрица Рисков
ВЫСОКОЕ Влияние
Критический] HL[ВЫСОКАЯ Вероятность
НИЗКОЕ Влияние
Средний] LH[НИЗКАЯ Вероятность
ВЫСОКОЕ Влияние
Высокий] LL[НИЗКАЯ Вероятность
НИЗКОЕ Влияние
Низкий] end style HH fill:#F44336,color:#fff style HL fill:#FFC107,color:#000 style LH fill:#FF9800,color:#fff style LL fill:#4CAF50,color:#fff
Как Использовать Матрицу
| Уровень | Подход к Тестированию |
|---|---|
| Критический | Все техники: функциональное, негативное, граничное, безопасности, производительности, исследовательское |
| Высокий | Полное покрытие: функциональное + негативное + граничное |
| Средний | Стандартное: функциональные кейсы, ключевые негативные |
| Низкий | Минимальное: smoke-тесты, базовая валидация |
Процесс Тестирования на Основе Рисков
Рисков] --> RA[2. Анализ
Рисков] RA --> RP[3. Приоритизация
на Основе Рисков] RP --> TE[4. Выполнение
Тестов] TE --> RM[5. Мониторинг
Рисков] RM --> RI style RI fill:#4CAF50,color:#fff style RA fill:#2196F3,color:#fff style RP fill:#FF9800,color:#fff style TE fill:#9C27B0,color:#fff style RM fill:#F44336,color:#fff
Шаг 1: Идентификация
Участники: QA, разработчики, product owners, архитекторы, эксплуатация.
Техники: Мозговой штурм, анализ исторических данных о дефектах, анализ требований на сложность, ревью архитектуры.
Шаг 2: Анализ
Для каждого риска: Вероятность (1-5) × Влияние (1-5) = Балл Риска.
Шаг 3: Приоритизация
| Приоритет | % Усилий | Глубина |
|---|---|---|
| Критический (15-25) | 40% | Все техники |
| Высокий (10-14) | 30% | Функциональное + негативное + граничное |
| Средний (5-9) | 20% | Функциональное + ключевые негативные |
| Низкий (1-4) | 10% | Smoke-тесты |
Шаг 4: Выполнение
Выполнять тесты в порядке приоритета. Если время закончится, наиболее рисковые области уже протестированы.
Шаг 5: Мониторинг
Риски меняются во время тестирования. Обновляйте реестр непрерывно.
Упражнение: Создать Реестр Рисков и Приоритизировать Тест-Кейсы
Вы — QA-лид онлайн-портала здравоохранения, где пациенты могут:
- Регистрироваться и управлять профилем (включая историю болезни)
- Записываться на приём к врачам
- Просматривать результаты анализов и медицинские записи
- Общаться с врачами через защищённую переписку
- Оплачивать консультации онлайн
- Получать уведомления о рецептах
Регуляторный контекст: Система должна соответствовать HIPAA для конфиденциальности данных пациентов.
Ваша задача:
- Создать реестр рисков с минимум 10 рисками
- Оценить каждый (Вероятность 1-5, Влияние 1-5)
- Категоризировать в матрице рисков
- Назвать 5 тест-кейсов для первоочередного выполнения
- Объяснить корректировку при сокращении сроков на 30%
Подсказка
Нарушения HIPAA влекут штрафы $100-$50,000 за нарушение. Медицинские данные — самая чувствительная категория. Ошибки записи могут привести к пропуску критической помощи. Уведомления о рецептах должны быть своевременными и точными.
Пример решения
Реестр Рисков
| ID | Риск | Тип | В | И | Балл | Приоритет |
|---|---|---|---|---|---|---|
| R1 | Медицинские записи видны неавторизованным пользователям | Продуктовый | 2 | 5 | 10 | Критический |
| R2 | Уведомление о рецепте отправлено не тому пациенту | Продуктовый | 2 | 5 | 10 | Критический |
| R3 | Защищённая переписка не зашифрована | Продуктовый | 3 | 5 | 15 | Критический |
| R4 | Двойное списание с пациента | Продуктовый | 3 | 4 | 12 | Высокий |
| R5 | Запись допускает перекрывающиеся слоты | Продуктовый | 4 | 3 | 12 | Высокий |
| R6 | Результаты анализов показывают неверные значения | Продуктовый | 2 | 5 | 10 | Критический |
| R7 | Слишком долгий таймаут сессии (HIPAA требует короткий) | Продуктовый | 3 | 4 | 12 | Высокий |
| R8 | Тестовое окружение без маскирования данных | Проектный | 4 | 4 | 16 | Критический |
| R9 | Интеграция с EHR больницы не работает | Проектный | 3 | 4 | 12 | Высокий |
| R10 | QA-команда не знакома с требованиями HIPAA | Проектный | 3 | 3 | 9 | Средний |
Топ-5 Тест-кейсов
- Контроль доступа: Пациент A не может видеть записи Пациента B (R1 — критично для HIPAA)
- Шифрование переписки: Сообщения зашифрованы при передаче и хранении (R3)
- Точность уведомлений о рецептах: Уведомление соответствует правильному пациенту и рецепту (R2)
- Точность результатов анализов: Лабораторные значения отображаются корректно с единицами (R6)
- Таймаут сессии HIPAA: Сессия истекает после требуемого периода бездействия (R7)
Корректировка при -30% Времени
Сохранить полные усилия (Критические): R1, R2, R3, R6 — не подлежат обсуждению для HIPAA.
Сократить усилия (Высокие): R4, R5, R7, R9 — только happy path и ключевые негативные сценарии.
Отложить (Средние/Низкие): R10 — решить через документацию. Косметическое тестирование — отложить полностью.
Коммуникация: «При сокращении сроков на 30% мы сохраняем полное покрытие для критичных областей HIPAA (контроль доступа, шифрование, точность данных пациентов). Мы сокращаем покрытие для платежей и расписания, принимая повышенный риск. Рекомендуем пост-релизный спринт для отложенных областей.»
Тестирование на Основе Рисков в Agile
- Sprint Planning: Определить риски для user stories спринта. Stories с высоким риском тестируются первыми.
- Daily Standup: Сообщать об обнаруженных рисках. Если в «безопасной» области найдены баги — эскалировать.
- Sprint Review: Обновить реестр рисков по итогам спринта.
- Retrospective: Обсудить точность оценки рисков. Улучшить для следующего спринта.
Профессиональные Советы
Привлекайте всю команду к идентификации рисков. Разработчики знают, где код хрупок. Product Owners знают, что критично для бизнеса. Ops знают, что ломалось раньше.
Обновляйте реестр непрерывно. Риск не статичен. Область высокого риска может стать низкорисковой после тщательного тестирования. Новые риски появляются при изменениях дизайна.
Используйте данные о дефектах для калибровки. Если область стабильно имеет больше дефектов, увеличьте балл вероятности для следующего релиза.
Документируйте решения. Когда сокращаете тестирование низкорисковой области, зафиксируйте это. Если дефект сбежит, вы сможете объяснить логику, а не выглядеть небрежными.
Это не о том, чтобы тестировать меньше. Это о том, чтобы тестировать умнее. Тот же объём усилий, но направленный туда, где это создаёт наибольшую ценность.