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)