Playwright 1.64 і WebMCP: як тестувати те, що написав агент

У жовтні 2026 року в тестуванні сталися дві речі, які варто розглядати разом. Вийшов Playwright 1.64 із доступом до інструментів, що сторінка реєструє для AI-агентів. І вийшло опитування Stack Overflow, яке показало, наскільки мало розробники довіряють тому, що ці агенти пишуть. Друге робить перше цікавим.

Що нового в Playwright 1.64

Playwright 1.64.0 опублікували 7 жовтня 2026 року, патч 1.64.1 — 14 жовтня. Коротко про те, що справді змінює роботу:

• WebMCP: page.webmcp і frame.webmcp — доступ до інструментів, які сторінка реєструє через експериментальний браузерний API WebMCP. Playwright MCP підтримує WebMCP за замовчуванням, а playwright-cli дає команди webmcp-list і webmcp-call.
• locator.within() — комбінує два локатори. Дрібниця, яка прибирає цілий клас крихких селекторів.
• page.getByRef() — ще один спосіб звернутися до елемента.
• Відео: з'явилася опція fps, оформлення підсвічування дій через style, кодек змінено з VP8 на VP9; опція fontSize застаріла.
• Тест-раннер: testProject.default (виключити проєкт із запуску за замовчуванням), --shuffle, опція lock у test.describe.configure(), тип 'webp' для toHaveScreenshot.
• Інше: includeShadow для content(), signCount для віртуальних credentials, fullConfig.filteredProjects, методи роботи з cookie в apiRequestContext.

У версії 1.63 (4 вересня 2026) з'явилися locator.visible() замість псевдокласу :visible, frameLocator() без селектора для пошуку по всіх фреймах, aria- і screen-снапшоти у трейсах. Там само припинили оновлювати експериментальні пакети component testing для React і Vue і прибрали підтримку Ubuntu 20.04.

WebMCP: сторінка, яка сама дає інструменти агенту

Щоб зрозуміти, чому page.webmcp важливіший за решту списку, варто побачити зміну підходу.

Зазвичай агент працює з вебсторінкою так само, як людина: шукає кнопки, читає текст, клікає. Це крихко — будь-яка зміна верстки ламає сценарій. WebMCP перевертає відповідальність: сама сторінка оголошує набір інструментів, якими можна користуватися. Умовно замість «знайди кнопку з текстом Додати до кошика і клікни» з'являється інструмент addToCart з описаними параметрами.

Для QA це означає дві нові задачі. По-перше, ці інструменти теж треба тестувати — вони стають частиною публічного інтерфейсу застосунку, як API. По-друге, через page.webmcp ви можете викликати їх із тесту безпосередньо, не імітуючи клікання.

Варто бути точними: WebMCP — експериментальний браузерний API. Це не те, що треба негайно вносити у виробничу стратегію тестування. Але це добрий момент, щоб розібратися, бо якщо підхід закріпиться, він змінить і тестування, і те, як ми описуємо інтерфейси. Якщо термін MCP для вас новий, подивіться коротке визначення в глосарії.

Зміни, які можуть зламати ваші тести

Це та частина релізу, яку найчастіше пропускають, а потім дивуються червоному CI. У 1.64 чотири зміни поведінки:

1. Елементи в схованих iframe тепер вважаються схованими. Це стосується дій, isVisible() і toBeVisible(). Якщо якийсь тест працював з елементом у схованому iframe — він почне падати. Найімовірніша причина червоного CI після оновлення.
2. screen передається з device descriptors. Щоб відмовитися, треба явно вказати screen: undefined.
3. --update-snapshots=missing більше не валить запуск. Режим за замовчуванням перейменовано на 'default': він досі записує відсутні снапшоти і при цьому позначає тест як невдалий.
4. JSX у тестових файлах тепер підкоряється tsconfig.json і за замовчуванням використовує automatic runtime.

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

6,6%: скільки розробників довіряє ШІ

6 жовтня 2026 року Stack Overflow опублікувала щорічне опитування — понад 30 000 респондентів із 169 країн. Цифри, які прямо стосуються тестування:

• 66% користуються AI-асистентами або агентами для коду;
• 26,2% уже використовують автоматизовані агентні процеси;
• 6,6% довіряють відповідям ШІ у важливих робочих рішеннях;
• близько половини довіряють, коли результат легко перевірити;
• 78,7% вважають важливим або дуже важливим бачити джерело інформації.

Складіть це разом: дві третини ринку вже генерують код агентами, і майже ніхто не довіряє результату без перевірки. Це і є опис попиту на QA у 2026 році. Питання не в тому, чи ШІ замінить тестувальника, а в тому, хто підтвердить, що згенерований тест справді щось перевіряє.

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

Вісім пунктів, які можна застосувати до будь-якого згенерованого тесту. Перший — найважливіший.

