Как анализировать ошибки от сервера?

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

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

Как отвечать

Опишите порядок действий:

• зафиксировать факт: код ответа, тело с текстом ошибки, идентификатор запроса из заголовков, точное время с часовым поясом, окружение и версия сборки. Этого достаточно, чтобы разработчик нашёл запрос в логах;
• понять класс ошибки: 4xx означает проблему в запросе (не тот формат, отсутствующий заголовок, нет прав, объекта не существует), 5xx означает проблему на сервере. Отдельно проверяется случай, когда сервер отвечает 200 с ошибкой в теле;
• воспроизвести: повторить запрос через curl или Postman ровно с теми же заголовками и телом. Если не воспроизводится, значит дело в клиенте или в состоянии данных, и это уже полезный вывод;
• сузить: другой пользователь, другое окружение, другие данные, повтор через минуту. Так отделяется постоянный дефект от разового сбоя;
• посмотреть логи и трассировку по идентификатору запроса, а если доступа нет, приложить его в отчёт;
• проверить смежное: не выкатывали ли релиз, не отвечает ли внешний сервис, не кончилось ли место, не истёк ли токен интеграции.

Хороший отчёт содержит шаги, ожидаемое и фактическое поведение, идентификатор запроса, время, окружение и приложенные ответ сервера с логом. Отдельно стоит сказать, что повторяющиеся 5xx это всегда дефект, даже если сценарий редкий.

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

Приносят скриншот с текстом «ошибка сервера» без времени и идентификатора.

Заводят дефект на 401 после истечения сессии, не проверив, что это ожидаемое поведение.

Останавливаются на симптоме и не пробуют воспроизвести через прямой запрос, из-за чего дефект возвращается как «не воспроизводится».