На співбесіді QA Automation перевіряють знання фреймворків, патернів автоматизації і — насамперед — уміння писати тести, які лишаються зеленими не випадково. Нижче — часті питання з еталонними відповідями. Junior: базова теорія, визначення та прості практичні кейси.
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 на кожен коміт і повну регресію на мерж або вночі. Пайплайн піднімає чисте оточення, ганяє набори паралельно, публікує звіти та артефакти на кшталт скриншотів і трейсів, і валить збірку при регресії. Працює це лише за правила, що червоний пайплайн блокує мерж — інакше набір тестів деградує.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Junior QA Automation →