Співбесіда на QA: 18 питань і відповідей для тестувальника

Як зазвичай проходить співбесіда на QA

Формат різниться між компаніями, тож точний перелік етапів краще уточнити в рекрутера. Типова схема: розмова про досвід і процес (як ви працюєте в команді, що таке тест-план, чим smoke відрізняється від регресії), блок питань з теорії та тест-дизайну, практична частина (протестувати форму, знайти баги в описі функції, написати кілька запитів чи тестів) і, для automation-позицій, невелике завдання з коду або розбір вашого коду.

Загальна порада: у відповідях називайте критерій, а не лише дію. «Я перевірив логін» — слабко; «я перевірив логін за класами еквівалентності: валідні дані, порожні поля, надто довгі значення, заблокований акаунт» — сильно. Про загальну структуру підготовки див. також як готуватися до технічної співбесіди.

Тест-дизайн (питання 1–5)

1. 1. Чим відрізняються клас еквівалентності й граничні значення? Клас еквівалентності — група вхідних даних, на яку система має реагувати однаково, тому з кожної групи достатньо взяти представника. Граничні значення — це краї таких груп, де помилки трапляються найчастіше. У глосарії ISTQB обидві техніки описано як техніки тест-дизайну «чорної скриньки». Приклад: поле «вік» приймає 18–65. Класи: менше 18, 18–65, більше 65, не число. Межі: 17, 18, 65, 66.
2. 2. Що таке позитивний і негативний тест? Позитивний підтверджує, що з коректними даними система робить очікуване. Негативний — що з некоректними вона відмовляє передбачувано (повідомлення, код помилки), а не падає чи мовчки зберігає сміття.
3. 3. Smoke, sanity, регресія — у чому різниця? Smoke — дуже швидка перевірка, що збірка взагалі працює і можна тестувати далі. Sanity — вузька перевірка конкретної виправленої чи зміненої функції. Регресія — перевірка, що нова зміна не зламала те, що працювало раніше. На співбесіді корисно додати, що регресію зазвичай автоматизують першою.
4. 4. Як ви пріоритезуєте тести, якщо часу мало? За ризиком: що найбільше вплине на користувача й бізнес (оплата, вхід, збереження даних) і що змінювалося в цьому релізі. Лишаю на потім рідкісні сценарії з малим впливом і чесно повідомляю команду, що не покрито.
5. 5. Що таке тест-кейс і чим він відрізняється від чек-листа? Тест-кейс має передумови, кроки, вхідні дані й очікуваний результат, тому його може виконати будь-хто однаково. Чек-лист — короткий перелік того, що перевірити; він швидший у підготовці й підходить для дослідницького чи частого тестування, але залежить від досвіду виконавця.

Баг-репорти й процес (питання 6–9)

1. 6. З чого складається хороший баг-репорт? Заголовок із суті (що, де), середовище (збірка, браузер/ОС, пристрій), кроки відтворення, фактичний і очікуваний результат, вкладення (скриншот, відео, лог, запит/відповідь). Один баг — один репорт. Глосарій ISTQB визначає дефект-репорт як документ про будь-який недолік у компоненті чи системі.
2. 7. Чим відрізняються severity і priority? Severity — наскільки серйозно баг впливає на систему (падіння, втрата даних, косметика). Priority — як швидко його треба виправити з погляду бізнесу. Дрібна помилка в назві компанії на головній може мати низьку severity, але високий priority.
3. 8. Що робити, якщо баг не відтворюється? Перевірити середовище й дані, спробувати інший браузер чи збірку, зібрати логи, уточнити в автора репорту кроки. Якщо відтворити не вдалося — залишити в статусі з поясненням і описом спроб, а не закривати мовчки.
4. 9. Як ви поводитесь, коли розробник каже «це не баг, а фіча»? Звіряюсь із вимогами або критеріями приймання. Якщо там неоднозначність — виношу питання до власника продукту, а не сперечаюся. Спір вирішують документ і користувацька цінність, а не авторитет.

API-тестування (питання 10–13)

