Вы заходите на сайт, и что-то идёт не так. Кнопка не работает. Данные не загружаются. Страница выглядит странно.
В этот момент обычный пользователь обновляет страницу. Или закрывает вкладку. Или пишет в поддержку, что у них там сломалось.
А тестировщик делает другое. Он открывает инструменты разработчика.
Не потому что он супертехнарь, а потому что это первый и самый быстрый способ понять, что произошло. Без гаданий. Без пересылки скриншотов в техподдержку. Просто открыл — и увидел.
DevTools — это встроенная в браузер панель, которая показывает всё, что происходит под капотом сайта: какие запросы уходят на сервер, что приходит в ответ, есть ли ошибки в коде, как сверстаны блоки. Это главный инструмент тестировщика на этапе ручного тестирования.
Сегодня разберём, что смотреть в DevTools в первую очередь. Без глубокого программирования — просто как рабочий инструмент для поиска и фиксации багов.
Как это выглядит на практике
Откройте любой сайт. Любой, который вы используете каждый день.
Нажмите F12. В большинстве браузеров это работает. Если нет — кликните правой кнопкой по странице и выберите «Исследовать элемент» или «Посмотреть код».
В открывшемся окне — панель с вкладками. Elements, Console, Sources, Network, Performance и другие. Нам пока нужны три: Network, Console и немного Elements.
Теперь перезагрузите страницу — F5. И переключитесь на вкладку Network.
Вы увидите список всех запросов, которые браузер отправил, чтобы загрузить эту страницу. HTML-документ, стили, скрипты, картинки, запросы к API — всё здесь.
Нажмите на любой запрос. Откроется панель с деталями: Headers (заголовки), Preview (просмотр ответа), Response (сырой ответ), Timing (время выполнения).
Всё это — ваши данные для анализа. Теперь разберёмся, что с ними делать.
Вкладка Network: что показывает и как фильтровать
Network — это главная вкладка для тестирования взаимодействия с сервером. Она показывает все запросы и ответы.
По умолчанию там много всего: HTML, CSS, JS-файлы, картинки, шрифты. Чтобы не тонуть в этом потоке, используйте фильтры.
В верхней части вкладки — иконки для фильтрации по типу:
- All — все запросы.
- XHR/Fetch — запросы от JavaScript к серверу. Это те самые, где передаются данные и получаются ответы. Именно здесь чаще всего видны баги API.
- JS, CSS, Img — скрипты, стили, картинки. Для верстки и загрузки ресурсов, не для тестирования логики.
- Doc — основной HTML-документ.
Для тестировщика самый важный фильтр — XHR/Fetch. Нажмите на него — и увидите только те запросы, которые имеют отношение к данным: отправка форм, загрузка списка товаров, авторизация, отправка комментариев. Всё, что меняет или передаёт информацию.
Колонки в Network:
- Name — имя запроса (часто это путь или название метода)
- Status — код ответа (200, 404, 500 — о них мы говорили в прошлой статье)
- Type — тип данных в ответе (json, html, js)
- Size — размер ответа
- Time — время выполнения запроса
- Waterfall — визуальное отображение времени загрузки
Для поиска багов смотрите на Status и Time. Если видите 4xx или 5xx — это уже повод заглянуть внутрь. Если запрос висит более 1-2 секунд — возможно, проблема с производительностью.
Как посмотреть заголовки запроса и ответа
Нажмите на любой запрос в Network. Откроется панель с деталями. Нам нужна вкладка Headers.
Здесь 2 основные части: Request Headers и Response Headers.
Request Headers — это то, что браузер отправил серверу. Там есть:
- Метод (GET, POST, PUT, DELETE)
- URL
- Content-Type — тип данных, которые вы передаёте (например, application/json)
- Authorization — токен авторизации, если он передаётся
- Cookie — куки, которые браузер отправляет автоматически
Response Headers — это то, что сервер вернул обратно. Там может быть:
- Content-Type — тип данных в ответе
- Server — информация о серверном ПО
- Cache-Control — настройки кэширования
- Set-Cookie — установка новых кук
Для тестировщика в заголовках важны 2 вещи
- Первая — Content-Type. Если вы отправляете JSON, а сервер ожидает form-data, он вернёт 400. Смотрим в Request Headers — и сразу видно, что вы отправили не то.
- Вторая — авторизация. Если в запросе нет заголовка Authorization или он неправильный — получите 401. Проверяете Request Headers — и видите, что токен не передаётся или невалидный.
После заголовков переключитесь на вкладку Response. Там будет тело ответа сервера. Если код 200, а внутри — ошибка (например, {"success": false, "message": "Недостаточно средств"}), это баг бизнес-логики. Код 200 не означает, что всё хорошо — нужно проверять и содержимое.
Вкладка Console: где искать ошибки JS
Console — это вторая по важности вкладка для тестировщика. Она показывает всё, что JavaScript-код пишет в консоль браузера.
Ошибки выглядят красным цветом. Предупреждения — жёлтым. Просто информационные сообщения — белым или серым.
Если в Console есть красная ошибка — это почти всегда баг. Например, «Cannot read property 'name' of undefined» — скрипт попытался прочитать поле у несуществующего объекта. Это баг, который разработчик должен починить.
Но не всё красное — ваша проблема. Часть ошибок в Console — это предупреждения сторонних скриптов. Например, рекламные сети, аналитика, виджеты. Они могут падать, но на работу самого сайта не влияют. Важно отличать «шум» от реальной проблемы.
Как различить?
Посмотрите на имя файла, где произошла ошибка. Если в пути есть название вашего сайта — скорее всего, это ваш код, и это баг. Если в пути указан сторонний сервис (например, «yandex.ru», «googleapis.com», «facebook.net») — это внешний скрипт, и к функциональности сайта он относится косвенно.
Нюанс: не все ошибки в Console — баги
Этот нюанс стоит запомнить сразу.
В Console часто много красного. Новичок видит красную строчку и сразу пишет баг-репорт. Но не всё красное — это баг вашего приложения.
Причины «шума» в Console:
- Сторонние скрипты. Аналитика, реклама, виджеты соцсетей. Они могут пытаться загрузить что-то и падать — на работу вашего приложения это не влияет.
- Браузерные расширения. Установленные плагины тоже пишут в консоль. Вы можете видеть ошибки расширения, к которым ваш сайт не имеет отношения.
- Предупреждения о deprecated-функциях. Браузер говорит: «Эта функция устареет в следующей версии, обновите код». Это не ошибка — это предупреждение. Баг-репорт по нему не заводится, если только функциональность не сломана.
Как фильтровать шум?
- Во-первых, смотрите на цвет. Красное — ошибка, жёлтое — предупреждение. По жёлтому редко заводят баги — чаще это рекомендации.
- Во-вторых, смотрите на источник ошибки. Если в названии файла есть ваш домен — скорее всего, это ваш код. Если внешний домен — это чужой скрипт.
- В-третьих, попробуйте открыть страницу в режиме инкогнито без расширений. Если ошибки пропали — они были связаны с расширениями, а не с приложением.
Этот навык приходит с практикой. Сначала вы видите весь шум, потом учитесь отсеивать лишнее и видите только то, что реально нужно.
Elements: как посмотреть структуру страницы
Третья вкладка — Elements. Она показывает HTML-код страницы в том виде, в каком он сформирован после всех скриптов и стилей.
Для тестировщика вкладка — Elements полезна для 2 вещей.
- Первая — проверка атрибутов. Нужно убедиться, что у элемента есть правильный ID или класс, что ссылка ведёт куда надо, что заполнены все data-атрибуты. В Elements вы легко найдёте любой элемент — кликните по нему мышкой в панели или наведите курсор на код.
- Вторая — проверка скрытых элементов. Бывает, что на странице есть блок, который появляется только при определённом условии. Он может быть в коде, но скрыт через display: none. В Elements вы увидите его, даже если на странице он не визуализирован.
Также в Elements можно менять атрибуты на лету — и видеть, как меняется страница. Это помогает проверить, что будет, если подставить другие данные, не перезагружая страницу.
Где обычно ошибаются новички
- Ошибка первая: забывают фильтровать Network. Смотрят на все запросы подряд и теряются в потоке. Включайте XHR/Fetch — и увидите только то, что нужно.
- Ошибка вторая: не смотрят вкладку Response. Ограничиваются кодом 200 и считают, что всё хорошо. А внутри — ошибка в JSON, которую надо зафиксировать.
- Ошибка третья: путают ошибки в Console и отправляют баги на сторонние скрипты. Проверяйте источник ошибки перед тем, как писать баг-репорт.
- Ошибка четвёртая: не знают, что заголовки можно посмотреть. Думают, что DevTools показывает только код ответа, и не нажимают на запрос. А там — вся информация.
- Ошибка пятая: боятся открывать DevTools и думают, что это «для программистов». Нет, это для любого, кто работает с сайтом. Вы не пишете код, вы просто смотрите, что происходит. Это как заглянуть под капот машины — не механик, но видно, где течёт.
Практическое задание
Условие: откройте сайт, на котором есть активный функционал с запросами к API — интернет-магазин, соцсеть, сервис карт. Нажмите F12, перейдите во вкладку Network, включите фильтр XHR/Fetch. Выполните на сайте действие: поиск товара, отправка формы, переход на страницу товара.
Что нужно сделать:
Найдите в Network запрос, который вернул ошибку (код 4xx или 5xx). Если ошибок нет — найдите запрос с большим временем выполнения (более 1 секунды) или запрос, который вернул не тот JSON, который ожидался.
Откройте этот запрос, посмотрите:
- Status Code (в Headers)
- Request Headers — что именно вы отправили
- Response — что пришло в ответ
Найдите в Console красную ошибку (если есть). Определите, из какого файла она пришла — ваш код или сторонний скрипт.
Сделайте скриншот запроса в Network (вкладка Headers или Response).
Как оформить результат:
- Запрос: POST /api/order
- Статус: 400 Bad Request
- Что отправил: Content-Type: application/json, тело: {"product_id": "abc", "quantity": 1}
- Что получил: {"error": "product_id должен быть числом"}
- В Console: ошибка "Failed to load resource: the server responded with a status of 400"
Источник: из файла main.js (это ваш код, значит, баг на обработку данных от клиента)
Если нет ошибок — опишите один успешный запрос (200) и напишите, что вы проверили в заголовках и ответе.
Как проверить себя:
- Вы нашли хотя бы один запрос в XHR/Fetch, а не среди картинок или стилей.
- Вы посмотрели Request Headers и поняли, что именно отправляли.
- Вы посмотрели Response и поняли, что именно пришло.
- Вы проверили Console и определили, относится ли найденная ошибка к вашему приложению.
Если застряли: на многих сайтах нет ошибок в Network — это хорошо, значит, сайт работает. Тогда найдите запрос к API (с JSON в ответе) и просто разберите его: что отправлено, что получено, какие заголовки. Это тоже практика.
Напишите свои результаты в комментариях. Если найдёте баг — опишите его, как сделали бы в баг-репорте.
Если хотите глубже разобраться с инструментами — подписывайтесь на канал, обязательно ставьте "лайк" тут мы с вами разбираем всё, что встречается на дорожной карте начинающего тестировщика.