Представьте ситуацию. Вы заходите на сайт. Что-то идёт не так. Кнопка не работает. Данные не загружаются. Страница падает.
Обычный пользователь обновляет страницу. Или уходит. Или пишет в поддержку «у вас сломалось» что бывает крайне редко.
Тестировщик делает по-другому. Он открывает лог.
Не потому что он супертехнарь. А потому что лог — это единственный объективный источник правды о том, что реально произошло на сервере и в браузере.
Лог — это запись событий. Сервер записывает в него каждое действие: кто к нему пришёл, что попросил, что ответил и с каким кодом. Если что-то упало — лог сохранит ошибку. Если что-то работало медленно — лог покажет время.
Для тестировщика лог — это первое место, куда он смотрит при воспроизведении бага. Не чтобы прочитать и понять код. А чтобы найти улики и передать их разработчику.
Как это выглядит на практике
Откройте любой сайт. Нажмите F12. Перейдите во вкладку Console.
Вы увидите записи. Возможно, серые и белые строки. Возможно, жёлтые и красные. Это и есть логи браузера.
- Теперь сделайте что-то, что должно сломаться. Например, введите в поле формы символы, которых там быть не должно. Или отправьте пустую форму.
- Посмотрите на Console. Появилась красная строка? Нажмите на неё — откроется стек вызовов (stacktrace). Это цепочка действий, которая привела к ошибке.
Теперь вы знаете, где искать. Дальше разберёмся, что означают эти записи и как их читать.
Уровни логирования: что означает каждый на практике
Логи бывают разными. Их разделяют по уровню важности. Чем выше уровень — тем серьёзнее событие.
- DEBUG — самый низкий уровень. Используется для отладки. Разработчик пишет в код сообщения вроде «сюда зашли», «переменная равна 5». В продакшене эти логи обычно отключены, потому что их слишком много. Если вы видите DEBUG — значит, вы тестируете в окружении разработки.
- INFO — информационные сообщения. Всё работает как надо. Пользователь залогинился, заказ создан, страница загружена. Эти логи показывают нормальный поток работы системы.
- WARNING — что-то пошло не так, но система справилась. Например, пользователь отправил невалидный номер телефона, но сервер его подправил. Или старый метод API скоро перестанет работать, но пока ещё работает. Предупреждение — это не ошибка, а сигнал: «Обрати внимание, но пока всё живо».
- ERROR — произошла ошибка. Что-то упало. Пользователь не получил то, что хотел. Это самое частое, что вы будете искать как тестировщик. Но не каждый ERROR — это баг.
- CRITICAL — критическая ошибка. Система не может работать дальше. Упал сервер, сломалась база данных, закончилось место на диске. Это уже не задача тестировщика — это задача DevOps и разработчиков. Но знать, что такое CRITICAL, нужно.
Где искать логи
Логи живут в 3-х местах. У каждого — своя роль.
- Логи браузера — это Console во вкладке DevTools. Вы видите их прямо сейчас, когда открываете сайт. Там пишет JavaScript-код. Если в коде ошибка — вы увидите красную строку. Если разработчик специально выводит информацию — вы увидите белую или серую строку.
Эти логи видны только вам. Другие пользователи их не увидят. Они нужны для отладки клиентской части — того, что происходит в браузере пользователя.
- Логи приложения — это записи, которые создаёт само приложение. Они хранятся на сервере. Обычно в папке logs или в специальной системе сбора логов. Туда пишут всё: и успешные запросы, и ошибки, и предупреждения. Тестировщик обычно не имеет прямого доступа к серверным логам — их смотрит разработчик или DevOps. Но тестировщик должен знать, что они есть и что в них можно найти.
- Логи сервера — это записи веб-сервера (nginx, Apache). Они фиксируют все входящие запросы: кто пришёл, что попросил, какой получил ответ, сколько времени это заняло. Если сервер вернул 500 — это точно будет в логе веб-сервера. Тестировщик может не работать с ними напрямую, но может попросить разработчика посмотреть.
Нюанс, который стоит запомнить: не каждый ERROR — баг
Вот здесь начинается самое важное.
Новичок видит в логе красную строку — и сразу пишет баг-репорт. Не торопитесь.
Иногда система сама восстанавливается после ошибки. Например, пользователь запросил товар, которого нет. Сервер вернул ERROR в лог, а пользователю показал «Товар не найден». Это не баг — это штатная ситуация. Ошибка в логе, но пользователь получил корректный ответ.
Или: запрос к внешнему API упал, сервер попробовал ещё раз — и успешно. В логе появился ERROR, но пользователь вообще ничего не заметил. Это не баг — это нормальное поведение системы.
Как отличить?
Смотрите на контекст:
- Что пользователь увидел на экране?
- Вернулся ли сервис в нормальное состояние?
- Повторилась ли ошибка при повторном запросе?
Если пользователь увидел ошибку, а не результат — это баг.
Если система упала и не восстановилась — это баг.
Если ошибка в логе, но пользователь получил всё как надо — это не баг, это информационный шум.
И ещё один важный момент: ERROR в логе одного сервиса может быть нормой для другого. Например, в процессе пакетной обработки ошибка в одной записи — это штатно. Главное, чтобы система обработала остальные.
Что такое stacktrace и зачем он нужен
Когда в логе появляется ERROR, разработчику нужно понять, где именно произошла ошибка. Для этого в лог пишут стек вызовов — stacktrace.
Stacktrace — это цепочка. Каждая строка — шаг. Одна функция вызвала другую, та — третью, и на каком-то шаге всё упало.
Выглядит это страшно. Много непонятных слов, имён файлов, номеров строк. Но тестировщику не нужно читать весь стек. Нужно найти три вещи:
Класс или файл, где произошла ошибка (обычно первая строка снизу или последняя в цепочке вашего кода).
Номер строки, где упало.
Тип ошибки (например, NullPointerException или TypeError).
Эту информацию вы передаёте разработчику. Он уже сам разберётся.
Что делать, если в стеке нет ошибки, а есть просто красная строка без подробностей? Иногда это значит, что разработчик не обработал ошибку и не вывел информацию. Это уже повод для баг-репорта — и он как раз про то, что ошибка не логируется.
Где обычно ошибаются новички
- Ошибка первая: путают Warning и Error. Видят жёлтое в Console — и пишут баг. А это предупреждение. Оно может быть про устаревший метод или про медленный запрос, но не про сломанный функционал.
- Ошибка вторая: не смотрят на контекст. Увидели Error — сразу побежали к разработчику. А Error может быть ожидаемым поведением, как в примере с «Товар не найден».
- Ошибка третья: не проверяют, повторяется ли ошибка. Одна ошибка — могла быть случайность. Десять одинаковых — это закономерность. В баг-репорте важно указывать стабильность воспроизведения.
- Ошибка четвёртая: не читают полный лог. Ограничиваются первой красной строкой. А под ней может быть важная информация о том, где именно упало. Всегда разворачивайте стек полностью.
- Ошибка пятая: считают, что в логе должны быть только ошибки. Нет. Лог — это запись всего. Там и успешные действия, и предупреждения, и информационные сообщения. Это нормально.
Практическое задание
Условие:
Откройте любой сайт с интерактивными элементами — например, форму поиска или регистрации. Нажмите F12, перейдите во вкладку Console. Намеренно введите данные, которые должны сломать форму: пустое поле, текст вместо цифр, слишком длинную строку.
Что нужно сделать:
- Выполните действие на сайте, которое приведёт к ошибке в Console.
- Зафиксируйте, что именно появилось в логе: текст ошибки, уровень (ERROR/WARNING), стек вызовов (если есть).
- Запишите, что вы сделали, чтобы получить ошибку.
- Определите, является ли это багом или штатной ситуацией.
Как оформить результат:
- Что сделал: в поле для номера телефона ввёл текст вместо цифр и нажал «Отправить».
- В Console: ERROR: Invalid phone number format at validation.js:45.
- На экране: подсветка поля красным и сообщение «Введите номер телефона».
- Решение: это не баг — форма корректно обработала невалидные данные и показала сообщение пользователю.
Если застряли: попробуйте отключить интернет на пару секунд и отправить форму. Браузер выдаст ошибку в Console — это хороший учебный пример, как выглядит логирование сетевых ошибок. Только не забудьте включить интернет обратно.
Напишите свои результаты в комментариях. Разберём вместе, правильно ли вы определили баг и что именно стоит передать разработчику.
Если хотите глубже разобраться с тестированием — подписывайтесь на мой канал и заходите в подборку статей Тестировщик ПО с 0 в 43 публикую все что будет полезно для начинающего тестировщика.