Що ви отримаєте?

Інтерв’юер: … Давайте почнемо з короткої розповіді про ваш досвід у тестуванні, особливо в частині API.

Кандидат: Вітаю! Я працюю в тестуванні понад 1 рік. Займаюся як ручним, так і автоматизованим тестуванням, включно з перевіркою REST API. Працював з такими інструментами, як Postman, Swagger UI, трохи автоматизував запити через Cypress і Newman. Маю досвід тестування авторизації, CRUD-операцій, валідації даних і навантажувального тестування базових сценаріїв.

Інтерв’юер: Чудово.
Тоді перейдемо до деталей. Скажіть, будь ласка, що таке REST і в чому його ключові принципи?

Кандидат: REST — це архітектурний стиль взаємодії між системами через протокол HTTP. Основні принципи — використання стандартних методів HTTP (GET, POST, PUT, DELETE), відсутність збереження стану на сервері (stateless), кешованість відповідей, ієрархічність ресурсів та уніфікований інтерфейс.

Інтерв’юер: Добре. Які коди статусу HTTP вам відомі? Назвіть ті, що найчастіше зустрічаються в тестуванні API.

Кандидат: Найчастіше зустрічаються такі:

• 200 OK — успішний запит,

• 201 Created — успішне створення ресурсу,

• 204 No Content — успішний запит без вмісту,

• 400 Bad Request — помилка на стороні клієнта,

• 401 Unauthorized — відсутність авторизації,

• 403 Forbidden — заборона доступу,

• 404 Not Found — ресурс не знайдено,

• 500 Internal Server Error — помилка на стороні сервера.

Інтерв’юер: Чудове пояснення. Тепер — трохи практики.
Припустимо, у нас є API: POST /users для створення користувача. Які тест-кейси ви б запропонували для цього ендпоінта?

Кандидат: Я б запропонував:

• Позитивний тест: надіслати коректні дані та перевірити статус 201 і правильність створеного об’єкта.

• Негативний тест: надіслати порожнє тіло запиту — очікувати 400.

• Негативний тест: пропустити обов’язкове поле, наприклад email — очікувати 400.

• Перевірка формату email (валідний і невалідний).

• Перевірка довжини полів, наприклад граничні значення імені користувача.

• Спроба створити користувача з уже існуючим email — очікувати помилку або правильну обробку.

• Перевірка відповіді сервера: правильність полів, відсутність зайвих даних.

Інтерв’юер: Чудово! Тепер невелике практичне завдання:

Уявіть, що вам надали специфікацію:

Ендпоінт: POST https://api.test.com/users

Тіло запиту:

Необхідно:

• Написати запит у форматі Postman.

• Які перевірки ви б зробили у відповіді?

Кандидат: Запит у Postman:

• Обираємо метод POST.

• URL: https://api.test.com/users.

• У Headers додаємо Content-Type: application/json.

• У тілі запиту вказуємо JSON (raw).

Перевірки:

• Статус відповіді 201 Created.

• Відповідь містить об’єкт із полями id, name, email.

• Перевірити, що поле email збігається з відправленим.

• Переконатися, що пароль не повертається у відповіді (безпека).

• Перевірити, що id унікальний і має правильний тип (наприклад, integer).

Інтерв’юер: Чудово.
Ще одне питання: чим відрізняється метод PUT від PATCH?

Кандидат: PUT повністю замінює ресурс новими даними. Тобто якщо якесь поле відсутнє у тілі PUT-запиту, воно буде видалено.
PATCH використовується для часткового оновлення: змінюються тільки вказані поля, інші залишаються без змін.

Інтерв’юер: Чудове пояснення.
І ще один практичний сценарій:

Завдання:
Вам надходить відповідь на GET /users/123:

Але очікуване:

• поле email має бути обов’язковим,

• поле role має бути відсутнім за замовчуванням для звичайних користувачів.

Що ви зробите як тестувальник?

Кандидат: Я б створив баг-репорт:

• Вказав би, що поле role повертається некоректно — воно має бути опціональним або відсутнім для звичайного користувача.

• Перевірив би в API-документації, чи правильний формат відповіді.

• Перевірив би створення нового користувача: чи завжди створюється роль за замовчуванням.