Регрессионное тестирование
Релиз-кандидат готов поздно вечером. Большинство функций не менялись, но три сервиса переработаны, а исправление цен затронуло общую логику. Кто-то предлагает «прогнать регресс», однако команда не согласовала, что защищать до окончания окна.
Регрессионное тестирование полезно, когда фиксирует решение о риске, а не обещает повторить каждый старый сценарий. Начните с изменения, пройдите по достижимому поведению и сделайте пропуски видимыми.
Регрессионное тестирование: начните с изменения
Составьте список изменений кода, конфигурации, зависимостей, схемы и данных. Для каждого спросите, какие сервисы, записи и пользовательские пути он может затронуть напрямую. Затем посмотрите на одну связь дальше. Изменение цены может дойти до скидки, счёта, возврата и аналитики, даже если их экраны не трогали.
Держите карту изменений рядом с решением о проверках. Она объясняет, почему сценарий вошёл в выпускной набор.
Определите объём по риску
Сначала берите важные для пользователя пути, частое поведение, хрупкие интеграции и области с недавними дефектами. Разделите быстрый выпускной набор и глубокое покрытие, которое можно выполнить позже. У каждой проверки должна быть причина: влияние, вероятность или цена пропуска.
Если времени мало, сокращайте ширину осознанно. Пусть случайно самый короткий список не станет объёмом работ.
Используйте уровни вместо одного огромного списка
- Дымовой слой: сборка вообще выполняет основную функцию?
- Область изменения: новое или исправленное поведение работает?
- Соседний риск: связанное поведение осталось стабильным?
- Ключевые пути: пользователь завершает важные задачи?
- Расширенное покрытие: какие автоматические или ручные проверки оправданы остаточным риском?
Такой подход делает остановку объяснимой. Релиз может пройти быстрый барьер, пока глубокие проверки остаются запланированными и названными.
Фиксируйте, что не проверялось
В результате регрессии укажите объём, билд, окружение, результаты проверок и оставшийся риск. Слово «пройдено» вводит в заблуждение, если интеграция была недоступна или важный путь исключили из-за данных. Назовите пропуск, чтобы решение о релизе принадлежало команде.
Улучшайте набор после релиза
Сравните прогноз рисков с фактическими сбоями и полезными сигналами из эксплуатации. Уберите проверки, которые не влияют на решения, исправьте нестабильную автоматизацию и добавьте покрытие там, где модель риска ошиблась. Следующий прогон должен стать надёжнее, а не просто длиннее.
Чек-лист оправдан, когда помогает решить, что защитить, что отложить и чему научил сам релиз.
Закрепите материал на одном примере
Возьмите условное или недавнее изменение и проведите от него три первые связанные области поведения. Выберите одну быструю проверку для барьера и одну глубокую. Для каждой запишите причину.
Добавьте окружение и результаты проверок, которые понадобятся, затем назовите один важный пропуск. Спросите, какое решение команда сможет принять по этому объёму, а какое пока не сможет.
Завершите вопросом для разбора после релиза: какой прогноз риска нужно сопоставить с фактическим результатом?
На выходе: объём регрессии с одной проверкой для допуска, одной глубокой проверкой, доказательством и явным исключением.
Вопросы перед следующим шагом
- Что изменилось и какого поведения это может коснуться?
- Какая проверка защищает выпускной барьер?
- Что сознательно отложено?
- Что нужно сравнить после релиза?
Тематические вопросы и объяснения в ISTQB Quiz помогают тренировать риск, покрытие и регрессионное тестирование.
Практиковаться в ISTQB Quiz →