Кто обычно настраивает обработку создания объекта на сервере

Что проверяют

Понимаете ли вы, где проходит граница между ролями и что вообще происходит на сервере при создании сущности. Формулировка расплывчатая намеренно: интервьюер смотрит, сведёте ли вы ответ к конкретике. Следом обычно звучит: «Хорошо, а как вы это протестируете?»

Как отвечать

Логику создания объекта пишет бэкенд-разработчик: обработчик POST-запроса, валидацию, запись в базу, формирование ответа. Опирается он на требования аналитика и контракт API, чаще всего это спецификация OpenAPI. Сервер, базу, переменные окружения и пайплайн выкладки готовят DevOps-инженеры, но саму обработку они не пишут.

Роль QA здесь проверочная, и её стоит раскрыть подробно:

• успешное создание: код 201 Created, в теле созданный объект с идентификатором, при необходимости заголовок Location. Запись действительно появилась в базе, это видно по SQL-запросу;
• валидация: пустые и слишком длинные поля, неверные типы, лишние поля. Ожидаем 400 или 422 с понятным сообщением, а не 500;
• дубли: повторное создание уникальной сущности даёт 409, двойной клик по кнопке не создаёт две записи;
• доступ: без токена 401, без прав 403;
• побочные эффекты: письмо, событие в очередь, запись в аудит.

Инструменты: Postman или Insomnia для ручных проверок, в автотестах REST Assured, pytest с requests или аналог на стеке команды.

Бывает, что настраивает как раз тестировщик: если бэкенд ещё не готов, QA поднимает заглушку в WireMock или mock-сервере Postman и описывает, что она отвечает на POST. Упомяните это, если такой опыт был.

Где спотыкаются

Перечисляют всех подряд: разработчиков, админов, DevOps, QA. Ответ «все понемногу» не показывает понимания, кто за что отвечает.

Проверяют только ответ API и не заглядывают в базу. Сервер может вернуть 201 и ничего не сохранить.

Забывают про негативные сценарии и повторные запросы, хотя именно там живут самые частые баги создания.