Manual QA

API вручну

REST, Postman, Swagger

Що таке REST API і що ти перевіряєш в API-тестуванні?

REST — архітектурний стиль: ресурси за URL, стандартні HTTP-методи, відповідь зазвичай у JSON, сервер не тримає стан між запитами.

Що перевіряю:

Статус-код і тіло відповіді: поля, типи, значення.
Заголовки: Content-Type, кешування, CORS.
Негативні кейси: невалідні дані, відсутні поля, неправильні типи, 401/403/404.
Бізнес-логіку: дані справді змінилися в системі (GET після POST, перевірка в БД).
Час відповіді.

На співбесіді: REST — це підхід, де ресурси мають свої адреси, а дії виконуються стандартними HTTP-методами. Я перевіряю статус-коди, структуру й значення відповіді, заголовки, негативні кейси з невалідними даними й без авторизації, і що зміна справді відбулася — через наступний GET або в базі.

Як ти працюєш у Postman?

Колекції — запити, згруповані за функціональністю.
Environments — змінні для dev, staging, prod: {{baseUrl}}, {{token}}.
Pre-request scripts — отримати токен, згенерувати дані.
Tests — асерти на статус і тіло, збереження значень у змінні для наступних запитів.
Collection Runner / Newman — запуск колекції цілком, Newman — з CLI в CI.

// вкладка Tests у Postman
pm.test("Статус 201", () => pm.response.to.have.status(201));

const body = pm.response.json();
pm.test("Сума збережена", () => pm.expect(body.amount).to.eql(100.50));

pm.environment.set("transferId", body.id);   // для наступного запиту

На співбесіді: У Postman я збираю запити в колекції, виношу адреси й токени в змінні оточення, у pre-request скриптах отримую токен, а у вкладці Tests пишу перевірки й зберігаю значення, наприклад ID, для наступних запитів. Колекцію можна прогнати через Runner або Newman у CI.

Що таке Swagger і як ти його використовуєш?

Swagger (OpenAPI) — специфікація API: ендпоінти, параметри, схеми запитів і відповідей, коди помилок. Swagger UI дозволяє відправляти запити прямо з браузера.

Як QA використовую: як джерело вимог до API, для швидкої перевірки ендпоінта, для пошуку розбіжностей між документацією і реальною поведінкою — це теж баги. Специфікацію можна імпортувати в Postman.

На співбесіді: Swagger — це документація API у форматі OpenAPI з можливістю відправляти запити з браузера. Я використовую його як вимоги до API, для швидких перевірок і шукаю розбіжності між документацією та реальною поведінкою. А ще імпортую специфікацію в Postman, щоб не створювати запити вручну.

Що таке ідемпотентність і навіщо її тестувати?

Операція ідемпотентна, якщо повторний виклик дає той самий результат, що й перший. GET, PUT, DELETE — ідемпотентні; POST — ні: два POST створять два записи.

Тестую: повторну відправку того самого запиту (подвійний клік, ретрай після таймауту) — система не повинна створити дубль.

На співбесіді: Ідемпотентна операція при повторі дає той самий результат. GET, PUT і DELETE ідемпотентні, а POST — ні. Я перевіряю, що повторний запит, наприклад після подвійного кліку чи ретраю після таймауту, не створює дубль.

Як тестувати автентифікацію і авторизацію в API?

Запит без токена → 401.
З простроченим або підробленим токеном → 401.
З валідним токеном, але без прав (звичайний користувач на адмін-ендпоінт) → 403.
Доступ до чужих даних: користувач A запитує ресурс користувача B за ID → 403 або 404. Це вразливість IDOR, одна з найчастіших.
Токен після logout більше не працює.

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