Інтеграція Playwright/Selenium з LLM для автономного тестування

Автономне тестування: де ламається ручний регрес

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

Затримка релізу зростає не лінійно: кожне доопрацювання додає кейси, а час на повний прогін залишається незмінним.

Друга точка відмови — підтримуваність перевірок. Той самий шлях користувача обростає дублями в різних наборах, і під час правки розмітки зміни доводиться вносити в кожен окремо.

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

Автономне тестування змінює джерело перевірок. Генерація перевірок виходить із постановки задачі та фактичної поведінки системи, а не з ручного переписування кроків: сценарій підлаштовується під змінений екран, дублі згортаються, а до кожного падіння додається розбір причини.

Зв'язка Playwright або Selenium із мовною моделлю дає виконувану перевірку та вердикт, який читається без занурення в код тесту, — застарілі кроки позначаються окремо, а не тихо падають.

Ефект на релізному циклі: повний прогін скорочується з днів до десятків хвилин, частка шляхів, підтверджених автоматично, зростає, а ручна праця зникає з повторюваних сценаріїв.

Водночас автономний контур не замінює дослідницьке тестування — він знімає рутину, залишаючи людям нові сценарії та спірні місця. Розбираємо, як це закривається на практиці — від збору покриття до розбору падінь.

Що змінюється після впровадження: покриття та швидкість

До впровадження покриття впирається в ручну працю: інженер описує перевірку, лише якщо вже знає, де ламається. Зв'язка Playwright і мовної моделі розбирає вимоги та проходить гілки сценарію сама — включно з негативними, до яких не доходили руки.

На критичних шляхах покриття зростає в рази, а у звіті видно, які гілки перевірені, а які залишилися без уваги.

Прогін перестає бути подією на півдня: перевірки розпаралелюються, і зміни отримують вердикт за хвилини, а не до вечора.

Це змінює поведінку команди — правку надсилають на перевірку одразу, а не накопичують пакетом до релізу, і помилка знаходиться в момент, коли її ще дешево виправити.

Нестабільні перевірки — головна причина, через яку червоний звіт перестають читати. Агент переперевіряє крок, що впав: повторює дію, звіряє розмітку та стан застосунку, відокремлюючи реальну поломку від таймауту або зміщеного селектора. Частка хибних падінь падає кратно, і сигнал знову сприймають як сигнал.

Разом із цим зникає клас відмов «пропустили перед релізом»: критичні шляхи проходять повністю на кожному кандидаті у випуск, а не вибірково за списком, складеним вручну. Рішення про випуск спирається на звіт щодо покриття та історію минулих падінь, а не на «ніби перевіряли». Стійкість релізів стає вимірюваною величиною, а не відчуттям.

Способи вбудовування перевірок: порівняння режимів

Режим перевірок визначає, скільки хибних падінь команда розбирає щотижня. Готові інструменти автоматизації передбачувані, але крихкі до правок розмітки; агент на базі мовної моделі переживає зміни інтерфейсу, зате потребує контролю коректності кроків.

Порівняння підходів нижче — за стійкістю до змін, охопленням сценаріїв і трудовитратами на підтримку.

На практиці базовий шар закривають детерміновані перевірки: вони дають однозначну відповідь «пройшло чи ні».

Агента підключають точково на ділянках, де розмітка змінюється щотижня, а візуальні та програмні перевірки розводять за різними наборами, щоб падіння верстки не маскувало помилку логіки.

Такий гібрид тримає частку хибних спрацювань низькою, а покриття зростає без переписування сценаріїв.

Як відбувається впровадження: етапи інженерної роботи

Впровадження відбувається короткими ітераціями: кожна закінчується робочим стендом і набором перевірок, який уже можна запускати. Так на будь-якому етапі залишається результат, придатний до використання, а не очікування фінальної здачі.

1. Аудит сценаріїв. Розбираємо регресійні набори та карту продукту, відбираємо критичні шляхи користувача й позначаємо, що закривається автономним тестуванням, а що усвідомлено залишається за ручною перевіркою.
2. Схема прогону. Фіксуємо, де запускаються перевірки, як ізолюються дані та як між сценаріями повертається початковий стан: інакше один тест, що впав, тягне за собою сусідні.
3. Налаштування середовищ. Піднімаємо стенди, тестові облікові записи та дані, налаштовуємо Playwright і прогін у браузерах, якими реально користується аудиторія продукту.
4. Генерація перевірок. Модель за описом сценарію та підказками про структуру сторінки видає чернетку перевірки, інженер править її та залишає лише те, що переживе найближчі правки інтерфейсу.
5. Перевірка стійкості. Ганяємо набір багаторазово на тому самому коді та вичищаємо кроки, що дають різний результат без змін у продукті.
6. Приймальна перевірка. Звіряємо автономний прогін із ручним на контрольних сценаріях і переконуємося, що навмисно внесені дефекти справді знаходяться.
7. Передача команді. Віддаємо конфігурації, правила підтримки перевірок та інструкцію з розширення набору — далі команда веде його сама.

Артефакти впровадження: схеми, конфігурації, регламенти

Впровадження автономного тестування закінчується не показовим прогоном, а комплектом, за яким команда замовника працює далі без нас. Усе йде в репозиторій замовника: конфігурації, схема перевірок, політики доступу та регламенти супроводу. Нижче — перелік артефактів впровадження, які приймаються разом із роботами.

