Як підготуватись до технічного інтерв'ю QA: реальні питання і відповіді 2026

Ця стаття — підготовка до реального технічного інтерв'ю. Не академічні визначення, а питання які реально задають в 2025-2026, і відповіді які реально очікують.

Структура типового QA інтерв'ю

Більшість технічних інтерв'ю для QA складаються з:

1. Теорія тестування (20-30%) — рівні, типи, техніки тест-дизайну
2. Практика тест-кейсів (20-30%) — написати тест-кейси для конкретної задачі
3. API тестування (20-25%) — HTTP, Postman, REST
4. SQL (10-15%) — написати запити
5. Автоматизація (10-20%, залежно від позиції)

Блок 1: Теорія тестування

"Чим відрізняється smoke від regression тестування?"

Smoke тестування — швидка перевірка що основна функціональність не зламана після деплою. 15-30 критичних тест-кейсів. Мета: вирішити чи варто продовжувати тестування взагалі.

Regression тестування — перевірка що нові зміни не зламали існуючу функціональність. Повне або вибіркове повторення тестів.

Ключова різниця: smoke — "чи живий продукт?", regression — "чи не зламали нову фічею старе?"

"Розкажіть про техніки тест-дизайну. Яку б ви застосували для форми реєстрації?"

Основні техніки:

Еквівалентне розбиття (Equivalence Partitioning): розбиваємо значення на класи еквівалентності. Для поля email: валідні (test@example.com), невалідні без @, невалідні без домену, порожнє.

Аналіз граничних значень (Boundary Value Analysis): тестуємо граничні точки. Для поля "вік (18-99)": 17, 18, 19, 98, 99, 100.

Таблиця рішень (Decision Table): для комбінацій умов. Форма реєстрації: email заповнено/ні × пароль відповідає вимогам/ні × підтвердження паролю збігається/ні.

Для форми реєстрації я б застосував усі три:

• Equivalence partitioning для кожного поля
• Boundary values для числових полів і обмежень довжини
• Decision table для комбінацій валідних/невалідних полів

"Що таке severity і priority? Чим відрізняються?"

Severity — наскільки серйозний баг технічно. Визначає QA.

• Critical: додаток крашить, дані втрачаються
• High: важлива функція не працює
• Medium: функція працює неправильно, є workaround
• Low: візуальний баг, незручність

Priority — наскільки важливо виправити зараз. Визначає product.

• P1: виправити негайно
• P2: виправити в наступному релізі
• P3: виправити коли є час

Приклад де вони не збігаються: опечатка в назві компанії на сайті — Severity Low (ніщо не ламається), Priority High (репутаційний ризик, виправити до завтра).

Блок 2: Практика тест-кейсів

"Напишіть тест-кейси для кнопки 'Лайк' в соцмережі"

Типове практичне завдання. Хороша відповідь покриває:

Позитивні сценарії:

• Авторизований user натискає Like → кількість лайків збільшується на 1
• Повторне натискання → лайк знімається, кількість зменшується
• Лайк відображається як активний для user який лайкнув
• Оновлення кількості видно іншим users

Негативні сценарії:

• Неавторизований user натискає Like → redirect на логін або підказка авторизуватись
• Лайк на власний пост (якщо заборонено) → помилка або кнопка недоступна

Edge cases:

• Швидке подвійне натискання → не повинно додати 2 лайки
• Лайк при відсутності інтернету → правильна обробка помилки
• Пост видалений поки user лайкав → коректна обробка

Нефункціональні:

• Лайк відображається правильно на мобільному
• Кількість лайків оновлюється без перезавантаження сторінки

Блок 3: API тестування

"Які HTTP методи ви знаєте і для чого вони?"

Бонус-поінт: пояснити що таке ідемпотентність — виклик один або кілька разів дає однаковий результат.

"Які статус-коди потрібно знати?"

2xx — Success:

• 200 OK — стандартна успішна відповідь
• 201 Created — ресурс успішно створений (POST)
• 204 No Content — успішно, але немає тіла відповіді (DELETE)

4xx — Client Error:

• 400 Bad Request — невалідні дані від клієнта
• 401 Unauthorized — потрібна авторизація
• 403 Forbidden — немає прав (авторизований, але не має доступу)
• 404 Not Found — ресурс не знайдено
• 422 Unprocessable Entity — валідаційна помилка

5xx — Server Error:

• 500 Internal Server Error — помилка на сервері
• 503 Service Unavailable — сервіс тимчасово недоступний

Часта помилка: плутати 401 і 403. 401 = "хто ти?", 403 = "я знаю хто ти, але ні".

"Що б ви перевіряли тестуючи POST /api/users?"

Request:
POST /api/users
Body: { "name": "Іван", "email": "ivan@test.com", "role": "user" }

Перевірки:
1. Status code: 201 Created (не 200!)
2. Response body: містить ID нового user
3. Поля відповіді відповідають специфікації
4. Дані збереглись в БД (перевірка GET запитом або SQL)

Негативні сценарії:
5. Порожній email → 400/422 з повідомленням про помилку
6. Дублікат email → 409 Conflict або відповідна помилка
7. Без авторизації → 401
8. Невалідний role → 400/422
9. Дуже довгий рядок у name → обробляється коректно
10. SQL injection в полях → система захищена, не 500

Блок 4: SQL

"Напишіть запит: знайти всіх users, які зареєструвались за останній місяць"

SELECT *
FROM users
WHERE created_at >= NOW() - INTERVAL '1 month'
ORDER BY created_at DESC;

"Знайти users, які ще не зробили жодного замовлення"

SELECT u.id, u.name, u.email
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;

"Знайти топ-5 товарів за кількістю продажів"

SELECT 
  p.name,
  COUNT(oi.id) as total_sold
FROM products p
JOIN order_items oi ON p.id = oi.product_id
GROUP BY p.id, p.name
ORDER BY total_sold DESC
LIMIT 5;

Загальні поради для інтерв'ю

Думайте вголос. Інтерв'юер хоче зрозуміти ваш процес мислення, а не тільки правильну відповідь. Якщо не знаєте — скажіть "я б підійшов так..." і покажіть логіку.

Задавайте уточнюючі питання. "Напишіть тест-кейси для кнопки" — запитайте: для якого девайсу? Які є ролі? Є обмеження на кількість лайків? Це показує аналітичне мислення.

Наводьте приклади з досвіду. "Я тестував схожу функціональність і знайшов цікавий edge case..." — набагато краще ніж теоретична відповідь.

Чесність про незнання. Краще сказати "я з цим не працював, але розумію принцип і вивчу" ніж плутати інтерв'юера.

Чеклист підготовки

• Переписати власноруч визначення рівнів і типів тестування
• Практика тест-кейсів: написати для 5-10 реальних фіч
• HTTP методи і статус-коди — знати напам'ять топ-10
• Зробити 10+ реальних запитів в Postman з assertions
• SQL: написати 10+ запитів з JOIN і GROUP BY
• Підготувати 3-5 прикладів реальних багів/ситуацій з досвіду (або з практики на pet-проекті)

Вдалого інтерв'ю! Пам'ятайте: інтерв'ю — це і ваша оцінка компанії теж. Задавайте питання про процеси, команду і те як вони тестують.