Инструменты автоматизации: вопросы для собеседования QA

@step — маркирует метод как шаг в отчёте, отображается в иерархии шагов теста; @description — добавляет текстовое описание теста; @severity — устанавливает уровень критичности (BLOCKER, CRITICAL, NORMAL, MINOR, TRIVIAL).

@feature и @story группируют тесты по функциональным областям продукта, что позволяет фильтровать отчёт по фичам; @link и @issue добавляют ссылки на задачи и баг-трекер.

Из практики: использую аннотации умеренно — @step и @severity обязательно, остальное там, где это реально помогает навигации по отчёту. Перегруженный отчёт читается хуже, чем простой.

Для Python: устанавливаю allure-pytest, запускаю тесты с флагом --alluredir=allure-results, затем генерирую отчёт командой allure serve. Шаги оборачиваю декоратором @allure.step, вложения добавляю через allure.attach.

Для Java: подключаю allure-junit5 или allure-testng через Maven/Gradle, аннотации @Step, @Attachment и @Description работают из коробки. Отчёт генерируется через mvn allure:report.

Из практики: важно настроить хранение allure-results в CI как артефакты и подключить history для отображения тренда стабильности между прогонами.

Строю UI-автоматизацию на трёх китах: надёжные локаторы (приоритет: data-testid > id > CSS > XPath), явные ожидания через WebDriverWait + ExpectedConditions вместо sleep, Page Object Model для разделения сценария и деталей страницы.

Управление WebDriver: для параллельного запуска использую ThreadLocal<WebDriver> вместо статического поля. WebDriver создаю в @BeforeEach, закрываю в @AfterEach.

Из практики: 90% нестабильности UI-тестов — отсутствие явных ожиданий. `driver.findElement()` без ожидания падает на медленных CI-серверах даже если локально работает стабильно.

Вложения добавляю через Allure API: аннотация @Attachment над методом или Allure.addAttachment(name, type, content) — так в отчёт попадают скриншоты, логи, запросы/ответы.

Скриншот снимаю на падении, логи и HTTP-трафик прикладываю как текст, видео прогона подключаю через записывающее расширение/файл.

Custom data кладу как произвольное вложение (JSON, CSV, файл) с нужным mime-type; добавляю только полезное, чтобы отчёт оставался читаемым.

Из практики: хорошо подобранные вложения снимают половину вопросов при разборе падения.

Suites/иерархию задаю BDD-метками @Epic/@Feature/@Story, чтобы отчёт группировался по логике продукта.

Categories настраиваю через categories.json — правила классификации падений (product defects vs test defects) по сообщению и трейсу.

Environments прокидываю через environment.properties (версия, стенд, браузер), чтобы контекст прогона был виден в отчёте.

Из практики: аккуратная структура и категории ускоряют разбор и принятие решений по релизу.

В Jenkins подключаю плагин Allure Jenkins Plugin, указываю путь к результатам (allure-results), история отчётов хранится между сборками автоматически.

В GitHub Actions использую шаг allure-report/allure-action, публикую отчёт на GitHub Pages или как артефакт сборки с retention policy.

Из практики: важно хранить historytrendline — без него команда не видит динамику стабильности, только срез по последнему прогону.

Playwright — это фреймворк автоматизации браузера от Microsoft. Управляет Chromium, Firefox и WebKit через единое API. Тесты пишут на TypeScript/JavaScript, Python, Java или .NET.

Отличия от Selenium: встроенное авто-ожидание элементов, изоляция тестов через контексты, поддержка emulation мобильных устройств, перехват сети, скриншоты/видео/трассы без плагинов, более быстрый запуск.

Из практики: на новых проектах для веб-автотестов чаще выбирают Playwright — он стабильнее и удобнее. Selenium остаётся в энтерпрайз-проектах с историей и где нужна совместимость со старым WebDriver-сервером.

Стандартный проект содержит playwright.config.ts в корне, папку tests/ с тестовыми файлами *.spec.ts, опционально playwright/.auth для сохранённых сессий и фикстуры.