• Схема перевірок — карта критичних шляхів із пріоритетами, списком передумов і ознаками, за якими сценарій вважається пройденим або проваленим.
• Конфігурації запуску — профілі для локального прогону, передрелізного контуру та нічної регресії: різні набори сценаріїв і різний рівень строгості перевірок.
• Політики доступу — виділені облікові записи для прогонів, заборона змінювальних операцій на продуктивних даних, зберігання секретів поза кодом і поза історією змін.
• Документація з прогону — як читати звіт, які артефакти зберігаються під час падіння (знімок екрана, журнал, запис кроків) і як відтворити збій на локальній машині.
• Регламент супроводу — строки розбору сценаріїв, що впали, умови переведення тесту в карантин, порядок оновлення селекторів під час зміни інтерфейсу.
• Правила розвитку набору — як додавати нові сценарії, хто погоджує їхній пріоритет і за якими ознаками тест видаляється як застарілий.

Приймання відбувається за кожним пунктом окремо: показуємо прогін на стенді замовника, розбираємо навмисно зламаний сценарій від звіту до причини та передаємо доступи, конфігурації й документацію інженерам, які залишаються на підтримці.

Кейс: як скоротили ручний регрес на потоці замовлень

Замовник — інтернет-магазин із потоком замовлень і релізами кожні два тижні. Регрес тримався на ручному прогоні: близько 320 перевірок, повний прохід займав 8–10 годин роботи двох інженерів і розтягувався на кілька днів.

Перевірки не встигали за змінами, і на реліз стабільно надходило 4–6 пропущених дефектів — частина спливала вже в оформленні замовлення.

Ми залишили сценарії в Playwright як шар виконання та надбудували над ними модель: вона збирає кроки з текстового опису перевірки, а під час зміни верстки знаходить елемент за змістом, а не за ланцюжком класів.

Регрес запускається на кожну зміну коду та вночі за розкладом, результат приходить звітом із кроками, знімками екрана та точкою падіння.

Через два місяці після запуску: повний прогін — 35–40 хвилин замість 8–10 годин, частка ручних перевірок упала з 100% до 12% — вручну залишилися вичитка листів і верстка на рідкісних пристроях, пропущені дефекти на реліз — 0–1 замість 4–6.

Окремий ефект — вартість підтримки: редизайн картки товару більше не ламає десятки тестів, частина відновлюється сама, решта правиться точково. Новий сценарій збирається за 20–30 хвилин замість половини дня: інженер описує перевірку словами, модель розгортає її в кроки. Автономне тестування стало частиною релізного циклу, а не окремим експериментом.

Чим автономне тестування відрізняється від класичних автотестів

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

Ламається він там, де змінюється розмітка: селектор не знаходить елемент, і перевірка падає не через дефект, а через правку верстки.

Автономне тестування починається там, де замість кроків задається мета та правила. Мовна модель отримує опис сценарію та стан сторінки, сама вирішує, куди натиснути й що ввести, а після кожної дії звіряє результат з очікуванням.

Елементи вона знаходить за змістом — за текстом, роллю, сусідніми блоками, — тому косметична правка розмітки не валить перевірку. Генерація кроків відбувається на кожному прогоні, а не один раз під час написання.

Звідси ключова відмінність — вартість підтримки перевірок. У класиці інженер лагодить селектори після кожної правки інтерфейсу, і разом із кількістю сценаріїв зростає ця частка. В автономному підході правлять опис мети та правила, код кроків переписувати не потрібно.

Вибір підходу диктує частота змін і ціна помилки, а не мода. Там, де вердикт має відтворюватися крок за кроком — платежі, права доступу, — залишається детермінований каркас, а автономні кроки підключають точково. Там, де інтерфейс переписують щотижня, автономний прогін виграє саме за рахунок меншої підтримки.

Сумніви інженерів: доступи, дані, нестабільні перевірки

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

Чи потрібні реальні тестові дані?

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

Як боретеся з нестабільними перевірками?

Нестабільність лікується очікуванням події, а не паузою: агент очікує на відповідь мережі, появу елемента або зміну стану, а не фіксовану затримку.

Кожне падіння потрапляє в чергу на розбір — перевірка, яка валиться на тому самому кроці, йде в карантин до виправлення й не блокує збірку.

Що з правами доступу та підтримкою після передачі?

Працюємо під окремим сервісним обліковим записом із мінімальними правами: читання даних і запуск тестів, без бойових секретів.

Після передачі залишаються конфігурації, політики карантину та регламент розбору падінь, а супровід перших прогонів займає рівно стільки, скільки потрібно вашій команді, щоб правити селектори самостійно.

Обговоримо задачу: що знадобиться для старту робіт

Щоб узятися за автономне тестування, повне технічне завдання не потрібне — достатньо короткого набору вхідних даних.

Чим раніше ми бачимо доступи, стенди та перелік критичних сценаріїв, тим точніша оцінка обсягу робіт і тим менше припущень у плані впровадження: агент, налаштований на демонстраційних даних, поводиться інакше, ніж на живому контурі з реальними ролями та станом бази.

• Репозиторій із поточними автотестами та права на окрему гілку під конфігурацію агента.
• Тестовий контур, що повторює бойовий за структурою даних і наборами ролей, зі своїми обліковими записами.
• Перелік критичних сценаріїв і правил: що вважати правильним результатом, а що — хибним спрацюванням.
• Регламент прогонів: за якою подією запускаємо, з якою періодичністю, хто розбирає звіт і в які строки.
• Доступ до журналів застосунку та системи обліку задач — туди агент заводить дефекти з кроками відтворення.
• Погоджені обмеження: які дані та операції не чіпаємо, де обов'язковий ручний підтверджувальний крок.
• Відповідальний з боку продукту, який розбирає спірні знахідки та підтверджує приймання.

Опишіть задачу у вільній формі — повернемося з оцінкою обсягу, вимогами до доступів і планом впровадження за етапами.