Зачем нужна система логирования
Что проверяют
Умеете ли вы пользоваться логами при разборе дефекта и понимаете ли, что в них должно попадать, а что нет.
Как отвечать
Логи это восстановленная история того, что происходило в системе. Для тестировщика они закрывают три задачи: понять причину, а не только симптом; отличить дефект приложения от проблемы окружения; приложить к отчёту доказательство вместо «иногда не работает».
Что делает логи полезными:
- уровни: отладка, информация, предупреждение, ошибка. По уровню видно, что действительно требует внимания;
- структурированность: запись в виде полей, а не строки текста, чтобы по ней можно было искать и строить фильтры;
- сквозной идентификатор запроса: он проходит через все сервисы, и по нему собирается вся цепочка обработки. Без него в распределённой системе разбор превращается в гадание;
- контекст: идентификаторы сущностей, версия сборки, окружение. Достаточно, чтобы воспроизвести, но не больше;
- где смотреть: централизованный сбор (Kibana, Grafana, облачные аналоги), а не файлы на машинах.
Отдельно назовите, чего в логах быть не должно: паролей и токенов, персональных данных, полных тел запросов с чувствительным содержимым. Это требование безопасности, и его нарушение само по себе дефект.
Для баг-репорта правило простое: приложить идентификатор запроса, время с часовым поясом, окружение, фрагмент лога с ошибкой. Такой отчёт разбирают за минуты.
Где спотыкаются
Прикладывают скриншот с текстом «ошибка сервера» без идентификатора и времени.
Считают, что логи это забота разработчиков, и не смотрят их сами.
Требуют включить отладочный уровень на проде постоянно: это лишняя нагрузка и риск утечки данных.