playwright.config.ts задаёт глобальные настройки: testDir, timeout, expect.timeout, retries, projects (наборы запуска по браузерам), reporters, baseURL, use (общие настройки: viewport, headless, video, screenshot, trace).

Из практики: для разных окружений (dev/stage/prod) удобно через переменные окружения подменять baseURL. Под каждый тип запуска (smoke/regress) делают отдельный project с своим testMatch.

page.locator() — основной способ. Внутри можно использовать CSS, XPath, тексты, role. Также есть удобные ярлыки: getByRole, getByText, getByLabel, getByPlaceholder, getByTestId.

Официальная рекомендация: getByRole и getByText. Они отражают то, как пользователь видит интерфейс, и устойчивы к изменениям разметки. getByTestId — компромисс, когда роли недостаточны.

Из практики: если разработчики аккуратно расставляют data-testid, локаторы получаются стабильными и понятными. CSS и XPath остаются для редких случаев, где роль не подходит.

Перед выполнением каждого действия (click, fill, check) Playwright автоматически ждёт, пока элемент станет видимым, стабильным (без анимации), включённым и пригодным к действию.

Если за timeout (по умолчанию 30 с) условия не выполнены — тест падает с понятной ошибкой. Это резко уменьшает количество явных waitFor в коде.

Из практики: благодаря авто-ожиданию большинство тестов не требует ручных пауз. Если всё-таки нужно — есть locator.waitFor({ state: 'visible' | 'hidden' | 'attached' | 'detached' }).

У expect(locator) есть ретраящиеся проверки: toBeVisible, toBeEnabled, toHaveText, toHaveValue, toHaveCount, toContainText, toHaveAttribute, toHaveURL, toHaveTitle и другие.

Они автоматически повторяются до выполнения условия или истечения таймаута. Это устраняет необходимость в ручных retry-обёртках.

Из практики: всегда предпочитайте ретраящиеся ассерты над «expect(await locator.textContent()).toBe(...)» — последний делает снимок один раз и часто моргает на медленной отрисовке.

Fixture — это переиспользуемое окружение, которое автоматически создаётся для тестов: страница, авторизованный пользователь, тестовые данные. В Playwright фикстуры объявляют через test.extend.

Каждая фикстура имеет область действия (scope): test (по умолчанию, на тест) или worker (один раз на воркер). Также поддерживается auto: true, чтобы применять без явного запроса.

Из практики: типовые фикстуры — авторизованная страница (loggedInPage), тестовый юзер, базовые данные. Это убирает дублирование beforeEach из тестов.

Trace viewer — это инструмент, показывающий пошаговую трассировку теста: каждое действие, снимок DOM на каждом шаге, сетевые запросы, консоль, источник падения.

Включается в конфиге через use.trace: 'on' | 'retain-on-failure' | 'on-first-retry'. Открывается командой npx playwright show-trace trace.zip.

Из практики: retain-on-failure — самый практичный вариант. Тогда трассу видно для упавших тестов, и почти всегда можно понять, где именно сломалось, без перезапуска.

В playwright.config.ts задаются projects, каждый с use.browserName или device. Стандартно — chromium, firefox, webkit. Запуск npx playwright test пройдёт все project параллельно.

Можно ограничить запуск: npx playwright test --project=chromium. Под мобильные устройства используются предустановленные device-профили: { ...devices['iPhone 13'] }.

Из практики: в CI ставят отдельные джобы на каждый браузер, чтобы видеть результаты раздельно. Для smoke-наборов часто достаточно одного chromium.

Через storageState: один раз логинятся в global setup, сохраняют состояние (cookies, localStorage) в файл методом context.storageState({ path: 'auth.json' }), а в use.storageState указывают путь к этому файлу.

Все тесты будут стартовать сразу авторизованными, без повторного логина. Можно иметь несколько storageState для разных ролей.

Из практики: даёт большое ускорение прогона. Глобальный setup — это отдельный «тест» (globalSetup), который не отображается в отчёте.

