Какой HTTP статус код самый проблемный для тестировщика
Что проверяют
Правильного ответа тут нет, интервьюер смотрит на ход мысли: понимаете ли вы, что код сам по себе ничего не ломает, а проблемой становится то, что за ним скрыто. Следом обычно просят рассказать, как вы локализовали такую ошибку и что написали в баг-репорте.
Как отвечать
Назовите свой вариант и обоснуйте его. Сильные кандидаты:
500 Internal Server Error: сервер упал на необработанном исключении, и снаружи не видно почему. Нужны логи, идентификатор запроса из заголовков ответа, точный запрос и данные, на которых ошибка воспроизводится;502,503,504: сбой на уровне прокси, балансировщика или таймаут апстрима. Плавают, зависят от нагрузки и окружения и на стенде тестировщика часто не воспроизводятся;200 OKс ошибкой в теле: самый коварный. Мониторинг и автотесты, которые смотрят только на код, считают запрос успешным, а пользователь видит сломанный экран;3xx: цепочки и циклы редиректов,302вместо301на переехавших адресах, потеря метода и тела при302(сохраняют их307и308).
Хорошая подача: «Самым неприятным считаю 200 с ошибкой внутри, его не ловит ничего, кроме проверки тела. 500 хотя бы видно сразу». Затем опишите, как вы работаете с 5xx: воспроизвести через Postman или curl, сохранить запрос целиком, найти запись в логах по времени и request id, приложить всё к багу. Назовите инструменты, которыми реально пользовались: Kibana, Grafana Loki, Sentry.
Где спотыкаются
Отвечают «500» и останавливаются. Без объяснения, чем он сложен и как вы с ним работаете, ответ звучит заученным.
Пишут баг «сервер вернул 500» без запроса, тела, времени и идентификатора. Разработчику нечем его воспроизвести, и задача возвращается обратно.
Считают 4xx не своей зоной. 401 вместо 403 или 400 без понятного сообщения тоже дефекты: клиент не сможет корректно на них среагировать.