Конец ручного регрессионного тестирования

Каждая команда, выпускающая ПО достаточно долго, приходит к одному ритуалу. Перед релизом кто-то открывает таблицу — или документ в Notion, или набор в TestRail — и начинает кликать. Войти. Создать заказ. Применить купон. Вернуть деньги. Поменять настройку и проверить, что она сохранилась. Список растёт каждый квартал, потому что каждый инцидент добавляет строку, удалять которую уже никому не разрешается.

Это ручное регрессионное тестирование, и это самая дорогая привычка в большинстве инженерных организаций. Не потому что какой-то отдельный тест сложен, а потому что работа масштабируется линейно с продуктом, тогда как продукт масштабируется экспоненциально с командой. Эта статья о том, почему модель наконец сломалась, почему очевидное решение — автоматизация record-and-replay — в основном провалилось и как выглядит рабочая замена.

Во что реально обходится регрессия

Честная стоимость ручной регрессии редко попадает в бюджет. Она прячется в трёх местах.

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

Второе — деградация покрытия. Ручные наборы пишут один раз и поддерживают плохо. Прополку никто не любит, поэтому накапливаются шаги, не соответствующие продукту, и тихо пропускаются потоки, добавленные после написания документа. Набор становится описанием продукта, каким он был полтора года назад.

Третье, и худшее, — усталость суждения. Человек, в сороковой раз проходящий одни и те же 300 шагов, к шагу 200 уже не внимателен. Баги, ради которых регрессия и существует — тонкая визуальная регрессия, ошибка на единицу в сумме, несохранившееся состояние — ровно те, мимо которых уставший человек прокликивает.

Почему ручная регрессия ломается

Структурная проблема в том, что ручная регрессия предполагает медленные и локальные изменения. Вы трогали код биллинга — значит, перетестируем биллинг. Это работало, когда релиз был скоординированным событием от горстки людей, понимавших радиус влияния своих изменений.

Больше это не работает. Релизы теперь собирают изменения от большего числа участников, затрагивают больше поверхностей и чаще — сдвиг, который мы подробно разбираем в статье Почему традиционный QA не поспевает за AI-разработкой. Когда любое изменение может затронуть любой поток, «перетестируй то, что трогал» перестаёт быть стратегией, потому что вы больше не можете дёшево узнать, что именно вы затронули. Безопасный ответ — перетестировать всё, каждый раз, — ровно то, чего ручное тестирование не может делать быстро.

Ловушка автоматизации

Ответ индустрии на протяжении двух десятилетий — записывать клики человека и воспроизводить их. Selenium, затем поколение record-and-replay инструментов обещали превратить ручную таблицу в скрипт, который гоняется на каждой сборке.

На практике большинство команд, пошедших этим путём, обменяли одну проблему на более коварную. Скрипты были привязаны к реализации UI, а не к его намерению. Типичный записанный шаг выглядит так:

await page.click("#checkout-btn-v2");
await page.fill("input[name='card_number']", "4242424242424242");
await page.click(".payment-form > button.primary");
await expect(page.locator("div.receipt-modal")).toBeVisible();

Каждый из этих селекторов — обещание, что DOM никогда не изменится. Но UI меняется постоянно: редизайн переименовывает checkout-btn-v2, библиотека компонентов меняет класс, форму переставляют. Когда это происходит, тест падает. Не потому что продукт сломан, а потому что тест описывал мебель вместо поведения.

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

Так команды пришли к тому, что содержат целую роль — инженера автоматизации — во многом чтобы поддерживать автоматизацию живой. Тесты должны были экономить человеческий труд; вместо этого они перенесли его из «прокликивания потоков» в «починку селекторов». Налог не исчез. Он переехал.

Что действительно приходит на замену

Замена — это не «больше скриптов» и не «лучше селекторы». Это другая единица покрытия: намерение вместо реализации.

Регрессионная проверка должна выражать, что должно оставаться истинным для пользователя, а не точный путь в DOM для проверки этого сегодня. «Вернувшийся клиент может завершить чекаут и получить чек» — долговечное утверждение. #checkout-btn-v2 — нет. Когда покрытие выражено как намерение, система может заново выводить конкретные шаги при каждом изменении интерфейса — так же, как человек-тестировщик, получив новую сборку, сам находит, куда переехала кнопка чекаута.

Практичным на масштабе это делают две возможности.

Самообновляющееся покрытие

