Lesson 1 of 1

Вопросы и ответы для QA Automation Playwright Specialist

Description: 20 вопросов и ответов для Middle и Senior — Playwright, TypeScript, POM, стабильность и CI/CD.

Материал рассчитан на подготовку к техническому интервью. Ответы написаны так, чтобы кандидат не просто запомнил формулировку, а показал понимание Playwright, TypeScript, Page Object Model, стабильности тестов и CI/CD.

Middle QA Automation Playwright Specialist

1. Чем Playwright отличается от Selenium?

Ответ:

Playwright работает ближе к современным браузерным API и из коробки поддерживает Chromium, Firefox и WebKit. В отличие от классического Selenium, он имеет автоожидания, удобную работу с контекстами браузера, встроенную трассировку, видео, скриншоты, network interception и параллельный запуск.

Объяснение:

Главное практическое отличие для QA Automation: в Playwright обычно меньше ручных ожиданий и меньше нестабильных тестов, если правильно использовать локаторы и assertions.

2. Что такое auto-waiting в Playwright?

Ответ:

Auto-waiting означает, что Playwright сам ждёт, пока элемент станет готовым для действия: появится в DOM, станет видимым, стабильным и доступным для клика или ввода.

Объяснение:

Например, перед locator.click() Playwright проверит, что элемент можно кликнуть. Поэтому в хороших тестах не нужно писать waitForTimeout(). Ожидание должно быть связано с реальным состоянием системы: toBeVisible(), toHaveText(), toHaveURL(), toBeEnabled().

3. Почему лучше использовать locator, а не page.$()?

Ответ:

locator ленивый и повторно ищет элемент перед каждым действием. Это делает тесты стабильнее, особенно когда DOM перерисовывается после действий пользователя.

Объяснение:

page.$() возвращает конкретный ElementHandle, который может устареть, если страница обновила DOM. В современных Playwright-тестах предпочтительно использовать page.getByRole(), page.getByText(), page.getByLabel() и page.getByTestId().

4. Что такое Page Object Model и зачем он нужен?

Ответ:

Page Object Model — это подход, где логика работы со страницей или компонентом выносится в отдельный класс. Тест описывает сценарий, а Page Object знает, как найти элементы и выполнить действия.

Объяснение:

Преимущества:

  • тесты становятся читаемыми;
  • селекторы не дублируются в разных тестах;
  • изменения в UI проще исправлять в одном месте;
  • бизнес-сценарий отделяется от технических деталей страницы.

5. Как выбрать хороший селектор в Playwright?

Ответ:

Лучший селектор отражает поведение пользователя, а не внутреннюю структуру HTML. Обычно порядок выбора такой:

  1. getByRole() — если у элемента есть семантическая роль;
  2. getByLabel() — для полей формы;
  3. getByText() — для стабильного текста;
  4. getByTestId() — для элементов без хорошей семантики.

Объяснение:

CSS и XPath лучше использовать только тогда, когда нет более надёжного варианта. Селектор не должен ломаться из-за изменения классов, верстки или порядка элементов.

6. Как проверить, что действие действительно успешно выполнено?

Ответ:

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

Объяснение:

Хороший пример проверки:

tsts
await expect(page.getByRole('heading', { name: 'Dashboard' }))
  .toBeVisible();

Такой assertion показывает реальный итог сценария.

7. Как работать с несколькими вкладками или popup в Playwright?

Ответ:

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

tsts
const pagePromise = context.waitForEvent('page');
await page.getByRole('link', { name: 'Открыть отчёт' }).click();

const reportPage = await pagePromise;
await expect(reportPage).toHaveURL(/report/);

Объяснение:

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

8. Как тестировать загрузку файла?

Ответ:

Для загрузки файла используется setInputFiles(). Обычно файл кладут в тестовые данные проекта и передают путь к нему в input.

tsts
await page
  .getByLabel('Загрузить документ')
  .setInputFiles('tests/fixtures/document.pdf');

Объяснение:

После загрузки нужно проверить результат: имя файла в интерфейсе, успешный toast, появление записи в таблице или корректный API-ответ.

9. Как тестировать скачивание файла?

Ответ:

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

tsts
const downloadPromise = page.waitForEvent('download');
await page.getByRole('button', { name: 'Скачать отчёт' }).click();

const download = await downloadPromise;
expect(download.suggestedFilename()).toContain('report');

Объяснение:

Такой подход стабильнее, чем проверять системную папку загрузок напрямую.

10. Что делать, если тест нестабилен?

Ответ:

Сначала нужно найти причину нестабильности, а не добавлять waitForTimeout(). Обычно проверяют:

  • правильный ли селектор;
  • есть ли ожидание результата после действия;
  • не зависит ли тест от порядка выполнения других тестов;
  • очищаются ли данные перед запуском;
  • нет ли гонки между UI, API и анимациями;
  • что показывает trace viewer.

Объяснение:

Хороший Middle-инженер умеет отличить проблему теста от реального бага приложения и подтверждает вывод логами, trace, скриншотами или network-записями.

Senior QA Automation Playwright Specialist

1. Как бы вы построили архитектуру Playwright-фреймворка?

Ответ:

