Вопросы на интервью по API-тестированию для QA: чего ждать

Собеседования по API-тестированию проверяют две вещи: концептуальные знания HTTP-методов, кодов статуса и auth-флоу, и практическое суждение о том что именно проверять в каждом ответе. Вопросы которые сбивают кандидатов это ситуационные: как полностью протестировать DELETE-эндпоинт, как управлять аутентификацией в тест-сьюте и почему ответ 500 на невалидный ввод сам по себе баг. Каждый вопрос ниже включает что именно проверяет интервьюер и ответ демонстрирующий практический опыт, а не просто определения.

Базовые вопросы

1. «Что такое API-тестирование и почему оно важно?»

Сильный ответ

2. «Какая разница между API-тестированием и UI-тестированием?»

| | API-тестирование | UI-тестирование |

|-|-----------------|-----------------|

| Что тестируется | Запрос/ответ, бизнес-логика | UI, визуальные элементы, пользовательские флоу |

| Скорость | Очень высокая (миллисекунды) | Медленнее (секунды, запуск браузера) |

| Стабильность | Высокая, нет изменений DOM | Ниже, UI-селекторы ломаются |

| Покрытие | Бизнес-логика, безопасность, целостность данных | Пользовательский опыт, визуальная корректность |

| Инструменты | Playwright request API, Postman, REST Assured | Playwright, Cypress, Selenium |

Ни один не заменяет другой: они ловят разные баги.

3. «Что вы проверяете в API-тесте?»

Хороший API-тест проверяет:

• Код статуса: 200 там где должен быть 201? Отсутствующий auth-токен возвращает 401?
• Тело ответа: правильные ли поля присутствуют? Верны ли значения?
• Типы данных: age это число или строка? is_active это булево?
• Обязательные поля: отсутствующие или null поля которые должны быть
• Нет утечки чувствительных данных: хеши паролей, внутренние ID, PII которые не должны быть в ответе
• Ответы с ошибками: возвращают ли невалидные запросы полезные сообщения с правильным кодом?
• Производительность: ответ приходит в допустимое время?

4. «Объясните HTTP-методы которые вы используете в API-тестировании»

| Метод | Назначение | Пример |

|-------|-----------|--------|

| GET | Получить данные | Профиль пользователя |

| POST | Создать новый ресурс | Регистрация нового пользователя |

| PUT | Полностью заменить ресурс | Обновить все поля пользователя |

| PATCH | Обновить часть ресурса | Обновить только email пользователя |

| DELETE | Удалить ресурс | Удалить аккаунт пользователя |

5. «Какие коды статуса вы чаще всего проверяете в API-тестировании?»

Вместо перечисления всех кодов дай ответ с точки зрения тестирования:

Вопросы по инструментам и реализации

6. «Как вы тестируете API в Playwright?»

test('POST /users returns 201 with correct body', async ({ request }) => {
  const response = await request.post('https://api.becomeqa.com/users', {
    data: {
      email: 'new_user@test.com',
      password: 'ValidPass1',
      role: 'member',
    },
  });

  expect(response.status()).toBe(201);
  
  const body = await response.json();
  expect(body.id).toBeTruthy();
  expect(body.email).toBe('new_user@test.com');
  expect(body).not.toHaveProperty('password'); // нет пароля в ответе
});

7. «Как вы управляете аутентификацией в API-тестах?»

Структура сильного ответа

let authToken: string;

test.beforeAll(async ({ request }) => {
  const response = await request.post('/api/auth/login', {
    data: { email: 'admin@test.com', password: 'AdminPass1' },
  });
  const body = await response.json();
  authToken = body.token;
});

test('authenticated request works', async ({ request }) => {
  const response = await request.get('/api/users', {
    headers: { Authorization: `Bearer ${authToken}` },
  });
  expect(response.status()).toBe(200);
});

8. «Какая разница между Postman и Playwright для API-тестирования?»