Первая — покрытие, которое перегенерирует себя. Вместо того чтобы человек писал и поддерживал каждый сценарий, система исследует продукт, строит модель существующих потоков и переписывает конкретные шаги при изменении продукта. Покрытие перестаёт деградировать, потому что поддерживать его актуальным больше не рутина, которую нужно помнить. Это ядро идеи современного AI-тестирования: рычаг, удешевивший написание кода, направляется на сами тесты.

Валидация, а не только выполнение

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

Реалистичный путь миграции

Вы не удаляете ручной набор в пятницу. Прагматичный переход выглядит так:

1. Инвентаризация по ценности, а не по истории. Ранжируйте потоки по влиянию на бизнес — выручка, удержание, целостность данных, — а не по тому, как давно существует тест. В большинстве ручных наборов 20% — критические потоки, а 80% — археология.
2. Сначала переведите критические потоки на покрытие по намерению. Именно их вы и так перетестируете каждый релиз, поэтому окупаемость наступит быстрее всего.
3. Дайте длинному хвосту обнаружиться. Потоки, которые никто не помнит тестировать, — ровно те, что хорошо всплывают при автоматическом обнаружении. Покрытие, о нехватке которого вы не знали, — самое ценное.
4. Оставьте людей на фронтире. Новые, неоднозначные или требующие суждения функции всё ещё заслуживают человеческого взгляда — см. Как ИИ меняет роль QA-инженеров.

Что не исчезает

Было бы нечестно утверждать, что ручное тестирование сходит в ноль. Три вещи упрямо остаются человеческими.

Исследовательское тестирование — намеренная попытка сломать что-то новое — это творческий акт, а не чек-лист, и оно ценно именно потому, что не по скрипту. Суждение о юзабилити — «технически работает, но ощущается неправильно» — не ассерт «прошёл/не прошёл». А приёмка по-настоящему новой функциональности, где нет прошлой версии для регрессии, требует того, кто понимает, что вообще должно означать «корректно».

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

Рабочий пример: купон, который сломался тихо

Конкретный случай делает аргумент менее абстрактным. Команда выпускает рефакторинг модуля цен — чистое, хорошо отревьюенное изменение, объединяющее три пути обработки скидочных кодов в один. Юнит-тесты проходят. Дифф выглядит отлично. Он мёржится.

Что ручной регрессионный набор должен был поймать: процентный купон (SAVE20) теперь применяется до налога, а не после, меняя итог на несколько копеек в части заказов. Это дефект, не дающий ни ошибки, ни строки в логе, ни упавшего запроса — только неверное число в чеке.

При ручной регрессии поймать это можно, только если человек специально создаст заказ, применит SAVE20 и сверит арифметику с ожидаемым значением — на шаге ~140 из 300, в 16

, в сороковой раз. На практике он жмёт «применить», видит появившуюся скидку и идёт дальше. Баг уходит в продакшен. Его находят через три недели клиент или финотдел при сверке.

Теперь сравните с версией по намерению. Покрытие — это не «нажми применить и посмотри глазами». Это инвариант: итог равен сумме позиций минус скидка плюс налог, посчитанный на сумму со скидкой. Это утверждение не зависит от того, какую кнопку или класс использует UI, и машина проверяет арифметику точно, каждый раз, без усталости. Рефакторинг проваливает эту проверку в тот же миг, как приземляется, — пока автор ещё помнит, зачем трогал модуль цен.

Урок обобщается: ручная регрессия слабее всего именно там, где дефекты тише всего. Всё, что падает громко, вы поймали бы и так. Проблема в тихо неверном итоге, несохранившемся состоянии, ошибке на единицу, которую уставший человек пропускает.

Заключение

Ручное регрессионное тестирование никогда не было про тестирование. Это был способ покупать уверенность человеко-часами, и он работал, пока человеко-часы поспевали за изменениями. Больше не поспевают. Record-and-replay это не решил, потому что автоматизировал клики, но не поддержку, — так что налог просто переехал с тестировщиков на инженеров автоматизации.

Долговечный ответ — сменить единицу покрытия с реализации на намерение, дать этому покрытию поддерживать себя и валидировать сбои до того, как они дойдут до человека. Это модель BuniOD — вы подключаете продукт по URL или через репозиторий, а регрессионное покрытие генерируется, держится актуальным и непрерывно валидируется по мере релизов. Таблица, наконец, отправляется на пенсию.

Если ваш релиз всё ещё заблокирован человеком, кликающим по чек-листу, — это первое место, куда стоит посмотреть. Всё, что ниже по течению — частота деплоев, число инцидентов, боевой дух инженеров — платит за это.