Middle QA Automation — питання на співбесіді QA Automation

У чому різниця між implicit, explicit і fluent wait?

Implicit wait — глобальне налаштування, через яке будь-який пошук елемента повторюється до N секунд. Explicit wait чекає одну конкретну умову — елемент клікабельний, текст зʼявився — і тільки її. Fluent wait це explicit з налаштовуваним інтервалом опитування та списком ігнорованих винятків. Змішування implicit і explicit дає непередбачувані сумарні таймаути, тому більшість команд повністю вимикають implicit і використовують explicit.

Які локатори ви використовуєте і чому XPath часто вважають поганою практикою?

Бажаний порядок: спеціальний тестовий атрибут на кшталт data-testid, потім id, потім стабільний CSS-селектор. У XPath погана репутація через абсолютні шляхи, які ламаються від будь-якої зміни DOM, і довгі відносні вирази, які важко читати. Сам по собі XPath нормальний і подекуди незамінний — наприклад пошук за видимим текстом або перехід до батьківського елемента — проблема в крихких XPath, а не в мові.

Що таке flaky-тест? Назвіть причини та способи усунення.

Flaky-тест падає і проходить без змін у коді. Звичні причини: припущення про час (жорсткі sleep замість очікування умови), спільні змінювані тестові дані, залежність від порядку запуску, анімації, нестабільні оточення та сторонні сервіси. Лікування: чекати явні умови, генерувати ізольовані дані під кожен тест, робити тести незалежними та ідемпотентними, мокати зовнішні сервіси і виносити нестабільні тести в карантин замість перезапусків до зеленого.

Як організувати паралельний запуск тестів? Які проблеми виникають?

Паралельність налаштовується на рівні раннера і зазвичай поєднується з Selenium Grid або контейнерами. Проблеми повʼязані зі спільним станом: тести пишуть в один акаунт або одні рядки БД, конфліктують за портами й файлами, покладаються на порядок виконання. Рішення в тому, що кожен тест створює свої дані з унікальними ідентифікаторами, не чіпає глобальні ресурси в setup і ніколи не припускає, що працює сам.

Чим Playwright відрізняється від Selenium? Коли обрати кожен?

Playwright спілкується з браузером по DevTools-протоколу, автоматично чекає готовності елемента і з коробки дає трейсинг, перехоплення мережі та ізоляцію для паралельного запуску — тому очікувань у коді майже не потрібно. Selenium — стандарт W3C з найширшою підтримкою браузерів, мов і гріда, глибоко вкорінений у корпоративній інфраструктурі. Playwright беруть для нового проєкту під сучасні браузери, Selenium — коли потрібна підтримка легасі або вбудуватись в наявну екосистему.

Як ви тестуєте REST API? Які інструменти використовуєте?

Перевіряють статус-коди, схему відповіді, значення в тілі, заголовки, обробку невалідного вводу, а також межі автентифікації й авторизації. Інструменти — Postman або Insomnia для розвідки та RestAssured, Playwright APIRequest, requests чи supertest для автотестів. API-тести дешевші й набагато стабільніші за UI-тести, тому основне покриття має жити саме там.

Що таке тестова піраміда? Яке співвідношення unit/integration/e2e оптимальне?

Піраміда каже, що потрібно багато швидких unit-тестів, менше інтеграційних і зовсім небагато end-to-end, бо вгору зростають і вартість, і нестабільність. Часто називають пропорцію приблизно 70/20/10, але важливіша не цифра, а принцип: опускати кожну перевірку на найнижчий рівень, де вона здатна зловити баг. E2E мають покривати лише критичні користувацькі сценарії, а не бізнес-логіку.

Як інтегрувати автотести в CI/CD pipeline?

Тести запускаються на кожен pull request, зазвичай розділені на швидкий smoke на кожен коміт і повну регресію на мерж або вночі. Пайплайн піднімає чисте оточення, ганяє набори паралельно, публікує звіти та артефакти на кшталт скриншотів і трейсів, і валить збірку при регресії. Працює це лише за правила, що червоний пайплайн блокує мерж — інакше набір тестів деградує.

Що таке data-driven testing і як його реалізувати?

Data-driven розділяє логіку тесту і дані, тому один тест проганяється на множині наборів з CSV, JSON або параметризованого провайдера. Це множить покриття без множення коду і перетворює додавання кейса на правку даних, а не коду. Підступ у нечитабельних падіннях — завжди підставляйте вхідні дані в імʼя тесту, щоб зі звіту було видно, який саме кейс зламався.

Що варто автоматизувати, а що ні?

Автоматизують стабільні, повторювані та цінні перевірки: регресію, smoke, контракти API і сценарії з великим обсягом даних. Не автоматизують швидкозмінний UI, разові перевірки, дослідницьке тестування, оцінку зручності та зовнішнього вигляду, а також усе, де написання й підтримка тесту дорожчі за ручний прогін. Вирішальне питання — скільки разів перевірка відпрацює до того, як зміниться.