Каждое изменение в коде - как новое украшение на новогодней ёлке: может сделать всё красивее, а может уронить всю конструкцию. Именно поэтому после каждого обновления важно не только проверить новые фичи, но и убедиться, что старый функционал всё ещё работает. Это и есть регрессионное тестирование.

Что такое регрессионное тестирование?

Регрессионное тестирование - это процесс повторной проверки уже протестированных участков системы, чтобы убедиться, что после изменений ничего не сломалось.

Пример: ты отремонтировал одну розетку в доме, но после этого перестали работать свет и Wi-Fi. Это и есть регрессия.

Зачем оно нужно?

Изменения в коде могут быть коварными. Даже небольшая правка может повлиять на другие, казалось бы, не связанные части системы. Регрессия помогает:

• Обнаружить побочные эффекты после внедрения новой функциональности
• Убедиться, что баги действительно исправлены
• Защитить старый функционал от случайной поломки

Регрессия - это предрелизная страховка: «мы ничего не сломали?»

Когда проводить регрессионное тестирование?

• После фикса бага
• После добавления новой фичи
• После рефакторинга
• Перед каждым релизом
• После слияния крупных pull-request’ов

Даже если всё протестировано вручную или через юнит-тесты - регрессия нужна, чтобы подтвердить целостность всей системы.

Полная или частичная?

Не всегда есть смысл запускать все тесты. Иногда достаточно проверить только затронутые области.

Полная регрессия

• Применяется перед важными релизами, в крупных системах
• Долго, но даёт уверенность

Частичная (селективная) регрессия

• Покрывает только затронутые фичи и связанные области
• Быстрее, но требует анализа

Грамотный QA всегда оценивает риски и решает, где нужна полная проверка, а где достаточно локальной.

Как автоматизация помогает в регрессии?

Ручная регрессия - боль. Повторять одни и те же сценарии снова и снова - неэффективно и утомительно. Поэтому автоматизация здесь - незаменимый союзник.

Стабильный набор автотестов:

• Проверяет функционал за минуты
• Снижает человеческий фактор
• Позволяет запускать тесты хоть при каждом коммите

CI/CD + автотесты = мгновенная регрессия без боли.

Чем регрессионное тестирование отличается от других?

| Тип теста   | Цель |
|-------------|------|
| Smoke       | Проверить, что система вообще запускается |
| Sanity      | Быстрая проверка отдельных фич |
| Регрессия   | Убедиться, что старый функционал не сломался |

Ошибки, которых стоит избегать

• Игнорировать регрессию: «ну я же новую фичу проверил, всё нормально!»
• Полагаться только на юнит-тесты: они не видят целостную картину
• Запускать вручную 100 тестов каждый раз: автоматизируй или сгоришь
• Не обновлять тесты после изменений: старая регрессия ≠ актуальная регрессия