Что вы получите?

Интервьюер:
….. Давайте начнем с короткого рассказа о вашем опыте в тестировании, особенно в части 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-документации, правильный ли формат ответа.

• Проверил бы через создание нового пользователя: создаётся ли всегда роль по умолчанию.

• Временно в Postman проверил бы другие ID пользователей для воспроизведения ошибки.