Что такое регрессионное тестирование?
Регрессионное тестирование проверяет, что ранее работающая функциональность не сломана последними изменениями. При каждом изменении кода — новых функций, исправлений, обновлений конфигурации — есть риск непреднамеренных побочных эффектов. Регрессионное тестирование их обнаруживает.
Термин «регрессия» означает откат назад. Программная регрессия — когда функция, работавшая в версии 1.0, перестаёт работать в 1.1.
Пример: Корзина покупок. Версия 1.0 корректно обрабатывает товары, количества и суммы. В 1.1 добавляют промокоды. Теперь итого считается неправильно — скидка применяется дважды. Функция промокодов работает, но оригинальный расчёт регрессировал. Регрессионное тестирование поймало бы это.
Почему регрессия необходима
Изменения имеют волновые эффекты
Современное ПО взаимосвязано. Изменение в одном модуле может повлиять на кажущиеся не связанными модули.
Стоимость регрессий в продакшене
Регрессия, пойманная при тестировании, стоит часов. Та же в продакшене — дни или недели плюс доверие клиентов и поддержка.
Наборы тестов растут со временем
Каждая новая функция добавляет тест-кейсы. Каждый bug fix — проверку регрессии. Без структурированного подхода качество деградирует.
Стратегии выбора регрессионных тестов
Перезапуск всех (Retest All)
Запуск всего набора. Максимум для крупных релизов. Медленно, но полно.
Выбор по приоритету
P1 = критический, P2 = высокий, P3 = средний, P4 = низкий. Запуск по убыванию приоритета.
Выбор на основе рисков
Тесты выбираются по вероятности сбоя и его влиянию.
Факторы риска: Близость к изменению, история багов, критичность для бизнеса, сложность, давность последнего тестирования.
Выбор на основе изменений
Запуск только тестов, затрагивающих изменённый код. Эффективно, но требует инструментов покрытия.
Автоматизация регрессии
Ручная регрессия не масштабируется. То, что сегодня занимает 2 часа, через год займёт 20.
Что автоматизировать первым
- Smoke-тесты — проверки критического пути
- Высокоприоритетную регрессию — функции дохода и чувствительных данных
- Часто выполняемые тесты — сценарии каждого релиза
- Стабильные функции — области, которые редко меняются
- Data-driven тесты — множество комбинаций входных данных
Что оставить ручным
- Исследовательское тестирование
- Тестирование удобства использования
- Часто меняющиеся функции
- Одноразовые тесты
Поддержка регрессионного набора
Добавлять тесты за каждый bug fix. Каждый исправленный баг получает регрессионный тест.
Удалять устаревшие тесты. Удалённые или перепроектированные функции — удалить соответствующие тесты.
Исправлять нестабильные тесты немедленно. Случайно падающие тесты учат команду игнорировать сбои.
Регулярно ревьюить и рефакторить. Как продакшен-код, тестовый код нуждается в рефакторинге.
Упражнение: Приоритизируйте регрессионный набор на основе рисков
Вы QA Lead банковского приложения. Спринт включал:
- Изменение 1: Обновление алгоритма расчёта процентов
- Изменение 2: Новая тема «Тёмный режим»
- Изменение 3: Fix бага в email сброса пароля
Ваш набор: 200 тестов. Время на 80 (40%). Выберите области и обоснуйте.
| Область | Тестов | Последняя проверка | Частота багов |
|---|---|---|---|
| Баланс счёта | 25 | 2 недели назад | Низкая |
| Переводы | 30 | 1 неделя | Средняя |
| Расчёт процентов | 20 | 3 месяца | Высокая |
| Заявка на кредит | 15 | 1 месяц | Низкая |
| Оплата счетов | 20 | 2 недели | Средняя |
| Аутентификация | 25 | 1 неделя | Низкая |
| Сброс пароля | 10 | 3 месяца | Средняя |
| UI/Доступность | 15 | 1 месяц | Низкая |
| Отчёты/Выписки | 20 | 2 месяца | Средняя |
| Мобильное приложение | 20 | 1 месяц | Высокая |
Подсказка
Сопоставьте каждое изменение с областью риска. Учтите: какие тесты напрямую связаны с изменениями? Где высокая частота багов? Что давно не тестировалось? Что наиболее критично?Решение
Обязательно тестировать (напрямую затронуто):
- Расчёт процентов: 20/20 (100%) — Изменение 1 напрямую. Высокая частота багов. 3 месяца без проверки. Финансово критично.
- Сброс пароля: 10/10 (100%) — Изменение 3 напрямую. Проверить fix и побочные эффекты.
- UI/Доступность: 10/15 (67%) — Изменение 2 добавило Тёмный режим.
Высокий риск (косвенно затронуто):
- Переводы: 15/30 (50%) — Финансовая транзакция. Изменения расчёта могут повлиять.
- Баланс счёта: 15/25 (60%) — Изменения процентов влияют на расчёт баланса.
Средний риск:
- Аутентификация: 5/25 (20%) — Сброс пароля — часть потока аутентификации.
- Отчёты: 5/20 (25%) — Изменения процентов влияют на расчёты выписок.
Итого: 80 тестов
Не выбрано: Заявка на кредит (0), Оплата счетов (0), Мобильное (0) — низкий риск для этого спринта.
Регрессия в CI/CD
5 мин] SMOKE --> UNIT[Unit
3 мин] UNIT --> INT[Интеграционные
15 мин] INT --> FAST[Быстрая регрессия
P1, 30 мин] FAST --> DEPLOY[Deploy в Staging] DEPLOY --> FULL[Полная регрессия
Ночная, 4 часа]
Профессиональные советы
Совет 1: Регрессионный набор — ваша страховка. Каждый тест гарантирует работоспособность чего-то. Пропуск регрессии — как отмена страховки.
Совет 2: Измеряйте эффективность. Сколько багов набор ловит за релиз? Если ноль за несколько релизов — нужно обновление.
Совет 3: Используйте анализ влияния. Современные инструменты анализируют изменения и автоматически определяют, какие тесты запускать.
Ключевые выводы
- Регрессия проверяет работоспособность существующей функциональности после изменений
- Четыре стратегии: полный перезапуск, приоритет, риск, изменения
- Выбор на основе рисков — лучший баланс покрытия и эффективности
- Автоматизация обязательна — ручная регрессия не масштабируется
- Поддержка набора: добавлять тесты за fix, удалять устаревшие, чинить нестабильные
- Интеграция в CI/CD для непрерывного обеспечения качества