Могли ли вы смотреть дашборды
Что проверяют
Был ли у вас доступ к мониторингу и логам и умеете ли вы им пользоваться при расследовании дефектов. QA, который видит только интерфейс, приносит баг «кнопка не работает», а QA с доступом к логам приносит конкретный запрос с ошибкой. Следом обычно просят рассказать, как вы нашли по дашборду причину конкретной проблемы.
Как отвечать
Назовите инструменты и то, что вы в них смотрели:
- Grafana: метрики из Prometheus или другого источника. Смотрят долю ответов 5xx, время ответа по перцентилям p95 и p99, отставание очередей, потребление памяти;
- Kibana или OpenSearch Dashboards: поиск по логам. Полезно знать базовый синтаксис запросов и фильтр по идентификатору запроса или trace id;
- Sentry или Crashlytics: ошибки фронтенда и мобильных приложений со стеком, версией и устройством;
- отчёты по автотестам: Allure или TestOps, где видны нестабильные тесты и тренд прогонов.
Дальше покажите, как вы это применяли. Воспроизвели баг, нашли в логах запрос по времени и идентификатору, приложили стек к задаче, и разработчик начал чинить без переспросов. После релиза следили за графиком ошибок и первыми заметили рост. При нагрузочном тестировании сопоставляли время ответа с загрузкой базы. Нужны ваши примеры, а не пересказ возможностей инструмента.
Если доступа не было, так и скажите. Расскажите, как вы тогда собирали информацию: DevTools браузера, Charles или Proxyman для запросов мобильного приложения, логи по просьбе разработчиков. И добавьте, что понимаете, зачем такой доступ нужен QA, и готовы быстро освоить конкретный стек.
Где спотыкаются
Отвечают «да, смотрел», и на этом всё. Без названия инструмента и конкретного случая такой ответ ничего не показывает.
Путают дашборды мониторинга с BI-отчётами для бизнеса. Вопрос почти всегда про наблюдаемость системы, а не про графики продаж в Power BI.
Не понимают, что показывают графики. Среднее время ответа может выглядеть нормально, пока растёт p99 и часть пользователей ждёт ответа секундами.