Browser context — это изолированный «профиль» внутри одного браузерного процесса. У каждого свои cookies, localStorage, кеш, разрешения. По сути — лёгкое подобие отдельного браузера.

В Playwright по умолчанию каждый тест получает новый context, что гарантирует чистое состояние без перезапуска браузера. Это и обеспечивает изоляцию, и быстро.

Из практики: чтобы создать «второго пользователя» в том же тесте, открывают новый context через browser.newContext() и в нём page.

page.route(url, handler) перехватывает запросы по шаблону URL. В handler можно: route.continue() — пропустить как есть, route.fulfill({ status, body }) — ответить заранее заданным, route.abort() — отменить.

Это удобно для моков API, эмуляции ошибок (5xx, таймауты), тестирования пограничных сценариев без поднятого бэкенда.

Из практики: для unit-подобных тестов фронта — fulfill. Для проверки реальной интеграции — continue с проверкой запроса. Для отказоустойчивости — abort.

В Playwright есть набор предустановленных профилей в devices: import { devices } from '@playwright/test'. Передают как ...devices['iPhone 13'] в use конкретного project.

Это задаёт viewport, userAgent, deviceScaleFactor, isMobile, hasTouch и другое. Получается полноценный эмулированный мобильный браузер.

Из практики: для проверки адаптива и mobile-only сценариев. Это не замена тестов на реальных устройствах — они нужны для проверки поведения железа и нативных компонентов.

В конфиге use можно задать screenshot: 'only-on-failure' | 'on' | 'off' и video: 'retain-on-failure' | 'on' | 'off'. Артефакты попадают в test-results.

В коде вручную: page.screenshot({ path: 'shot.png', fullPage: true }) и expect(page).toHaveScreenshot('homepage.png') для визуального сравнения.

Из практики: only-on-failure / retain-on-failure — оптимальный баланс между отладочной информацией и размером артефактов. Полные скриншоты страниц помогают в репортах.

У Playwright есть APIRequestContext (request fixture). Делает HTTP-запросы напрямую: const res = await request.post('/api/login', { data: {...} }).

Удобно соединять с UI-тестами: подготовить данные через API, потом проверить интерфейс. Также можно писать чистые API-тесты в том же проекте, что и UI.

Из практики: подготовка тестовых данных через API сильно ускоряет тесты — не нужно прокликивать формы. Также удобно для smoke API в одном репозитории.

Retries — это количество повторов упавшего теста перед окончательным фейлом. Задаётся в конфиге: retries: 2 — будет до трёх попыток.

Тест, упавший один раз и прошедший после повтора, помечается flaky. В отчёте видно общее количество flaky — это сигнал, что в тестах есть нестабильность, которую стоит чинить.

Из практики: retries полезны в CI для смягчения сетевых дёрганий. Локально часто оставляют 0, чтобы видеть проблему сразу. Постоянные flaky — это технический долг, а не повод увеличивать retries.

Playwright codegen — это инструмент, который записывает действия в браузере и генерирует код теста. Запускается npx playwright codegen https://example.com.

Удобно для быстрого старта: открыть страницу, поклацать, получить готовый скрипт. Locators codegen старается выбирать осознанно (getByRole, getByText).

Из практики: используют для черновика теста, который потом доводят руками. Слепое использование codegen даёт фрагильные тесты, поэтому полученный код всегда стоит переписать в стиле проекта.

POM — это класс на страницу с локаторами в конструкторе и методами действий: class LoginPage { readonly emailInput; constructor(page) { this.emailInput = page.getByLabel('Email'); } async login(email, password) {...} }.

В тестах: const loginPage = new LoginPage(page); await loginPage.login(...). Это убирает дублирование, делает рефакторинг безопасным и читаемым.

Из практики: страницы со сложной логикой выносят в POM. Для простых форм иногда хватает функций. Большинство команд использует гибрид: POM для основных экранов плюс утилитные функции.

Самый простой способ — обычный цикл for/forEach по массиву данных, создающий test() для каждого случая: for (const tc of cases) test(`login ${tc.name}`, async ({ page }) => { ... }).

