Тестирование на основе рисков
Updated Jul 2026
У вас никогда не хватит времени протестировать всё. Планирование тестирования — это дисциплина принятия решений о том, что тестировать в первую очередь, насколько глубоко и когда остановиться. Тестирование на основе рисков предоставляет структурированный фреймворк для принятия этих решений, гарантируя, что ваши ограниченные усилия по тестированию сконцентрированы там, где они предотвратят наибольший ущерб.
Уравнение риска
Риск = Вероятность отказа x Влияние отказа.
Каждая функциональная область вашего приложения несёт различный уровень риска. Модуль обработки платежей, работающий с реальными деньгами и недавно модифицированный, несёт гораздо больший риск, чем статическая страница FAQ, не менявшаяся шесть месяцев.
Матрица оценки рисков
| Функциональная область | Вероятность дефектов | Бизнес-влияние | Уровень риска | Глубина тестирования |
|---|---|---|---|---|
| Обработка платежей | Средняя | Критическое | Высокий | Полная регрессия, крайние случаи, безопасность |
| Редактирование профиля | Низкая | Низкое | Низкий | Основной сценарий, один негативный кейс |
| Новая сторонняя интеграция | Высокая | Высокое | Критический | Исчерпывающе: позитивные, негативные, таймауты, ошибки авторизации |
| Статическая страница FAQ | Очень низкая | Очень низкое | Минимальный | Только дымовой тест |
| Функция поиска | Средняя | Среднее | Средний | Основные сценарии, точечная проверка производительности |
| Управление пользователями (admin) | Низкая | Высокое | Высокий | CRUD-операции, границы прав доступа, журналирование аудита |
Факторы, повышающие вероятность
- Недавно изменённый код: новый или изменённый код содержит больше ошибок, чем стабильный
- Сложная бизнес-логика: многоусловные правила имеют больше крайних случаев
- Сторонние зависимости: внешние API, платёжные шлюзы, провайдеры аутентификации
- Первая реализация: команда никогда не строила функцию такого типа
- Технический долг: области с известными проблемами качества кода
- Конкурентность: функции, обрабатывающие параллельные запросы или общее состояние
Факторы, повышающие влияние
- Потоки, генерирующие доход: оформление заказа, подписка, оплата
- Данные пользователей: регистрация, управление профилем, экспорт данных
- Границы безопасности: аутентификация, авторизация, контроль доступа к данным
- Функции соответствия: удаление по GDPR, журналирование аудита, хранение данных
- Публичные функции: всё, видимое неаутентифицированным пользователям
- Нижестоящие зависимости: функции, потребляемые другими сервисами или партнёрами
Применение тестирования на основе рисков
Шаг 1: Перечислите функциональные области
Совместно с владельцем продукта и разработчиками составьте список всех функциональных областей, выпускаемых или модифицируемых.
Шаг 2: Оцените риски
Для каждой области оцените вероятность (Очень низкая / Низкая / Средняя / Высокая) и влияние (Очень низкое / Низкое / Среднее / Высокое / Критическое). Используйте матрицу выше для определения общего уровня риска.
Шаг 3: Назначьте глубину тестирования
| Уровень риска | Глубина тестирования |
|---|---|
| Критический | Исчерпывающее: все позитивные кейсы, все негативные кейсы, крайние случаи, безопасность, производительность, кросс-браузерное |
| Высокий | Тщательное: все позитивные кейсы, ключевые негативные кейсы, граничные значения, одна кросс-браузерная проверка |
| Средний | Стандартное: основной сценарий, ключевые негативные кейсы, одна проверка границ |
| Низкий | Лёгкое: только основной сценарий |
| Минимальный | Дымовое: проверить, что функция загружается и базовая функциональность работает |
Шаг 4: Приоритизируйте выполнение
Тестируйте критические и высокорисковые области первыми. Если время закончится, вы уже покрыли самые важные сценарии.
Техники оценки трудозатрат
Точная оценка трудозатрат на тестирование — это навык, который улучшается с опытом. Три техники:
Оценка на основе декомпозиции работ
Перечислите все необходимые типы тестирования, оцените каждый:
| Тип тестирования | Ожидаемое время |
|---|---|
| Функциональные позитивные кейсы (12 кейсов) | 3 часа |
| Функциональные негативные кейсы (8 кейсов) | 2 часа |
| Крайние случаи и граничные значения | 2 часа |
| Кросс-браузерное тестирование (3 браузера) | 1.5 часа |
| Исследовательская сессия | 1 час |
| Верификация багов и ретестирование | 1 час |
| Итого | 10.5 часов |
Историческая аналогия
«Последняя функция аналогичной сложности заняла 3 дня тестирования.» Лучше всего работает, когда ваша команда отслеживает время тестирования по функциям.
Ведите журнал:
- Функция X (средняя сложность, API + UI): 2.5 дня
- Функция Y (высокая сложность, сторонняя интеграция): 5 дней
- Функция Z (низкая сложность, только UI): 0.5 дня
Трёхточечная оценка
(Оптимистичная + 4 x Наиболее вероятная + Пессимистичная) / 6
Пример:
- Оптимистичная: 2 дня (всё идёт гладко, без блокеров)
- Наиболее вероятная: 3 дня (типичное количество проблем и ретестирования)
- Пессимистичная: 6 дней (обнаружены серьёзные баги, проблемы с окружением, расширение объёма)
Оценка = (2 + 4(3) + 6) / 6 = 3.3 дня
Это лучше учитывает неопределённость, чем одноточечная оценка.
Критерии входа и выхода
Критерии входа
Критерии входа определяют условия, которые должны быть выполнены до начала тестирования. Начинать тестирование до выполнения критериев входа приводит к напрасной трате усилий на нестабильной сборке.
Типичные критерии входа:
- Сборка успешно развёрнута в тестовом окружении
- Дымовые тесты проходят (критические пути работают)
- Тестовые данные загружены и проверены
- Документ требований/критериев приёмки доступен и рассмотрен
- Тестовое окружение доступно и стабильно
- Известные проблемы окружения задокументированы (чтобы тестировщики не сообщали о них как о багах)
Критерии выхода
Критерии выхода определяют, когда тестирование «достаточно завершено» для перехода к релизу.
Типичные критерии выхода:
- Все баги критической и высокой серьёзности решены и верифицированы
- 95% запланированных тест-кейсов выполнены (оставшиеся 5% обоснованы)
- Нет открытых блокеров
- Регрессионный тест-сьют проходит (зелёный)
- Исследовательские сессии завершены для высокорисковых областей
- Показатели производительности соответствуют требованиям (время отклика в рамках SLA)
Когда критерии выхода не выполнены
Иногда дедлайн релиза наступает до выполнения критериев выхода. Задокументируйте:
- Какие критерии не выполнены
- Связанные риски
- Вашу рекомендацию (выпускать / не выпускать / выпускать с мерами по смягчению)
Это решение о принятии рисков для руководства, а не для QA. QA предоставляет данные; руководство принимает риски.
Тест-планы
Тест-план — это документ, фиксирующий вашу стратегию тестирования на основе рисков для конкретного релиза или функции.
Облегчённый шаблон тест-плана
Feature: Checkout Flow Redesign
Release: v2.5.0
QA Lead: Jane D.
Date: 2024-03-15
SCOPE:
- In scope: New checkout UI, payment integration, order confirmation
- Out of scope: User registration, product catalog, admin panel
RISK ASSESSMENT:
- Payment processing: CRITICAL — new integration with Stripe v3
- Address validation: HIGH — new autocomplete API
- Order confirmation: MEDIUM — mostly UI changes
- Email notifications: LOW — existing system, no changes
TEST APPROACH:
- Functional: 25 test cases covering all risk levels
- Exploratory: 2 sessions focused on payment edge cases
- Cross-browser: Chrome, Firefox, Safari (latest)
- Performance: Load test checkout with 100 concurrent users
ENTRY CRITERIA:
- Build deployed to staging
- Stripe sandbox configured
- Test accounts created (3 roles: admin, customer, guest)
EXIT CRITERIA:
- All critical/high bugs resolved
- 90%+ test case pass rate
- Payment flow verified for all card types
SCHEDULE:
- Day 1-2: Functional testing
- Day 3: Exploratory sessions
- Day 4: Cross-browser and regression
- Day 5: Bug verification and sign-off
Практическое упражнение
Вы — QA-лид для релиза, который включает:
- Новый способ оплаты (интеграция Apple Pay)
- Переработанная страница настроек пользователя
- Исправление бага с индексацией поиска
- Обновлённая страница «Условия использования»
Создайте матрицу оценки рисков для этих четырёх элементов, назначьте глубину тестирования, оцените время тестирования с использованием трёхточечной оценки и определите критерии входа/выхода.
Ключевые выводы
- Риск = Вероятность x Влияние. Тестируйте высокорисковые области первыми и наиболее глубоко.
- Используйте оценку рисков для распределения ограниченного времени тестирования туда, где это важнее всего
- Три техники оценки: декомпозиция работ, историческая аналогия, трёхточечная
- Критерии входа предотвращают напрасное тестирование на нестабильных сборках
- Критерии выхода определяют «достаточно завершено» — и что делать, когда они не выполнены
- Документируйте вашу стратегию на основе рисков в облегчённом тест-плане