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-тестування та межами відповідальності.