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

Каждая команда, выпускающая ПО достаточно долго, приходит к одному ритуалу. Перед релизом кто-то открывает таблицу — или документ в 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, простым языком расписываете по шагам процессы из регрессионного чек-листа и указываете ожидаемый результат, проверяете собранные по этим шагам сценарии и запускаете их по запросу или раз в день по расписанию. Сместившиеся элементы находятся заново, а у неудачного запуска сохраняются шаг со сбоем, скриншоты, логи и объяснение; решение, баг это или сценарий пора обновить, остаётся за человеком. Таблица, наконец, отправляется на пенсию.

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