Консоль DevTools: как читать ошибки и понимать, чья вина
Красная строка в консоли превращает «кнопка не работает» в конкретный дефект с точным местом поломки. Разберём, что там смотреть и что копировать в задачу.
Первое, что нужно сделать
Откройте DevTools (F12) на любом продукте, с которым работаете, и держите вкладку Console открытой всё время проверки. Не для того, чтобы разбираться в коде, а чтобы видеть: молчит консоль или сыплет ошибками.
Продукт, который внешне работает, но каждую секунду пишет ошибки в консоль, — это дефект. Часто такие ошибки означают, что часть функциональности отваливается тихо и всплывёт у пользователя в другом сценарии.
Типы сообщений
| Тип | Цвет | Насколько серьёзно |
|---|---|---|
| Error | Красный | Что-то сломалось. Заводим или выясняем |
| Warning | Жёлтый | Предупреждение: устаревший вызов, проблема с ресурсом |
| Info / Log | Обычный | Отладочные сообщения разработчиков |
Фильтр сверху позволяет оставить только Errors — с него и стоит начинать. Жёлтые предупреждения обычно не заводят, но если их сотни, это тоже повод спросить команду.
Отладочные console.log с внутренними данными, оставленные в боевой версии. Иногда там оказываются токены, ответы сервера целиком или персональные данные — это уже вопрос безопасности, а не аккуратности.
Как читать ошибку
Ошибка состоит из трёх частей: тип, сообщение и стек вызовов — цепочка, показывающая, откуда всё пришло.
Например: TypeError: Cannot read properties of undefined (reading 'name'). Расшифровка для тестировщика: код ожидал объект, а получил «ничего», и попытался взять у него поле name.
Практический вывод почти всегда один: где-то не пришли данные. Стоит открыть вкладку Network и посмотреть, не упал ли запрос, который должен был эти данные принести. В половине случаев там и найдётся настоящая причина.
Частые виды ошибок и что они значат
| Ошибка | О чём говорит |
|---|---|
TypeError: Cannot read properties of undefined | Не пришли данные или пришли не в том виде |
404 (Not Found) для файла | Отсутствует картинка, скрипт или стиль — проверьте, всё ли выложили |
Uncaught (in promise) | Ошибка запроса, которую никто не обработал: пользователь ничего не увидит |
CORS policy | Сервер не разрешает обращение с этого адреса — частая проблема на тестовых стендах |
Mixed Content | На https-странице грузится http-ресурс. Дефект безопасности |
Failed to fetch | Запрос не ушёл: нет сети, сервер недоступен или заблокирован |
Что прикладывать к баг-репорту
- Текст ошибки целиком — текстом, не скриншотом. По тексту разработчик ищет в коде, по картинке — нет.
- Стек вызовов. Разверните и скопируйте: первые строки указывают на место в коде.
- Момент появления. Ошибка была при загрузке страницы или после нажатия кнопки — это разные дефекты.
- Связанный запрос из вкладки Network, если ошибка про данные.
- Воспроизводимость. Всегда или иногда — от этого зависит подход к разбору.
Как оформить всё это в задачу — в разборе как писать баг-репорт.
Связка консоли и вкладки Network
Самая частая рабочая ситуация: в консоли красная ошибка про данные, а настоящая причина — в упавшем запросе. Разбирать их по отдельности бесполезно, смотреть надо вместе.
- Увидели ошибку в консоли — запомнили время её появления.
- Перешли в Network и нашли запросы того же момента.
- Проверили коды: есть ли 4xx или 5xx рядом по времени.
- Открыли Response упавшего запроса — что именно вернул сервер.
- Сопоставили: ошибка в консоли обычно следствие, ответ сервера — причина.
В репорт идут обе части. Разработчику важно знать и что упало на сервере, и как на это отреагировал интерфейс: это часто два разных дефекта, и чинят их разные люди.
Полезные приёмы
- Preserve log — сохранять сообщения при переходе на другую страницу. Без этого ошибка, после которой произошёл редирект, исчезает.
- Фильтр по тексту. Строка поиска отсекает шум и оставляет нужное.
- Правый клик → Save as… — сохранить всю консоль в файл и приложить к задаче.
- Группировка. Повторяющиеся сообщения схлопываются со счётчиком — по нему видно, что ошибка сыплется в цикле.
- Проверка в инкогнито. Отделяет дефекты продукта от влияния расширений браузера.
Что смотреть, кроме ошибок
Консоль умеет больше, чем показывать красное, и пара вещей пригодится в обычной проверке.
- Сообщения о заблокированных ресурсах. Если браузер отказался грузить скрипт или шрифт, здесь будет причина — часто это неверные настройки безопасности на стенде.
- Предупреждения о deprecated. Сигнал, что продукт использует то, что скоро перестанет работать. Не срочный дефект, но повод завести задачу.
- Ошибки сторонних сервисов. Аналитика, чаты, платёжные виджеты сыплют своими сообщениями. Отделять их от своих помогает проверка в инкогнито.
- Медленные предупреждения о производительности. Некоторые браузеры сообщают о долгих задачах, блокирующих интерфейс.
Чего не стоит делать
Не выполняйте в консоли код, который вам прислали или который вы нашли в интернете. Консоль работает от вашего имени в вашей сессии: вставленный туда фрагмент может отправить ваши куки и токены куда угодно. Браузеры не зря выводят там предупреждение крупными буквами.
И не приносите в задачу вывод консоли обрезанным до одной строки. Первая строка ошибки без стека часто бесполезна — она говорит «что-то не то с данными», но не говорит где.
Нужно ли тестировщику знать JavaScript?
Для чтения ошибок — нет. Достаточно понимать типы ошибок и уметь связать их с запросами. Знание языка помогает, но не является входным требованием.
Каждую ли ошибку в консоли заводить?
Нет. Ошибки от расширений браузера и сторонних сервисов (аналитика, чаты) обычно не ваши. Проверьте в инкогнито: если ошибка осталась — она про продукт.
Что делать, если консоль чистая, а функция не работает?
Идти во вкладку Network: скорее всего, запрос вернул ошибку, которую код молча проглотил. Это отдельный дефект — пользователь должен видеть, что произошло.