Использовали ли вы логирование в проектах?

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

Для тестировщика вопрос не про настройку логгера, а про то, умеете ли вы по логам локализовать дефект и приложить к баг-репорту доказательства. Следом спрашивают, какими инструментами вы логи смотрели и как нашли в них конкретный запрос.

Как отвечать

Стройте ответ на своих примерах, с трёх сторон:

• логи тестируемой системы: где смотрели (Kibana или OpenSearch Dashboards, Grafana Loki, Sentry, kubectl logs или docker logs на стенде) и как искали. Главный приём: найти запрос по correlation id или trace id и пройти по нему через все сервисы. В баг-репорт идёт фрагмент лога со временем и идентификатором, а не «на бэке ошибка»;
• логи автотестов: что пишет ваш фреймворк и как это помогает разбирать падения в CI. Запрос и ответ API вложением в Allure, шаги, скриншот и консоль браузера при падении UI-теста. В .NET это ITestOutputHelper в xUnit или TestContext в NUnit, для структурных логов Serilog или NLog; в Java SLF4J с Logback или Log4j 2;
• логирование как объект проверки: ошибки пишутся с нужным уровнем и контекстом, в логах нет паролей, токенов и персональных данных. Это отдельный класс дефектов, который ловят редко.

Результат описывайте своими словами и цифрами, которые сможете подтвердить, например: «падение в ночном прогоне теперь разбирается по отчёту, без перезапуска». Если сами логирование не настраивали, так и скажите и расскажите, как логами пользовались: для QA это и есть основной навык.

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

Отвечают «да, смотрел логи» и замолкают. Без инструмента, приёма поиска и примера найденного бага ответ ничего не показывает.

Пишут в отчёт автотестов всё подряд на уровне DEBUG. Упавший тест тонет в шуме, и разбор занимает больше времени, чем без логов.

Прикладывают к Allure полные запросы с заголовком Authorization и токенами. Отчёт открыт всей команде, а иногда и подрядчикам, это утечка.