Інтерв’юер:
… Ми бачимо у твоєму резюме досвід роботи з Playwright на Python. Розкажи, як ти використовував цей інструмент у проєктах?

Кандидат:
Так, я використовую Playwright з Python для end-to-end тестування вебзастосунків. В одному з проєктів у нас була адмінка з динамічними таблицями та фільтрами, і я автоматизував сценарії з авторизацією, валідацією форм та перевірками даних в UI.
Я використовував pytest як фреймворк, Page Object Model для структурування, і запускав тести в CI через GitHub Actions.

Інтерв’юер:
Як ти організовуєш структуру тестів з використанням Page Object у Playwright?

Кандидат:
Я створюю папку pages, де кожна сторінка — окремий клас з методами, що описують дії над елементами. Наприклад, LoginPage, DashboardPage.
Також є файл locators.py — щоб у разі потреби швидко змінити локатори.
Самі тести розміщуються в папці tests, і кожен файл покриває окремий функціональний модуль.

Інтерв’юер:
Playwright дозволяє працювати з кількома контекстами та браузерами. Ти використовував це?

Кандидат:
Так, використовував. Особливо зручно для паралельного запуску тестів та тестування кількох ролей — наприклад, адміністратор і користувач.
Я створював окремий browser_context і page для кожного користувача в conftest.py і перемикав їх під час тесту. Це зручно та швидко, особливо з async API.

Інтерв’юер:
Розкажи, як ти працюєш з очікуваннями в Playwright? Чи були проблеми з flaky-тестами?

Кандидат:
Переважно я використовую вбудовані очікування, такі як page.locator(...).wait_for() або просто locator().click() — Playwright автоматично чекає появи елемента.
Flaky-тести виникали у випадках, коли змінювався стан елементів, і доводилося додавати перевірки assert element.is_visible() перед дією.
Якщо сторінка перезавантажувалась — використовував expect(page).to_have_url() або to_have_title() перед наступним кроком.

Інтерв’юер:
Як запускаєш тести локально і в CI? Чи використовуєш репортери?

Кандидат:
Локально — через pytest, а в CI (GitHub Actions) — workflow, де тести запускаються в headless-режимі.
Додаю pytest-html або allure для звітів, і в разі падіння тесту зберігаю скріншоти та логи (context.tracing.start() / tracing.stop(path=...)).

Інтерв’юер:
Який найцікавіший баг ти знайшов за допомогою Playwright?

Кандидат:
В одному проєкті ми тестували редагування профілю, і при швидкій послідовності дій (редагувати → зберегти → одразу назад) сервер зберігав порожній профіль.
Я написав тест, який виконував дії з мінімальними очікуваннями — баг відтворювався лише в автоматизованому режимі, вручну його було складно зловити.