Также можно сделать собственную фикстуру test.extend, принимающую параметры через test.use({...}).

Из практики: для проверки одной логики на разных данных — for-цикл с информативным именем. Не используйте динамический test внутри test — это запрещено.

globalSetup — это файл с функцией, запускающейся один раз перед всеми тестами (после загрузки конфига). Подходит для общей подготовки: логин, прогрев кеша, миграции, создание тестовых пользователей.

globalTeardown — симметрично, после всех тестов. Часто чистит созданные ресурсы.

Из практики: типичный сценарий — globalSetup логинится и сохраняет storageState. Тесты потом стартуют уже авторизованными. Также сюда удобно класть seed данных через API.

Playwright прозрачно проходит через open shadow DOM при использовании getByRole, getByText и текстовых селекторов. Для CSS-цепочек тоже работает, в отличие от классического Selenium.

Если shadow root закрытый, доступ из JS невозможен — поможет только evaluate с прямым доступом к компонентам.

Из практики: большинство Web Components с открытым shadow DOM тестируется без специальных приёмов. Главное — выбирать локаторы по ролям и текстам, а не по сложным CSS.

Получают FrameLocator: page.frameLocator('iframe[name="checkout"]'). Далее frame.locator(...) ведёт себя как обычный page.locator, но внутри указанного iframe.

Альтернатива — page.frame({ name: 'checkout' }) возвращает объект Frame с тем же API, что у Page.

Из практики: для платёжных виджетов, чатов, embed-форм iframe — обычная история. FrameLocator + getByRole внутри даёт стабильные тесты.

Загрузка: page.locator('input[type="file"]').setInputFiles('path/to/file.pdf') — поддерживает массив для нескольких файлов и Buffer для контента в памяти.

Скачивание: const downloadPromise = page.waitForEvent('download'); await page.click('text=Download'); const download = await downloadPromise; await download.saveAs('out.pdf');

Из практики: для setInputFiles не нужно симулировать клик по input — Playwright под капотом работает с DOM API. Для нестандартных drag-and-drop загрузчиков может понадобиться DataTransfer вручную.

Встроенные: list (живой вывод в консоль), line (компактный), dot (точки), json, junit, html (интерактивный отчёт со скриншотами и трассами). Можно подключать несколько одновременно.

В конфиге: reporter: [['list'], ['html', { open: 'never' }]]. Открыть HTML-отчёт: npx playwright show-report.

Из практики: list/line — для локального запуска. html — для разбора падений (его сохраняют в CI как артефакт). junit — для интеграции с системами вроде GitLab CI / Jenkins.

Стандартный рецепт: установить зависимости (npm ci), установить браузеры (npx playwright install --with-deps), запустить тесты (npx playwright test), загрузить html-отчёт и trace как артефакты.

Отдельный GitHub-action не нужен — актуальный гайд Playwright рекомендует именно npm ci + npx playwright install --with-deps (старый microsoft/playwright-github-action заброшен). Как альтернатива — официальный Docker-образ mcr.microsoft.com/playwright, где браузеры и системные зависимости уже предустановлены.

Из практики: с Docker-образом сборка кешируется, а с install --with-deps на чистом раннере нужно дождаться установки системных зависимостей. В CI обычно включают video: retain-on-failure и trace: retain-on-failure.

Sharding — это разделение тестов на несколько частей (shard) и параллельный прогон каждой части на отдельной машине/контейнере. Запуск: npx playwright test --shard=1/4.

Playwright сам делит тесты примерно поровну. После прогона можно объединить отчёты blob-репортов в один общий HTML-отчёт.

Из практики: даёт почти линейное ускорение прогона больших наборов. В GitHub Actions удобно через матрицу: shard 1..N как отдельные джобы, потом merge-отчётов в финальной.

В playwright.config.ts use.baseURL = 'http://localhost:3000' задаёт корневой адрес. После этого page.goto('/login') автоматически добавит baseURL.

Это позволяет менять окружение через env-переменную без правки тестов.

