В каждом браузере есть встроенные инструменты разработчика — DevTools. Открываются клавишей F12 (или правой кнопкой → «Просмотреть код»). Название пугает словом «разработчик», но тестировщику эти инструменты нужны почти так же, как разработчику: они превращают проверку из «снаружи, вслепую» в серый ящик, где видно, что реально происходит под капотом страницы.
Разбирать все вкладки не нужно. Тестировщику хватает четырёх: Console (консоль), Network (сеть), Elements (элементы) и Application (хранилища). Пройдёмся по каждой.
Console — ошибки страницы
Вкладка Console показывает сообщения, которые страница выводит для разработчиков, и — самое ценное для вас — ошибки. Они обычно выделены красным.
Зачем это тестировщику: если на странице что-то ведёт себя странно (кнопка не срабатывает, данные не грузятся), в консоли часто лежит красная ошибка, объясняющая причину. Даже если вы не понимаете её текст целиком, скриншот этой ошибки в баг-репорте — золото для разработчика: он сразу видит, куда смотреть.
Практическое правило: заметили баг — загляните в консоль перед тем, как заводить. Есть красная ошибка — приложите её.
Network — запросы к серверу
Вкладка Network показывает все обращения страницы к серверу: за данными, за картинками, при отправке формы. Каждая строка — один запрос. Чтобы увидеть их, откройте Network и обновите страницу или выполните действие (например, нажмите «Войти»).
Что здесь смотрит тестировщик:
- Статус запроса. Число вроде 200 — успех; 400/404 — что-то не так с запросом; 500 — ошибка на сервере. Красные строки со статусом 500 — верный признак серверного бага.
- Что ушло и что пришло. Кликнув по запросу, можно посмотреть, какие данные страница отправила серверу и что он ответил. Это помогает понять, где сломалось: на стороне страницы (отправила не то) или сервера (ответил неверно).
Пример пользы: форма «молча» не сохраняется. В Network видно: запрос ушёл, сервер ответил статусом 500. Значит, баг на сервере, а не в кнопке, — и это ценная деталь для репорта.
Elements — устройство страницы
Вкладка Elements показывает HTML-структуру страницы — из чего она собрана — и позволяет её временно поменять прямо в браузере (у себя, не для всех).
Чем полезно тестировщику:
- Посмотреть, что там на самом деле. Например, поле выглядит пустым, но в разметке видно, что значение есть, просто не отображается.
- Проверить тексты и подписи — точно ли совпадают с макетом.
- Быстро проверить длинный текст: временно вписать в поле очень длинную строку прямо в разметке, чтобы увидеть, не разъедется ли вёрстка.
Глубоко в Elements лезть новичку не нужно, но уметь заглянуть и увидеть структуру — полезный навык.
Application — что страница хранит у себя
Часть багов не повторяется на чистом браузере и живёт «только у меня»: у каждого своё сохранённое состояние. Всё, что страница отложила себе, лежит во вкладке Application (в Firefox — «Хранилище»), там же это удаляют поштучно.
Четыре полки браузера с разным сроком жизни: SessionStorage умирает вместе с вкладкой, сессионная кука — вместе с браузером, LocalStorage живёт, пока его не почистят, кэш сбрасывается жёсткой перезагрузкой. Отсюда и разные симптомы: «выкинуло из аккаунта» — про куки, «показывает старое» — про кэш.
Куки — маленькие пары «имя — значение», которые браузер сам прикладывает к каждому запросу на этот домен: идентификатор сессии, выбранный язык, метка согласия на обработку данных. Кроме имени и значения у куки есть срок (Expires) и два флага, которые проверяют: HttpOnly — куку не достать скриптом страницы, её шлёт только браузер; Secure — куку отправляют только по HTTPS. У сессионной куки оба флага обязаны стоять, и пустая ячейка в этой таблице — дефект.
LocalStorage и SessionStorage — хранилища побольше, куда страница кладёт данные сама и сама же их читает; на сервер они не уходят. Разница одна — срок жизни: LocalStorage переживает и перезагрузку, и закрытие браузера, пока его не почистят; SessionStorage живёт до закрытия вкладки, в соседней вкладке его уже нет. Лежат там черновик формы, свёрнутые панели, выбранный фильтр, иногда токен. Отсюда проверка: обещанное «запомнить» должно лежать в LocalStorage — иначе запомнили только до закрытия вкладки.
Ниже в той же вкладке — кэш: сохранённые файлы страницы и ответы сервера.
Куки против кэша
Их путают, хотя это разные полки. Куки — данные о вас: кто вошёл, какой язык, что в корзине; браузер прикладывает их к запросам. Кэш — копии файлов и ответов, сохранённые, чтобы не качать второй раз. Симптомы поэтому разные: слетели куки — вас выкинуло из аккаунта и корзина пуста; сработал кэш — видите старую версию страницы, хотя на сервере уже новая.
Из-за второго легко завести ложный баг: исправление выкатили, а в браузере лежит вчерашний файл со скриптом — «ничего не починилось». На этот случай в Network есть галочка «Отключить кэш»: она действует, пока DevTools открыты, и проверку свежего выката держат на ней. Второй приём — жёсткая перезагрузка (Ctrl+Shift+R, на Mac Cmd+Shift+R): страница и её файлы качаются заново.
Правило простое: прежде чем заводить баг «не применилось» или «показывает старое», повторите сценарий с отключённым кэшем или в приватном окне. Повторилось — баг настоящий; нет — это был ваш кэш.
Ошибка CORS в консоли
Красный текст вида «blocked by CORS policy» пугает сильнее прочего и выглядит как поломка браузера. На деле это правило безопасности: страница с одного адреса не может прочитать ответ с другого, пока тот сам не разрешит. Разрешение приходит заголовком Access-Control-Allow-Origin в ответе — значит, чинится это на сервере, а не в браузере.
В Network видно так: запрос ушёл, в ответе бывает даже 200, но страница ответ не получила и ничего не показала. Частая причина — фронтенд стенда открыт по одному адресу, API отвечает по другому, и адрес стенда забыли внести в список разрешённых.
В баг-репорт идут адрес страницы, адрес запроса, метод, полный текст ошибки из консоли и заголовки ответа — этого хватает, чтобы понять, какой домен не разрешили. Чинить такое расширением, отключающим проверку, нельзя: у вас баг спрячется, у пользователя останется.
Эмуляция устройств
В DevTools есть режим, который показывает страницу как на телефоне разного размера, — удобно для быстрой проверки адаптивности, хотя настоящее устройство он не заменяет.
Где это применяется
DevTools — это переход от «тыкаю снаружи и гадаю» к «вижу, что произошло». Практически каждый нетривиальный баг стоит проверять с открытыми инструментами: красная ошибка в консоли или упавший запрос в Network часто сразу указывают на причину и делают ваш баг-репорт в разы полезнее. Это один из главных навыков, отличающих джуна, который «просто кликает», от того, кто понимает, что происходит.
Где спотыкаются начинающие:
- Не открывают DevTools вообще и заводят баги «форма не работает», хотя в консоли прямым текстом лежит причина.
- Пугаются незнакомого текста ошибок. Не нужно понимать всё — достаточно приложить скриншот, разработчик разберётся.
- Путают, где сломалось. Network помогает различить: страница отправила не то (клиент) или сервер ответил неверно (500).
- Заводят баг на собственном кэше. «После выката ничего не изменилось» часто лечится галочкой «Отключить кэш» и жёсткой перезагрузкой — проверьте до того, как писать репорт.
Что учить дальше. Network показал, что страница общается с сервером запросами. Проверять эти запросы можно и напрямую, без интерфейса, — это основы API-тестирования в Postman.