1. 10. Що ви перевіряєте в відповіді API? Код статусу, тіло (структура, типи полів, значення), заголовки (наприклад, Content-Type), час відповіді та поведінку на помилки: 400 для поганого запиту, 401/403 без прав, 404 для відсутнього ресурсу. Окремо — ідемпотентність: повторний PUT чи DELETE не має ламати стан.
2. 11. Чим відрізняються PUT і PATCH? PUT зазвичай замінює ресурс цілком, PATCH змінює лише передані поля. Точну поведінку конкретного API завжди перевіряють у його специфікації.
3. 12. Як написати перевірку у Postman? У вкладці Scripts → Post-response пишуть тести через pm.test, а асерти — через pm.response або pm.expect (Chai). Приклад із документації: pm.test("Status test", function () { pm.response.to.have.status(200); });. Результати видно у Test Results.
4. 13. Як передавати дані між запитами? Через змінні: у скрипті зберігаєте значення (наприклад, токен чи id створеного ресурсу) у змінну середовища чи колекції й підставляєте в наступні запити як {{змінна}}. Для запуску набору запитів по черзі використовують колекції та runner.

Автоматизація (питання 14–18)

1. 14. Що тестувати автоматизовано, а що вручну? Автоматизуйте стабільне й повторюване: регресію, smoke, API-перевірки, дані з багатьма комбінаціями. Вручну лишайте нове, дослідницьке, UX і те, що змінюється щодня. Автоматизувати все — не мета.
2. 15. Як писати стабільні UI-тести у Playwright? Документація радить пріоритизувати видимі користувачеві атрибути (роль, текст) замість CSS чи XPath, що залежать від структури DOM. Використовувати web-first асерти (expect), які чекають виконання умови, а не одноразові перевірки. Locators мають автоочікування, тож штучні паузи (sleep) не потрібні.
3. 16. Що таке ізоляція тестів і чому вона важлива? За Playwright, кожен тест має бути повністю ізольованим і запускатися незалежно. Тоді тести можна виконувати паралельно, а падіння одного не тягне інші. Спільну підготовку виносять у хуки типу beforeEach.
4. 17. Що таке фікстури pytest? Функція, що готує те, що потрібно тесту (дані, з’єднання, клієнт), а тест просить її через аргумент. За документацією, область дії (scope): function (за замовчуванням), class, module, package або session. Код очищення пишуть після yield — він виконується після тесту.
5. 18. Що робити з флейкі-тестом? Не додавати вічні ретраї. Знайти причину: гонки й очікування, залежність від даних чи порядку тестів, нестабільне середовище. Поки не виправлено — ізолювати тест, щоб він не маскував справжні падіння, і завести завдання.

Як готуватися за тиждень

• Візьміть будь-який застосунок (навіть сайт банку чи інтернет-магазин) і складіть для однієї форми класи еквівалентності та межі.
• Напишіть 3 баг-репорти за шаблоном вище й перечитайте їх очима розробника: чи можна відтворити без запитань?
• У Postman зробіть колекцію з 4–5 запитів до відкритого API і додайте до кожного pm.test.
• Напишіть 3 тести у Playwright чи pytest і запустіть їх тричі поспіль: якщо хоч один флейкить — знайдіть чому.
• Пройдіть відповіді вголос: у технічній частині оцінюють, як ви міркуєте, а не лише що кажете.

Якщо співбесіда не рідною мовою або під стресом

Багато QA-позицій в українських і міжнародних командах проводять англійською частково або повністю. Терміни (test case, flaky, regression) варто вміти вимовити вголос; докладніше — технічна співбесіда англійською. Якщо підказки в реальному часі допомагають розібрати питання чи згадати термін, є Interview Copilot — оверлей, що слухає звук дзвінка й показує підказку; є безкоштовний план без картки, а про вікно, невидиме під час показу екрана, читайте на сторінці невидимого помічника. Правила щодо ІІ-підказок визначає компанія: перед живою співбесідою спитайте рекрутера, що дозволено, і не користуйтеся інструментом, якщо це заборонено. Розв’язувати за вас технічну суть він не замінить — на додаткові питання відповідатимете ви.

Джерела

• Playwright — Best Practices: локатори, web-first асерти, ізоляція тестів
• pytest — How to use fixtures: scope, yield-фікстури
• Postman — Test scripts: pm.test, pm.expect, pm.response
• ISTQB Glossary — equivalence partitioning, boundary value analysis, defect report

Перевірено 12.11.2026.

Як тут допомагає застосунок

Схожі статті

Читайте далі