Я бы разделил проект на понятные слои:

  • tests — сценарии и бизнес-проверки;
  • pages или page-objects — работа со страницами;
  • components — переиспользуемые UI-блоки;
  • fixtures — подготовка контекста, пользователей, API-клиентов;
  • test-data — тестовые данные;
  • utils — небольшие общие функции без бизнес-логики;
  • config — окружения, baseURL, retries, projects.

Объяснение:

Тесты должны читаться как пользовательский сценарий. Детали селекторов, авторизации, подготовки данных и очистки лучше держать вне тестов.

2. Когда использовать UI-тесты, а когда API-тесты?

Ответ:

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

Объяснение:

Senior-подход — не автоматизировать всё через UI. UI-тесты дорогие и более медленные, поэтому их должно быть меньше, но они должны покрывать самые важные пути пользователя. Всё, что можно надёжно проверить ниже уровня UI, лучше проверять API или unit/integration тестами.

3. Как организовать тестовые данные для параллельного запуска?

Ответ:

Каждый тест должен иметь независимые данные. Нельзя полагаться на одного общего пользователя, общий заказ или общую корзину, если тесты запускаются параллельно.

Объяснение:

Практичные подходы:

  • создавать данные через API перед тестом;
  • использовать уникальные email, id или названия;
  • очищать данные после теста, если это нужно;
  • использовать isolated browser context;
  • не делать тесты зависимыми друг от друга.

Если данные дорогие в создании, можно использовать заранее подготовленные фикстуры, но они должны быть read-only или безопасно изолированы.

4. Как работать с авторизацией в больших тестовых наборах?

Ответ:

Лучше не логиниться через UI перед каждым тестом. Обычно делают отдельный setup, который получает авторизованное состояние и сохраняет storageState. Дальше тесты используют это состояние.

Объяснение:

Это ускоряет запуск и уменьшает количество падений из-за нестабильного login flow. При этом сам логин всё равно должен быть покрыт отдельным UI-тестом, потому что это критический пользовательский сценарий.

5. Как вы боретесь с flaky-тестами на уровне процесса?

Ответ:

Нужен не только технический фикс, но и процесс:

  • включить trace, screenshot и video для падений;
  • анализировать повторяемость и условия падения;
  • разделять реальные баги, проблемы окружения и ошибки теста;
  • заводить flaky-тесты как технический долг;
  • не скрывать проблему бесконечными retries;
  • удалять или переписывать тест, если он не даёт доверия.

Объяснение:

Retry может быть временной страховкой в CI, но не заменой исправления причины.

6. Как использовать fixtures в Playwright?

Ответ:

Fixtures позволяют переиспользовать подготовку окружения, данных, страниц и клиентов. Например, можно создать fixture для авторизованного пользователя, API-клиента или Page Object.

Объяснение:

Хорошая fixture имеет понятную ответственность. Она не должна незаметно делать слишком много действий, иначе тесты становятся магическими и сложными для отладки.

7. Как тестировать роли и права доступа?

Ответ:

Нужно покрывать не только наличие кнопок в UI, но и реальное ограничение доступа. Например, пользователь без прав не должен видеть кнопку удаления, но также не должен иметь возможность удалить объект прямым API-запросом.

Объяснение:

Хорошая стратегия:

  • создать пользователей с разными ролями;
  • проверить доступные действия в UI;
  • проверить запреты на уровне API;
  • проверить прямой переход по URL;
  • убедиться, что ошибка понятна пользователю.

Такой подход покрывает и UX, и безопасность.

8. Как настроить Playwright в CI/CD?

Ответ:

В CI/CD важно запускать тесты воспроизводимо:

  • фиксировать версии Node.js и браузеров;
  • устанавливать browsers через npx playwright install --with-deps;
  • запускать тесты параллельно;
  • сохранять trace, screenshots, videos и HTML report как artifacts;
  • разделять smoke, regression и nightly suites;
  • использовать retries осторожно;
  • не хранить секреты в репозитории.

Объяснение:

Для pull request обычно запускают быстрый smoke-набор. Полную регрессию лучше запускать по расписанию или перед релизом.

9. Как проектировать smoke, regression и e2e наборы?

Ответ:

Smoke — это минимальный набор, который быстро отвечает на вопрос: "Система вообще работает?". Он должен быть коротким и стабильным.

Regression шире: он проверяет основные бизнес-функции и сценарии, которые могли сломаться после изменений.

Объяснение:

E2E должен покрывать критические пути пользователя от начала до конца. Но не каждый тест обязан быть длинным e2e-сценарием. Senior-инженер балансирует скорость, стабильность и ценность проверки.

10. Как понять, что автоматизация приносит пользу команде?

Ответ:

Автоматизация полезна, если она быстро даёт команде доверие к релизу и помогает находить проблемы раньше. Метрики могут быть такими:

  • сколько критических сценариев покрыто;
  • сколько времени экономится на ручной регрессии;
  • насколько стабилен CI;
  • сколько багов найдено до релиза;
  • сколько flaky-тестов в наборе;
  • сколько времени команда тратит на поддержку тестов.

Объяснение:

Цель Senior QA Automation не просто писать больше тестов, а строить систему, которой команда доверяет.