Контекст
Лог — это хронологическая запись событий, которые приложение само сообщает о своей работе. Для QA лог отвечает на вопрос «что именно произошло внутри системы в момент дефекта», а не «что увидел пользователь на экране». Без логов QA вынужден гадать о причине, описывать симптом и перекидывать тикет разработчику. С логами тот же QA локализует проблему до сервиса, эндпоинта или конкретной строки. Этот курс целиком о логах: мы не разбираем метрики и трейсы как самостоятельные темы, а используем их только там, где они помогают читать логи.
- Лог фиксирует факт события с timestamp: запрос пришёл, ошибка возникла, транзакция закоммичена
- QA читает лог, чтобы отделить дефект приложения от проблемы окружения или тестовых данных
- Лог превращает расплывчатый баг-репорт «иногда падает» в воспроизводимый сценарий с точным временем
- Доступ к логам сокращает цикл «нашёл — описал — починили» в разы
- Логи — самый дешёвый сигнал: они есть почти везде, в отличие от настроенных трейсов
Рабочий алгоритм
Чтобы лог стал инструментом, а не свалкой текста, QA должен подходить к нему системно. Этот алгоритм описывает базовый цикл работы с логами при любом дефекте.
- Шаг 1. Зафиксируйте точное время воспроизведения дефекта по своим часам или часам сервера
- Шаг 2. Определите, какой компонент логирует нужное событие: бэкенд, фронтенд, очередь, БД
- Шаг 3. Откройте лог этого компонента и сузьте окно до ±1–2 минут вокруг времени дефекта
- Шаг 4. Найдите записи уровня ERROR/WARN и прочитайте их сообщение целиком, а не первую строку
- Шаг 5. Свяжите запись с вашим действием через requestId, userId или уникальный параметр
- Шаг 6. Сохраните релевантный фрагмент лога для баг-репорта до того, как лог уйдёт по retention
Пример из практики
QA тестирует оформление заказа и периодически видит «Ошибка сервера» без деталей. Симптом размытый, разработчик просит шаги воспроизведения, но они нестабильны.
- QA фиксирует время клика «Оплатить» — 14:32:07 — и открывает лог платёжного сервиса
- В окне 14:32 находит ERROR с сообщением о таймауте к внешнему банку и requestId заказа
- По requestId видно, что таймаут случается только когда сумма заказа превышает лимит
- Баг-репорт превращается из «иногда падает» в «таймаут при сумме > лимита, лог приложен»
Частые ошибки
Большинство ошибок при работе с логами связаны не с инструментами, а с привычками. Вот типичные ловушки начинающего QA.
- Читать только первую строку ошибки и игнорировать сообщение и контекст ниже
- Считать логи делом разработчиков и не запрашивать к ним доступ заранее
- Не фиксировать время дефекта, а потом искать запись в часе логов вслепую
- Прикладывать к багу скриншот UI вместо релевантного фрагмента лога
- Полагаться на память: вернуться к логу через сутки, когда он уже удалён по retention