DevTools, кроссбраузерность и адаптивность

«Открой DevTools и покажи, чей это баг» — типовое практическое задание на собеседовании веб-тестировщика.

DevTools — встроенная панель разработчика браузера (F12). Для тестировщика это способ превратить «что-то не работает» в «POST /api/orders вернул 500, вот тело ответа и request-id».

Вопрос 1: «Как определить, чей дефект — фронтенда или бэкенда?»

Что на самом деле проверяет интервьюер

Способны ли вы локализовать проблему до заведения бага. Тестировщик, который умеет это делать, экономит команде часы.

Развёрнутый ответ

Алгоритм разбирается по вкладке Network:

Открыть Network, включить «Preserve log», воспроизвести проблему.
Найти запрос, соответствующий действию, посмотреть его статус, тело запроса и ответа.
Развилка: сервер вернул неверные данные или 5xx → дефект бэкенда; сервер вернул корректный ответ, а на экране пусто или неправильно → дефект фронтенда; запрос вообще не ушёл → дефект фронтенда (не сработал обработчик, упала валидация); запрос ушёл с неверными параметрами → тоже фронтенд.

Вкладка	Что смотрит тестировщик
Network	запросы, коды, тела, заголовки, время ответа, размер; троттлинг скорости сети; экспорт HAR для баг-репорта
Console	JS-ошибки и предупреждения — часто содержат готовую причину дефекта
Elements	вёрстка и стили, проверка текстов, состояний, атрибутов для автотестов
Application	cookies, localStorage, sessionStorage — проверка выхода из аккаунта и «протухания» токена
Device toolbar	эмуляция мобильных экранов и разрешений
Lighthouse / Performance	скорость загрузки, базовая доступность

Хороший приём для баг-репорта: сохранить HAR-файл (правый клик по списку запросов → Save all as HAR) и приложить к дефекту. Это снимает половину вопросов разработчика.

Вопрос 2: «Как тестировать кроссбраузерность и адаптивность? Что важнее?»

Что на самом деле проверяет интервьюер

Умеете ли вы приоритизировать вместо «проверю во всех браузерах и на всех устройствах».

Развёрнутый ответ

Первое, что стоит сказать: матрица покрытия строится не по личным предпочтениям, а по аналитике продукта. Открываем статистику посещений: если 60% трафика — мобильный Chrome на Android, а Safari на macOS даёт 2%, приоритеты очевидны. Дополнительно учитывают движки: Chrome, Edge и Opera построены на Chromium, поэтому реальных «семейств» три — Chromium, Firefox (Gecko) и Safari (WebKit). На iOS все браузеры используют WebKit, поэтому «Chrome на iPhone» — это по сути Safari.

Адаптивность проверяют по контрольным точкам вёрстки, а не по случайным ширинам. Точки берут из CSS проекта:

/* типичные breakpoints, которые стоит взять как тестовые ширины */
@media (max-width: 480px)  { /* телефон */ }
@media (max-width: 768px)  { /* планшет / крупный телефон */ }
@media (max-width: 1024px) { /* небольшой ноутбук */ }

Проверять надо ширину до и после точки перелома — та же логика граничных значений, что и в тест-дизайне: 479 и 480, 767 и 768. Чек-лист адаптивности: горизонтальная прокрутка не появляется, текст не обрезается и не наезжает, кнопки остаются нажимаемыми (минимум примерно 44 px по стороне), модальные окна помещаются на экран, работает поворот экрана, изображения не растягиваются.

Отдельно упомяните разницу между эмуляцией и реальным устройством: Device toolbar меняет размер вьюпорта, но не воспроизводит реальный движок, шрифты, жесты, клавиатуру и производительность. Критичные сценарии проверяются на настоящих телефонах или в облачных фермах устройств.

Типичные ошибки кандидатов

Говорят «проверю во всех браузерах» без приоритизации по аналитике.
Считают Chrome, Edge и Opera тремя независимыми браузерами — движок у них общий.
Не знают, что на iOS любой браузер работает на WebKit.
Тестируют адаптивность растягиванием окна мышью, не заглядывая в breakpoints проекта.
Прикладывают к багу скриншот, хотя в Network лежит готовый ответ сервера с текстом ошибки и request-id.
Путают вкладки: ищут ошибки JS в Network, а сетевые запросы — в Console.

Как ответить кратко

Чтобы понять, чей дефект, открываю Network и воспроизвожу проблему: если запрос вернул 5xx или неверные данные — это бэкенд; если ответ корректный, а на экране не то — фронтенд; если запрос вообще не ушёл или ушёл с неверными параметрами — тоже фронтенд. В Console смотрю JS-ошибки, в Application — cookies и localStorage, к багу прикладываю HAR-файл и request-id. Матрицу браузеров строю по аналитике продукта и по движкам: Chromium, Gecko и WebKit, помня, что на iOS все браузеры используют WebKit. Адаптивность проверяю по breakpoints из CSS проекта, беря ширины до и после точки перелома, а критичные сценарии — на реальных устройствах, потому что эмуляция не воспроизводит движок, жесты и производительность.