Из практики: всегда настраивайте baseURL — тесты становятся переносимыми между dev/staging/prod.

В Playwright диалоги обрабатываются через event dialog: page.on('dialog', async dialog => { await dialog.accept(); }). Регистрируют до действия, вызывающего диалог.

Можно прочитать тип (dialog.type()), сообщение (dialog.message()), значение по умолчанию (dialog.defaultValue()).

Из практики: для confirm нужно решить — accept или dismiss. Для prompt можно передать ввод: dialog.accept('значение').

waitForResponse(url) ждёт, пока сервер вернёт ответ на URL, соответствующий шаблону. Полезно при асинхронных действиях, где результат приходит не сразу.

waitForRequest симметрично ждёт отправки запроса. Применяется реже — обычно интересует именно ответ.

Из практики: используйте, когда UI обновляется после API-вызова — дожидайтесь конкретного response, не sleep.

Новое окно открывается через context.waitForEvent('page'): const newPagePromise = context.waitForEvent('page'); await page.click('a[target=_blank]'); const newPage = await newPagePromise.

После этого newPage — обычный Page, с которым можно работать как с основным.

Из практики: типовой сценарий — попап с OAuth, новая вкладка с условиями. Важно не забыть закрыть после теста.

test.step('название', async () => { ... }) — группирует действия в логический шаг. В Trace Viewer и HTML-отчёте они видны как отдельные шаги.

Полезно для длинных сценариев — отчёт становится самодокументируемым.

Из практики: BDD-стиль тестов через step делает их понятными даже не-инженерам, которые читают отчёт.

Если поле — обычный input[type=date], то fill('2025-01-15'). Если кастомный — кликают по календарю как обычно, через getByRole/getByText('15').

Также можно установить значение напрямую через evaluate: page.locator('#date').evaluate(el => el.value = '2025-01-15').

Из практики: предпочтительно через UI — это ближе к пользовательскому пути. Прямой ввод — для ускорения, когда календарь сложный.

expect(page).toHaveScreenshot('home.png') сравнивает текущий скриншот с эталонным (хранится рядом с тестом). При первом запуске эталон создаётся.

Можно задать threshold (порог совпадения) и mask (зоны, исключаемые из сравнения — например, дата/счётчик).

Из практики: визуальные тесты ловят регрессии вёрстки. Но они хрупкие — шрифты, анимации, рендеринг отличаются между ОС. Эталоны нужно хранить под каждую ОС или замораживать рендеринг.

В конфиге: timeout (общий на тест), expect.timeout (на ассерты), use.actionTimeout, use.navigationTimeout. По умолчанию — 30 секунд на тест, 5 секунд на ассерт.

В коде можно переопределить: test.setTimeout(60000), expect(...).toHaveText('x', { timeout: 10000 }).

Из практики: не повышайте таймауты, чтобы скрыть проблемы. Сначала разберитесь, почему действие медленное.

В конфиге: workers: 4 — четыре теста параллельно. По умолчанию Playwright берёт примерно половину логических ядер CPU. В CI часто фиксируют workers: 1 или 2 для стабильности.

Параллелизация — на уровне тестов (файлов); внутри одного теста всё последовательно.

Из практики: больше workers — быстрее прогон, но больше нагрузки на тестовую среду. Найдите баланс — где БД/сервер не упирается.

test.skip — пропустить тест безусловно. test.fixme — то же, но семантически означает «тест нерабочий, нужно починить».

В отчётах различимы. Помогает командам отслеживать, какие тесты сейчас не работают и почему.

Из практики: всегда добавляйте комментарий с причиной и тикетом. Без него быстро забывают, почему пропустили.

Allure — фреймворк для красивых отчётов автотестов. Интегрируется с JUnit, TestNG, pytest, Cypress, Playwright и многими другими.

Фичи: шаги теста, скриншоты, видео, attachments, история, trend по запускам, разбивка по features/epics.

Из практики: для команды, регулярно смотрящей отчёты, Allure сильно удобнее, чем встроенные HTML-репортеры.