QA Automation: Playwright меняет поведение тестов, GitHub Actions получает lockfile

QA Automation: Playwright меняет поведение тестов, GitHub Actions получает lockfile

С 12 по 19 октября 2026 года вышло несколько обновлений, которые стоит проверить перед следующим запуском регрессии: GitHub Actions начал поддерживать lockfile для workflow, Playwright 1.64 иначе определяет видимость элементов в iframe, а Schemathesis научился сохранять найденные API-дефекты в виде Pytest-тестов.

Разбираю, что это меняет для QA Automation и какие проверки стоит запустить у себя.

GitHub Actions: workflow теперь можно защитить от неожиданной смены версии Action

14 октября GitHub открыл публичное тестирование workflow dependency lockfiles.

Проблема знакома многим: в YAML написано actions/checkout@v4, но тег может быть перенесён на другой коммит. Получается, содержимое workflow не меняли, а при следующем запуске мог выполниться уже другой код.

Новый файл .github/workflows/actions.lock фиксирует конкретные коммиты используемых Actions, их транзитивных зависимостей и reusable workflows.

В самом YAML можно оставить понятные имена версий. Для создания и проверки lockfile GitHub предлагает расширение gh actions-lock, а Dependabot способен обновлять записи вместе с зависимостями.

Что делать QA-инженеру: возьмите один некритичный CI-workflow с Pytest и включите lockfile сначала только для него. Проверьте, что будет при обновлении Action, и обязательно просмотрите изменения в lockfile перед слиянием PR.

Важно: функция пока в public preview. Если подключённый workflow ссылается на зависимость, которой нет в lockfile, запуск не пройдёт. Кроме того, закреплённый SHA не означает, что сторонний Action безопасен.

Источник: GitHub Changelog, 14 октября 2026.

Playwright Python 1.64: некоторые E2E-тесты могут начать падать

13 октября вышел Playwright Python 1.64.0. Одно из наиболее важных изменений для автоматизаторов связано с iframe.

Раньше Playwright мог считать элемент видимым, даже когда сам iframe скрыт. Теперь элементы внутри невидимого iframe считаются невидимыми и для действий, и для проверок locator.is_visible() и expect(locator).to_be_visible().

Пример из практики: на странице оплаты есть iframe с платёжной формой. Элемент внутри фрейма присутствует в DOM, но контейнер скрыт.

После обновления тест, который раньше «находил» такую кнопку, может завершиться ошибкой. И это не обязательно баг Playwright: новая проверка лучше соответствует тому, что видит пользователь.

Что делать QA-инженеру: отдельно прогоните E2E-сценарии с оплатой, авторизацией и встроенными виджетами на старой и новой версии. При падении откройте trace и проверьте реальную видимость iframe.

Не начинайте исправление с force=True: так легко замаскировать проблему в интерфейсе.

[ИЗОБРАЖЕНИЕ 2: видимый и скрытый iframe, сравнение результата проверки]

В 1.64 также появились locator.within() для поиска внутри заданного родительского локатора и методы управления cookie у APIRequestContext - add_cookies(), cookies() и clear_cookies().

Последние полезны для API-проверок авторизации и выхода из системы без создания полноценного браузерного контекста.

Источник: Playwright Python 1.64.0, release notes.

Schemathesis 4.32: найденный API-баг превращается в Pytest-тест

18 октября вышел Schemathesis 4.32.0.

Это инструмент, который генерирует проверки API по OpenAPI-схеме и помогает находить неожиданные ошибки.

Теперь флаг --report pytest позволяет экспортировать найденные сбои в отдельные тесты на Pytest.

Почему это полезно?

Допустим, генератор подобрал комбинацию входных данных, при которой endpoint возвращает 500 вместо ожидаемого ответа.

Обычно QA нужно вручную восстанавливать запрос, писать тест и добавлять его в регрессию. Теперь первая версия воспроизводящего теста может быть сформирована автоматически.

Но экспорт не заменяет работу инженера. Перед добавлением такого теста в репозиторий нужно убрать случайные идентификаторы, не сохранить токены или личные данные и обеспечить подготовку и очистку тестовых сущностей.

Ещё два полезных изменения: стабильные коды ошибок вида ST101 и команда st explain <code>, которая объясняет проблему.

Кроме того, улучшена передача идентификаторов ресурсов между запросами при stateful-тестировании.

Что попробовать: запустите Schemathesis на отдельном тестовом стенде, сохраните один найденный сбой как Pytest-тест и доведите его до стабильной регрессионной проверки.

Сначала убедитесь, что тест воспроизводит проблему до исправления, а после исправления проходит.

Проверьте совместимость: ветка Schemathesis 4.31+ требует Python 3.11 или новее. Если тестовый проект ещё на Python 3.10, не обновляйте пакет без проверки окружения.

Источники: Schemathesis 4.32.0, Schemathesis 4.31.0.

Docker Desktop 4.95: меньше ложных падений из-за окружения

12 октября вышел Docker Desktop 4.95.0.

В нём исправили ошибку macOS, мешавшую запускать подпроцессы после повторного открытия Docker Desktop, и отдельную проблему старта локального Kubernetes после сетевого тайм-аута при загрузке образа.

В комплекте поставляется Docker Compose 5.6.0.

Для QA Automation это важно по простой причине: упавший API-smoke не всегда означает ошибку продукта.

Иногда стенд не успел корректно подняться, контейнер недоступен или сервисы запустились не полностью.

Что проверить: после обновления дважды пройдите полный цикл запуска Docker Desktop, docker compose up, проверки готовности сервисов и API-smoke.

Зафиксируйте версии Docker Desktop и Compose. Если время старта изменилось, не списывайте результат автоматически на изменения тестов.

Источник: Docker Desktop release notes 4.95.0.

Python 3.15: пора проверить зависимости, но не спешить с миграцией

9 октября вышел стабильный Python 3.15.0.

Среди изменений - UTF-8 по умолчанию и поддержка явных ленивых импортов.

Для команды автоматизации разумнее сначала добавить Python 3.15 в тестовую матрицу CI.

Проверьте установку пакетов, сбор тестов через pytest --collect-only, работу плагинов и чтение файлов.

На новый Python особенно внимательно нужно переносить проекты с бинарными зависимостями.

Источник: Python Insider, 9 октября 2026.

Что из этого стоит внедрить первым

Если у вас много E2E-проверок с iframe, начните с Playwright 1.64: это изменение может повлиять на существующие проверки.

Если у команды важны воспроизводимые сборки - протестируйте lockfile в GitHub Actions.

А если вы автоматизируете API, попробуйте перенос найденного Schemathesis дефекта в постоянную регрессию.

В своих учебных проектах я стараюсь разбирать такие изменения не только по release notes, но и через реальный код: CI, API-тесты, браузерные сценарии и диагностику падений.

Если вы хотите освоить Python, Pytest и Playwright на практике, посмотрите форматы обучения в EasyITLab.

А что вы проверяете первым после обновления инструментов - совместимость тестов, стабильность CI или новые возможности?