На співбесіді QA Automation перевіряють знання фреймворків, патернів автоматизації і — насамперед — уміння писати тести, які лишаються зеленими не випадково. Нижче — часті питання з еталонними відповідями.
До кожного питання — еталонна відповідь, з якою можна порівняти свою.
Page Object Model загортає кожну сторінку або компонент у клас, який віддає локатори та високорівневі дії, тому тести описують намір, а не кліки. Він вирішує проблему підтримки: при зміні верстки правиш один page object замість пʼятдесяти тестів. Ще він прибирає дублювання і робить тести читабельними для тих, хто їх не писав.
Implicit wait — глобальне налаштування, через яке будь-який пошук елемента повторюється до N секунд. Explicit wait чекає одну конкретну умову — елемент клікабельний, текст зʼявився — і тільки її. Fluent wait це explicit з налаштовуваним інтервалом опитування та списком ігнорованих винятків. Змішування implicit і explicit дає непередбачувані сумарні таймаути, тому більшість команд повністю вимикають implicit і використовують explicit.
Бажаний порядок: спеціальний тестовий атрибут на кшталт data-testid, потім id, потім стабільний CSS-селектор. У XPath погана репутація через абсолютні шляхи, які ламаються від будь-якої зміни DOM, і довгі відносні вирази, які важко читати. Сам по собі XPath нормальний і подекуди незамінний — наприклад пошук за видимим текстом або перехід до батьківського елемента — проблема в крихких XPath, а не в мові.
Flaky-тест падає і проходить без змін у коді. Звичні причини: припущення про час (жорсткі sleep замість очікування умови), спільні змінювані тестові дані, залежність від порядку запуску, анімації, нестабільні оточення та сторонні сервіси. Лікування: чекати явні умови, генерувати ізольовані дані під кожен тест, робити тести незалежними та ідемпотентними, мокати зовнішні сервіси і виносити нестабільні тести в карантин замість перезапусків до зеленого.
Паралельність налаштовується на рівні раннера і зазвичай поєднується з Selenium Grid або контейнерами. Проблеми повʼязані зі спільним станом: тести пишуть в один акаунт або одні рядки БД, конфліктують за портами й файлами, покладаються на порядок виконання. Рішення в тому, що кожен тест створює свої дані з унікальними ідентифікаторами, не чіпає глобальні ресурси в setup і ніколи не припускає, що працює сам.
Playwright спілкується з браузером по DevTools-протоколу, автоматично чекає готовності елемента і з коробки дає трейсинг, перехоплення мережі та ізоляцію для паралельного запуску — тому очікувань у коді майже не потрібно. Selenium — стандарт W3C з найширшою підтримкою браузерів, мов і гріда, глибоко вкорінений у корпоративній інфраструктурі. Playwright беруть для нового проєкту під сучасні браузери, Selenium — коли потрібна підтримка легасі або вбудуватись в наявну екосистему.
Перевіряють статус-коди, схему відповіді, значення в тілі, заголовки, обробку невалідного вводу, а також межі автентифікації й авторизації. Інструменти — Postman або Insomnia для розвідки та RestAssured, Playwright APIRequest, requests чи supertest для автотестів. API-тести дешевші й набагато стабільніші за UI-тести, тому основне покриття має жити саме там.
Піраміда каже, що потрібно багато швидких unit-тестів, менше інтеграційних і зовсім небагато end-to-end, бо вгору зростають і вартість, і нестабільність. Часто називають пропорцію приблизно 70/20/10, але важливіша не цифра, а принцип: опускати кожну перевірку на найнижчий рівень, де вона здатна зловити баг. E2E мають покривати лише критичні користувацькі сценарії, а не бізнес-логіку.
Тести запускаються на кожен pull request, зазвичай розділені на швидкий smoke на кожен коміт і повну регресію на мерж або вночі. Пайплайн піднімає чисте оточення, ганяє набори паралельно, публікує звіти та артефакти на кшталт скриншотів і трейсів, і валить збірку при регресії. Працює це лише за правила, що червоний пайплайн блокує мерж — інакше набір тестів деградує.
Data-driven розділяє логіку тесту і дані, тому один тест проганяється на множині наборів з CSV, JSON або параметризованого провайдера. Це множить покриття без множення коду і перетворює додавання кейса на правку даних, а не коду. Підступ у нечитабельних падіннях — завжди підставляйте вхідні дані в імʼя тесту, щоб зі звіту було видно, який саме кейс зламався.
Автоматизують стабільні, повторювані та цінні перевірки: регресію, smoke, контракти API і сценарії з великим обсягом даних. Не автоматизують швидкозмінний UI, разові перевірки, дослідницьке тестування, оцінку зручності та зовнішнього вигляду, а також усе, де написання й підтримка тесту дорожчі за ручний прогін. Вирішальне питання — скільки разів перевірка відпрацює до того, як зміниться.
Кожен тест має сам створювати потрібні дані й прибирати за собою, бажано через API або сидинг бази, а не через UI — це швидше й надійніше. Спільні фікстури призводять до залежності від порядку та загадкових падінь. За оточеннями ізоляцію дають контейнери або ефемерні інстанси на кожен прогін; якщо спільне оточення неминуче, усі дані треба позначати унікальним ідентифікатором прогону.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю QA Automation →