Регрессионное тестирование: почему ручной регресс не масштабируется

Что проверяет регресс и почему без него нельзя

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

Глоссарий ISTQB определяет регрессионную проверку как повторное тестирование уже проверенной программы после изменений, чтобы убедиться, что новые дефекты не появились. Суть простая: каждый релиз может задеть то, что никто не трогал.

Регресс, смоук и санити: в чём разница

Эти три вида часто путают. Смоук — быстрая проверка, что сборка вообще живая: сайт открывается, вход работает, заказ создаётся. Занимает минуты.

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

Виды регрессионного тестирования: полный, выборочный, по рискам

• Полный регресс — прогон всех тест-кейсов. Надёжно, но долго: на крупном интернет-магазине вручную это дни работы.
• Выборочный — только тесты для изменённых модулей и их соседей. Требует понимания архитектуры.
• По рискам — сначала проверяются функции, поломка которых дороже всего: оплата, оформление заказа, личный кабинет.

Почему ручной регресс быстро становится узким местом

Объём регресса растёт с каждой функцией, а время на релиз не растёт. Через год жизни проекта набор из 50 тест-кейсов превращается в 500. Тестировщик перестаёт успевать и начинает проходить чек-лист по диагонали.

По трекам времени нашего QA это было видно без всякой аналитики. Прогон всех кейсов после каждого релиза — тяжёлый однообразный труд. Люди устают, внимание падает, а вместе с ним падает и смысл проверки.

Тогда я вспомнил, с чего начинал: я же программист, и тесты можно автоматизировать. Мы попробовали, и это оказалось не так дорого, как многие думают.

Сколько стоит ручной прогон

Простой расчёт: если регресс занимает 2 дня тестировщика, а релиз выходит раз в две недели, на повторные проверки уходит около 20% его времени. При еженедельных релизах — уже 40%.

Автотест пишется один раз и дальше выполняется за минуты. Окупаемость зависит от того, как часто вы релизитесь и сколько живёт проект.

Как собрать регрессионный набор

Хороший набор не равен всем тест-кейсам подряд. В него попадают сценарии, которые приносят деньги или чаще всего ломаются.

Порядок, который работает

• Выписать критические пользовательские пути: регистрация, поиск, корзина, оплата, личный кабинет.
• Добавить места, где ошибки уже случались. История багов в трекере подскажет, что ломается чаще.
• Проставить приоритеты: высокий — в каждый прогон, средний — перед крупными релизами, низкий — раз в квартал.
• Убрать дубли и устаревшие кейсы после каждого заметного изменения продукта.
• Решить, что автоматизировать первым: стабильные сценарии с частыми прогонами.

Пирамида тестов

Майк Кон в книге «Succeeding with Agile» 2009 года предложил пирамиду: в основании много быстрых модульных тестов, посередине интеграционные, на вершине немного медленных сквозных через интерфейс.

Для регресса это важный ориентир. Если весь набор живёт в UI-тестах, он медленный и хрупкий. Часть проверок дешевле перенести на уровень API.

Автоматизация регресса: инструменты и процесс

Для веба чаще всего берут Selenium, Playwright или Cypress. Playwright от Microsoft появился в 2020 году и умеет работать с Chromium, Firefox и WebKit одним API. Для PHP-проектов модульные проверки пишут на PHPUnit или Codeception, для мобильных приложений используют Appium.

Запуск встраивают в CI: GitLab CI, GitHub Actions или Jenkins прогоняют набор на каждый мердж-реквест или ночью. Разработчик узнаёт о поломке до того, как код попал на прод.

Нестабильные тесты

Тест, который то проходит, то падает без изменений в коде, хуже отсутствия теста. Команда перестаёт верить красному статусу и начинает его игнорировать.

Такие тесты надо сразу чинить или отключать. Частые причины — жёсткие задержки вместо ожидания элементов, общие тестовые данные и зависимость от внешних сервисов.

Какие метрики смотреть

Без цифр автоматизация быстро превращается в веру. Я бы следил за четырьмя показателями с первого месяца.

Время полного прогона. Если набор идёт дольше часа, разработчики начинают сливать код, не дожидаясь результата. Ориентир для проверки мердж-реквеста — 10–15 минут, полный ночной прогон может длиться дольше.

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

Ошибки, найденные после релиза

Главная метрика для бизнеса — сколько дефектов нашли пользователи, а не команда. Если после внедрения автотестов таких багов меньше, деньги потрачены не зря.

Четвёртый показатель — доля нестабильных тестов. Когда она выше нескольких процентов, команда перестаёт доверять набору, и его ценность падает быстрее, чем растёт покрытие.

Все четыре цифры удобно вывести на один дашборд в CI. Тогда разговор о качестве с заказчиком идёт по фактам, а не по ощущениям.

Типичные ошибки при внедрении

• Автоматизировать всё сразу и через полгода утонуть в поддержке тестов.
• Писать автотесты после релиза, когда на них нет времени.
• Отдать автоматизацию одному человеку, без которого набор никто не понимает.
• Не считать время прогона и терпеть часовые сборки.
• Уволить ручных тестировщиков: исследовательские проверки и UX машина не заменит.

Как объяснить бизнесу, зачем нужно тестирование

Заказчику проще показать цифры, чем рассказывать про качество. Я показывал примеры смет: сколько часов уходит на ручной прогон и сколько на написание и поддержку автотестов. Обычно расчёт сам отвечает на вопрос, нужна ли автоматизация на проекте.