Как оформлять задачу при ошибке со стороны бэка?

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

Умеете ли вы сначала доказать, что ошибка именно на бэкенде, и оформить её так, чтобы разработчик воспроизвёл проблему без переписки с вами. Следом спрашивают, как вы отличаете баг бэка от бага фронта и что приложите к задаче.

Как отвечать

Сначала локализация. Откройте вкладку Network в DevTools: если API вернул 500, неверные данные или нарушил контракт, это бэк. Если ответ правильный, а экран показывает не то, это фронт. Для уверенности повторите запрос через Postman или curl, минуя интерфейс, и поищите дубликаты в трекере.

Состав задачи:

• заголовок: где, что и при каком условии, например «POST /api/orders отвечает 500 при пустом поле comment»;
• окружение: стенд, версия сборки или коммит, имя сервиса;
• запрос: метод, URL, значимые заголовки, тело. Удобно приложить команду через «Copy as cURL» из DevTools, убрав токены и персональные данные;
• ответ: код статуса, тело, время запроса с часовым поясом;
• идентификатор трассировки: X-Request-ID или traceId из ответа, по нему разработчик быстро найдёт логи в Kibana или Grafana Loki и трейс в Jaeger;
• ожидаемый результат: со ссылкой на спецификацию OpenAPI или требование в задаче, а не «должно работать»;
• фактический результат и стабильность воспроизведения: всегда или один раз из десяти;
• тестовые данные: ID пользователя, заказа, предусловия в базе;
• серьёзность и приоритет: блокирует ли сценарий, есть ли обходной путь.

Один баг, одна задача. Если ошибок несколько, заведите отдельные и свяжите их.

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

Прикладывают только скриншот интерфейса с надписью «ошибка». Разработчику придётся самому искать запрос, стенд и время, и задача вернётся с вопросами.

Копируют cURL целиком вместе с Authorization и cookie. Токен из задачи видят все, у кого есть доступ к трекеру.

Пишут в ожидаемом результате «код 200», хотя для невалидных данных контракт требует 400 с описанием ошибки. Ожидаемое поведение берут из спецификации, а не из догадки.