E2E-тесты в CI/CD с Playwright и Cypress

Почему e2e-тестирование разваливается на нестабильных стендах

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

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

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

Что меняется после встраивания прогонов в конвейер сборки

Ключевые показатели, по которым видно, что прогоны встроились в конвейер, а не живут отдельным ночным заданием. Каждый пункт проверяется по логам и метрикам, а не по ощущениям команды.

• Время сборки. Полный набор браузерных сценариев раскладывается на параллельные потоки по файлам спецификаций, прогрев браузеров и подготовка данных вынесены из критического пути — прогон укладывается в минуты, а не растягивается на часы.
• Доля ложных падений. Ожидание сетевых ответов и появления элементов заменяет фиксированные паузы, тестовые данные изолированы по прогонам — набор перестаёт мигать на нестабильной среде, и красный отчёт означает реальный дефект.
• Раннее обнаружение дефектов. Проверки идут на каждый запрос на слияние: разрыв в цепочке «форма — запрос — ответ сервиса — запись в хранилище» видит автор изменения, пока контекст ещё в голове.
• Время восстановления стенда. Окружение поднимается из образа и сида за минуты, после сбоя прогон стартует с чистого состояния, а не чинится руками дежурного.
• Наблюдаемость результата. Отчёт сохраняет видео, трассировку и снимок состояния на шаге падения — разбор занимает минуты вместо переписки «у меня не воспроизводится».
• Ушедший класс отказов. Ошибки интеграции между сервисами и регрессии в пользовательских сценариях ловятся до выкладки, а не в обращении клиента.

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

Форматы запуска e2e-тестирования: регресс, дымовые, ночные

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

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

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

Этапы внедрения: от аудита стенда до передачи регламентов

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

1. Аудит стендов и сценариев. Инвентаризуем контуры, доступы и тестовые данные, собираем реестр критичных пользовательских путей и отсекаем то, что дешевле проверять на уровне ниже. На выходе — карта покрытия с явными пробелами.
2. Схема окружений. Разводим контуры по назначению: где идёт полный набор, где короткий дымовой, как готовятся данные и откатывается состояние между прогонами. Это снимает главную причину ложных падений.
3. Настройка прогонов. Встраиваем набор на Playwright и Cypress в конвейер: на изменения — сокращённый список по затронутым зонам, ночью — полный. Отчёт показывает не «упало двенадцать тестов», а конкретный путь и шаг.
4. Стабилизация падений. Разбираем каждый нестабильный тест: явные ожидания вместо фиксированных пауз, изоляция данных, повтор только при подтверждённом сбое инфраструктуры. Ориентир — доля успешных прогонов выше 95%.
5. Проверка на реальных релизах. Прогоняем набор параллельно с несколькими релизами и сверяем сигналы с фактическими дефектами: видно, ловит ли он регрессии или просто шумит.
6. Передача регламентов. Отдаём документацию: как добавить тест, как читать отчёт, кто и что делает при падении. Дальше команда ведёт набор сама.

Артефакты на выходе: конфигурации, схемы стендов, регламенты

Что остаётся у заказчика — не отчёт о работах, а комплект артефактов в вашем репозитории: прогон e2e-тестирования поднимается на чистой машине по инструкции, без обращения к нам.

• Конфигурации окружений — параметризованные профили стенда и предпродуктивной среды: адреса, таймауты, наборы тестовых учёток. Секреты лежат в хранилище секретов, а переключение среды делается одной переменной запуска.
• Схема стенда — диаграмма связей: где идут браузерные прогоны, как наполняются тестовые данные, что нужно для восстановления окружения с нуля.
• Правила доступа к данным — какие учётки используются, какие данные синтетические, как сценарии изолируются, чтобы параллельные прогоны не перетирали состояние друг друга.
• Документация по прогонам — как читать отчёт, где трассировки и скриншоты упавших шагов, сколько хранятся артефакты, как локально перезапустить один сценарий.
• Регламент релиза — какие наборы блокируют выкладку, какие идут информационно, кто и в какой срок разбирает красный прогон.
• Порядок разбора падений — критерий нестабильного сценария и карантин с обязательным тикетом на починку, чтобы шум не маскировал реальные дефекты.
• Вспомогательные модули — общие селекторы, шаги и фикстуры, чтобы ваши инженеры дописывали сценарии на Playwright или Cypress без нас.

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

Кейс: время проверки релиза сократилось в четыре раза

Точка отсчёта

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

Что изменили

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

Замеры после

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

Что делать, если проверки уже развёрнуты, но им не доверяют

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

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

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

Частые вопросы о стендах, данных и ложных падениях

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

Нужен отдельный стенд или хватит общего тестового контура?

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

Откуда брать тестовые данные?

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

Не придётся ли переписывать сценарии после каждого релиза?

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

Обсудим задачу: что подготовить к старту работ

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

• Доступы к репозиторию и конвейеру сборки: на старте достаточно прав на чтение и возможности запускать сборку вручную.
• Тестовый стенд с изолированной базой, предсказуемыми учётными записями и ролями, возможностью вернуть данные в исходное состояние между прогонами.
• Перечень критичных сценариев — 10–20 путей, сбой которых обходится дороже всего: вход, оплата, оформление заказа, выгрузка отчётов.
• Решение по внешним сервисам: где подменяем их заглушками, а где нужна отдельная тестовая среда поставщика.
• Контактные лица по клиентской части, серверной части и инфраструктуре — один человек, который сводит решения и подтверждает приёмку.
• Существующие артефакты: старые тесты, журналы падений, отчёты о дефектах, описание релизного цикла и окон развёртывания.

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