Три агенти Playwright: планувальник, генератор та усувач помилок у додатку для корзини.

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

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

Цільовим об’єктом демонстрації був невеликий додаток для кошика з логікою переходу від входу до каталогу товарів, кошика, процесу оплати та сторінки подяки. У підсумку було створено 22 автоматизовані сценарії, які охоплювали типові ситуації, негативні випадки та крайні ситуації перевірки. Вони виконуються паралельно, використовуючи об’єкти сторінок, які самі агенти підтримують. Звіт Playwright у форматі HTML показав 22 успішно пройдені тести, 0 невдалих та 0 нестабільних, причому весь набір тестів було завершено за 16,2 секунди.

Підготовчі кроки перед запуском будь-якого агента

Спочатку мають існувати три елементи. Більшість посібників їх ігнорують, але саме вони визначають, чи можна взагалі використовувати отриманий результат.

Сервер тестів MCP від Playwright. Агенти не повинні здогадуватися щодо структури DOM, тому вони використовують справжній браузер. Один файл конфігурації з’єднує їх між собою:

{
  "servers": {
    "playwright-test": {
      "type": "stdio",
      "command": "npx",
      "args": ["playwright", "run-test-mcp-server"]
    }
  }
}

Це надає кожному агенту інструменти на кшталт browser_navigate, browser_snapshot та browser_click, а також test_run та test_debug для Healer.

Контракт фреймворку. Один файл framework.md визначає структуру папок та правила: селектори знаходяться у pages/, сценарії взаємодії користувача — у flows/, а адреси та облікові дані — у .env. Кожен агент читає його перед виконанням будь-яких дій, тож результати виглядають як єдиний кодовий базис, а не три різні особисті стилі.

Тест-насіння. Один маленький специфікаційний документ відкриває справжню головну сторінку та перевіряє щось стабільне. Кожен генерований тест починається з цього відомого коректного стану.

Якістю агента визначаються ті „рейли“, на яких він працює, і це саме ті троє „рейлів“.

The Planner: вирішення, що заслуговує на тестування

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

Його алгоритм роботи:

1. Викликати функцію planner_setup_page один раз.
2. Досліджувати додаток за допомогою інструментів браузера, читаючи знімки DOM замість скріншотів.
3. Визначити основні сценарії використання та способи їхнього провалу.
4. Зберегти план у форматі markdown у файл specs/-plan.md.

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

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

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

Генератор: створення одного сценарію

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

1. Запускає generator_setup_page, щоб досягти початкового стану.
2. Виконує кожен крок безпосередньо в браузері, розглядаючи текст кроку як інструкцію.

Читає журнал виконання за допомогою generator_read_log, який містить індикатори та вказує, які з них справді спрацювали.

Викликає generator_write_test для створення одного файлу специфікації.

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

Результат автоматично відповідає правилам фреймворку:

// spec: specs/checkout-e2e-plan.md
// seed: tests/web/seed.spec.js

import { test, expect } from '../../../fixtures';
import { users } from '../../../testdata';test.describe.configure({ mode: 'parallel' });test.describe('E2E checkout journey', () => {
  test('positive: login → add product → checkout → thank you → home', async ({ flow }) => {
    await flow.completeHappyPathPurchase();
  });
});

У результаті значно відсутні CSS-селектори, текстовий пароль та рядки URL. Селектори переміщуються до об’єктів сторінки, а багатоетапні процеси перетворюються на методи класу потоку:

async completeHappyPathPurchase(user = users.standard, info = checkout.valid) {
  await this.goToCheckoutInformation(user);
  await this.fillValidInformation(info);
  await this.continueToOverview();
  await this.app.checkoutOverview.expectProductVisible(products.first.name);
  await this.finishOrder();
  await this.backHomeToProducts();
}

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

The Healer: виправлення правого шару

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

1. test_run виконує набір тестів та збирає інформацію про помилки.
2. test_debug зупиняється на кожній помилці.
3. Він аналізує поточний знімок екрана, консоль, мережевий трафік та несправну асертацію.
4. Він діагностує причину: змінений локатор, зміщення таймінгу, змінені умови або справжня помилка продукту.

Він виправляє причину, а не симптом: оновлює pages/, коли змінюється інтерфейс, та api/endpoints/, коли змінюється контракт.

Він знову запускає цей тест та переходить до наступної невдачі.

Два механізми захисту забезпечують його надійність. Він ніколи не послаблює умови перевірки лише для того, щоб отримати позитивний результат. Якщо продукт неправильний, а тест правильний, він позначає тест як test.fixme() та додає коментар, що описує справжню поведінку, щоб невдача залишалася видимою та не зникала. Він також уникає небезпечних API, таких як networkidle, які можуть використовуватися як тимчасове рішення проблеми з конкурентністю.

Перевагою є концентрація змін. Якщо перейменувати кнопку, буде відредаговано лише один метод об’єкта сторінки, після чого всі тести, що його використовують, знову будуть працювати. Оскільки 22 тести використовують 325 рядків об’єктів сторінки, розподілених між 10 класами, переробка не призводить до зриву всього набору тестів. У сукупності кожен елемент відповідає за чітко визначену частину репозиторію, а спільний шар об’єктів сторінки є тим, що підтримує всю структуру.

Запуск від початку до кінця

Команди налаштування:

1. Copy .env.example → .env, set BASE_URL (+ credentials)
2. npm install && npx playwright install

І агент виконує дії у наступному порядку:

3. Run the Planner
      → specs/checkout-e2e-plan.md   (22 scenarios, reviewed by me)4. Run the Generator, scenario by scenario
      → tests/web/login/login.spec.js
      → tests/web/cart/cart.spec.js
      → tests/web/checkout/checkout.spec.js
      → tests/web/e2e/checkout-journey.spec.js5. npm test        (4 workers, fully parallel)6. Any red? Run the Healer → re-run → green

Перехід на інший продукт не впливає на агентів. Встановіть BASE_URL на новий продукт, створіть заново об’єкти сторінки та тестові дані, а потім знову виконайте ті самі три запити. Оскільки агенти читають framework.md та .env, а не жорстко закодовану назву продукту, цей підхід є переносним та не спеціалізованим.

Наскільки це насправді швидше?

Твердження на кшталт „Штучний інтелект зробив це в десять разів швидше“ не слід приймати без детального аналізу. Розробка тесту від початку до кінця вручну рідко полягає лише у наборі тексту. Це означає відкриття DevTools, пошук стабільного селектора, знаходження кнопки всередині незвичайного обгортника, повторну роботу для перевірки того, чи не виконується перевірка занадто рано, та початок все знову. Більша частина зусиль припадає на цей цикл пошуку, а генератор компенсує його, виконуючи кроки в реальному часі та повідомляючи, що спрацювало.

Переваги проявляються на кількох етапах:

• Визначення охоплення. Уручну це робиться спорадично, і часто ігноруються негативні випадки. Planner заздалегідь перераховує позитивні, негативні та крайні сценарії.
• Пошук локаторів. Ручний пошук у DevTools для кожного елемента замінюється використанням локаторів, отриманих з уже пройденої сесії.
• Перший успішний тест. Цикл «написати, запустити, виправити та повторити» перетворюється на створення тесту на основі перевіреного текстового опису.
• Підтримка життєздатності набору тестів. Пошук у кожному специфікації пошкоджених селекторів замінюється виправленням одного об’єкта сторінки, що виправляє всі залежні тести.

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

Швидкість виконання походить з зовсім іншого джерела. Паралелізм — це не функція ШІ. Це правило проектування, якого мають дотримуватися агенти. Кожен тест отримує новий контекст з фікстур, і жоден з них не змінює стан спільного модуля, тому конфігурація виконується повністю паралельно: чотири працівники локально, два в CI з двома спробами, причому трекінг та відео записуються лише у разі провалу тесту. Будь-який набір тестів, який використовує одну сесію входу, не може працювати таким чином без ризиків. Цей набір може, тому що правило «один сценарій — один незалежний тест» було обов’язковим для дотримання у кожному файлі Генератором.

Чотири уроки, які варто запозичити

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

Виконання довіри замість роботи з пам’яттю. Локатори, підтверджені у запущеному браузері, є надійнішими, ніж ті, які вгадуються на основі документації.

Спочатку створіть каркас, а потім агенти. Об’єкти сторінки, фікстури, обробка середовища та паралельні правила — саме це робить результат роботи ШІ фреймворком, а не набором скриптів. Написання файлу framework.md покращило якість більше, ніж будь-яка корекція запиту.

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

Для кого це підходить

Інженери з тестування, які витрачають більше часу на усунення проблем, пов’язаних із локаторами, ніж на проектування механізмів покриття, отримають користь від цього. Так само будуть задоволені команди, які використовують Playwright та хочуть, щоб ШІ працював у рамках чітко визначеної структури, а не замінював людину, а також усі, хто порівнює агентів Copilot чи Cursor із тестовим сервером MCP від Playwright.

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