1. Зламайте код навмисно. Змініть логіку, яку тест нібито перевіряє, і переконайтеся, що тест упав. Якщо він проходить і до, і після поломки — він не перевіряє нічого. Це єдиний спосіб відрізнити справжній тест від декорації.
2. Перевірте, що тестується поведінка, а не реалізація. Тест, прив'язаний до внутрішньої структури, падатиме після будь-якого рефакторингу й не ловитиме справжніх помилок.
3. Знайдіть фіксовані очікування часу. waitForTimeout і подібне — джерело «мерехтливих» тестів. У Playwright є вбудовані очікування; агент часто про них «забуває».
4. Перевірте локатори. Селектори на кшталт довгих CSS-ланцюжків або позицій у DOM зламаються на першій зміні верстки. Шукайте локатори за роллю, текстом або data-testid.
5. Запустіть тест ізольовано й у випадковому порядку. Нова опція --shuffle у 1.64 для цього й потрібна. Тест, який проходить лише в конкретному порядку, залежить від стану, залишеного іншими тестами.
6. Перевірте, що саме стверджує assert. Твердження на кшталт «елемент існує» часто проходять там, де насправді потрібне «елемент містить правильне значення».
7. Подивіться на межові випадки. Агенти добре покривають щасливий шлях і погано — порожні дані, помилки сервера, довгі рядки, подвійні кліки.
8. Прочитайте назву тесту. Якщо з назви не зрозуміло, що саме зламалося при падінні, тест не допоможе тому, хто читатиме CI через місяць.

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

Що вчити QA у 2026 році

Порядок важливий — він від фундаменту до інструментів:

1. Тестування як дисципліна. Типи тестів, межові випадки, пріоритизація, звіти про дефекти. Без цього автоматизація дає швидкі, але нікому не потрібні тести.
2. Програмування на базовому рівні. JavaScript або Python: функції, асинхронність, структури даних.
3. Playwright серйозно. Локатори, вбудовані очікування, фікстури, трасування. Трейси — найкорисніше й найменш використовуване.
4. Робота з API. Більшість помилок дешевше ловити на рівні API, ніж через інтерфейс.
5. CI. Тест, який не запускається автоматично, не існує.
6. Перевірка згенерованого коду. Нова, дефіцитна і найцінніша навичка з цього списку.

Докладніше про те, як професія змінюється під впливом ШІ, — у статті QA Engineer в епоху ШІ. Якщо готуєтеся до співбесіди, подивіться питання на співбесіді QA.

Де навчитися тестуванню

• Курс QA Engineer — ручне тестування як фундамент професії.
• QA Automation — автоматизація для тих, хто вже розуміє тестування.
• За підпискою — тестування JavaScript: unit-тести, TDD і моки і Docker з нуля для запуску тестів в ізольованому середовищі.

Короткі визначення термінів, які зустрічалися в статті: Playwright і E2E-тестування.

Часті запитання

Що таке WebMCP у Playwright 1.64?

WebMCP — це експериментальний браузерний API, через який сама сторінка реєструє інструменти для AI-агентів. Playwright 1.64 додав page.webmcp і frame.webmcp, щоб у тестах можна було звертатися до цих інструментів. Playwright MCP підтримує WebMCP за замовчуванням, а playwright-cli дає команди webmcp-list і webmcp-call.

Яка зміна в Playwright 1.64 найімовірніше зламає наявні тести?

Елементи всередині схованих iframe тепер вважаються схованими для дій, для isVisible() і для toBeVisible(). Якщо ваш тест працював із таким елементом, він почне падати. Також screen тепер передається з device descriptors — відмовитися можна через screen: undefined.

Чи замінить AI тестувальника?

За опитуванням Stack Overflow 2026 року лише 6,6% розробників довіряють відповідям ШІ у важливих робочих рішеннях, а 78,7% вважають важливим джерело інформації. Тобто ринок хоче не менше ШІ, а перевірюваного ШІ. Для QA це означає зростання, а не зникнення роботи: хтось має підтвердити, що згенерований тест справді перевіряє поведінку.

Як перевірити тест, який написав агент?

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

Що краще вчити у 2026 році: Playwright чи Selenium?

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

З чого почати шлях у QA automation з нуля?

З ручного тестування й розуміння, що таке якість: типи тестів, тест-кейси, пошук межових випадків. Паралельно — базове програмування (JavaScript або Python) і робота з браузером через інструменти розробника. Автоматизація без розуміння тестування дає швидкі, але нікому не потрібні тести.

Джерела

• Playwright — Release notes 1.64 / 1.63
• GitHub — Playwright releases (1.64.0 — 7 жовтня 2026, 1.64.1 — 14 жовтня 2026)
• Stack Overflow Developer Survey 2026 (6 жовтня 2026)