| | Postman | Playwright |

|-|---------|-----------|

| Тип | GUI-инструмент для ручного и скриптованного тестирования | Фреймворк автоматизации на основе кода |

| Для чего хорош | Исследование API, быстрые проверки, моки | Автоматизированные тест-сьюты, CI/CD, E2E + API вместе |

| Порог входа | Низкий | Средний (требует программирования) |

| Интеграция с CI/CD | Возможна (Newman CLI) | Нативная, первоклассная |

| Качество тестового кода | Ограниченное | Полная поддержка TypeScript |

| Отладка | Визуальный просмотр запрос/ответ | Логи, trace viewer |

Ситуационные вопросы

9. «Вы тестируете DELETE-эндпоинт. Что проверяете?»

Полный тест DELETE-эндпоинта должен проверять:

1. Happy path: Удаление ресурса с валидным auth → 204 No Content

2. Ресурс реально удалён: последующий GET → 404

3. Идемпотентность: второй DELETE → 404 (не 500, не 204 снова)

4. Авторизация: удаление без auth → 401

5. Чужой ресурс: удаление чужого ресурса → 403

6. Несуществующий ресурс: удаление того чего никогда не было → 404 (не 500)

test('DELETE /orders/:id full coverage', async ({ request }) => {
  // Создаём заказ для удаления
  const createResp = await request.post('/api/orders', { 
    data: { product_id: 1, quantity: 2 },
    headers: { Authorization: `Bearer ${userToken}` },
  });
  const { id } = await createResp.json();

  // Удаляем
  const deleteResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(deleteResp.status()).toBe(204);

  // Проверяем что исчез
  const getResp = await request.get(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(getResp.status()).toBe(404);

  // Повторное удаление → 404, не падение
  const redoResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(redoResp.status()).toBe(404);
});

10. «Как вы тестируете обработку ошибок в API?»

Чеклист для тестирования:

• Отсутствует обязательное поле → 400/422 с чётким сообщением
• Неверный тип данных (строка там где ожидается число) → 400/422
• Значение вне диапазона → 400/422
• Валидный JSON но нарушение бизнес-логики (дублирование email) → 409
• Некорректный JSON в теле → 400
• Отсутствует заголовок Content-Type → 400 или 415

11. «Что такое контрактное тестирование и когда его применять?»

Контрактное тестирование проверяет что API соответствует согласованному контракту: спецификации того как должны выглядеть запросы и ответы. Инструменты вроде Pact определяют эти контракты между потребителем (фронтенд) и провайдером (бэкенд).

12. «Как вы тестируете пагинацию в API?»

test('pagination returns correct page sizes', async ({ request }) => {
  // Первая страница
  const page1 = await request.get('/api/products?page=1&limit=10');
  const body1 = await page1.json();
  expect(body1.data).toHaveLength(10);
  expect(body1.pagination.current_page).toBe(1);
  expect(body1.pagination.total_pages).toBeTruthy();

  // Вторая страница
  const page2 = await request.get('/api/products?page=2&limit=10');
  const body2 = await page2.json();
  // Другие элементы чем на первой странице
  expect(body2.data[0].id).not.toBe(body1.data[0].id);

  // Последняя страница
  const lastPage = await request.get(`/api/products?page=${body1.pagination.total_pages}&limit=10`);
  const bodyLast = await lastPage.json();
  expect(bodyLast.data.length).toBeGreaterThan(0);
  expect(bodyLast.data.length).toBeLessThanOrEqual(10);

  // За последней страницей
  const overPage = await request.get(`/api/products?page=${body1.pagination.total_pages + 1}&limit=10`);
  expect(overPage.status()).toBe(200); // или 404, зависит от дизайна API
  const bodyOver = await overPage.json();
  expect(bodyOver.data).toHaveLength(0); // или пустой массив
});

Что замечают интервьюеры

Помимо правильных ответов, интервьюеры обращают внимание на: