Как проходит проверка через DevTools

Процесс проверки веб-приложения через DevTools

Проверка через Инструменты разработчика (DevTools) — это одна из фундаментальных практик в работе QA-инженера, особенно при тестировании frontend. Этот процесс систематичен и многослоен. Я рассматриваю его как последовательность шагов, направленных на проверку корректности, производительности и безопасности рендеринга веб-страницы.

1. Открытие DevTools и навигация

Первым делом необходимо открыть DevTools. Стандартные способы:

• Горячие клавиши: F12 или Ctrl+Shift+I (Cmd+Opt+I на macOS).
• Контекстное меню: «Просмотреть код» или «Исследовать элемент».
• Меню браузера: Часто в разделе «Дополнительные инструменты».

После открытия ключевой шаг — выбор вкладки, соответствующей цели проверки.

2. Ключевые вкладки и их применение в QA

Вкладка Elements (Инспектор)

Это основной инструмент для проверки DOM и CSS. Здесь я:

• Инспектирую и валидирую верстку: Навожу курсор на элементы в DOM-дереве, чтобы визуально выделить их на странице. Это помогает быстро найти «сломанный» или неправильно расположенный элемент.
• Редактирую HTML/CSS в реальном времени: Могу изменять атрибуты, классы или стили, чтобы проверить, как UI отреагирует на разные состояния, данные или разрешения экрана. Например, симулирую состояние :hover или :disabled.

  /* Пример: Быстрая проверка адаптивности через изменение стиля */
  .my-button {
      /* Временно меняю display для проверки поведения */
      display: none;
  }
  

• Проверяю accessibility (a11y): В современных DevTools есть раздел «Accessibility» в панели Computed Styles, показывающий вычисленные ARIA-атрибуты, контрастность текста (что критично для проверки WCAG).

Вкладка Console (Консоль)

Консоль — это «окно» в JavaScript-мир страницы.

• Логирование и отладка: Проверяю, нет ли ошибок (Errors) или предупреждений (Warnings), которые выводят разработчики или фреймворки. Красные ошибки Uncaught TypeError — прямые указатели на баги.
• Взаимодействие с API: Могу выполнять JavaScript-код для проверки состояния приложения. Например, получить значение глобальной переменной или симулировать действие.

  // Пример: Проверка наличия токена авторизации в localStorage
  console.log('Auth token exists:', !!localStorage.getItem('userToken'));
  // Пример: Быстрый вызов функции из глобальной области видимости
  window.app.updateCartItemCount(5);
  

Вкладка Network (Сеть)

Наиболее мощный инструмент для проверки backend взаимодействий.

• Мониторинг запросов: Вижу все HTTP/HTTPS-запросы: XHR (API), Fetch, документы, скрипты, стили. Фильтрую по типу (XHR для API-вызовов).
• Анализ запросов и ответов:

    *   **Headers:** Проверяю корректность отправляемых заголовков (Authorization, Content-Type).
    *   **Payload:** Смотрю, правильно ли отправляются данные (тело запроса при `POST/PUT`).
    *   **Response:** Анализирую данные, пришедшие с сервера, их структуру и корректность.
    *   **Status Codes:** Отслеживаю коды ответов. Ответ `500` или `404` на критичный API-вызов — явный дефект.

• Тестирование производительности и условий: Использую вкладку Network Conditions для эмуляции медленного соединения (3G) или отключения кэша. Анализ вкладки Timing помогает найти «долгие» запросы.

Вкладка Application (Приложение)

Здесь проверяется клиентское хранилище и манифест.

• Local Storage, Session Storage, Cookies: Просматриваю, изменяю или удаляю ключи и значения для тестирования различных сценариев авторизации, персистентности данных.
• Service Workers & Cache Storage: Проверяю работу PWA, кэширование ресурсов в Cache API.
• IndexedDB: Для сложных клиентских баз данных могу провести инспекцию.

Вкладка Sources (Источники)

Используется для продвинутой отладки JavaScript.

• Точки останова (Breakpoints): Устанавливаю их в коде, чтобы отследить выполнение скрипта шаг за шагом, проверить значения переменных в Call Stack в момент срабатывания конкретного обработчика события.

Вкладка Performance (Производительность) и Lighthouse

• Performance: Записываю сессию взаимодействия с приложением (например, открытие модального окна). Анализирую временную шкалу: загрузку, выполнение скрипта (Scripting), рендеринг (Rendering), отрисовку (Painting). Ищу «длинные задачи» (Long Tasks), которые блокируют главный поток.
• Lighthouse: Запускаю встроенный аудит для проверки производительности, доступности, SEO и лучших практик. Получаю структурированный отчет с рекомендациями. Это часть проверки нефункциональных требований.

3. Стратегия и лучшие практики при проверке

1. Четкая цель: Перед открытием DevTools я определяю, что именно проверяю: UI-баг, ошибку в консоли, медленный API-запрос или проблему с хранилищем.
2. Воспроизведение дефекта с открытой консолью: Многие ошибки JS видны только в момент взаимодействия.
3. Использование мобильной эмуляции (Device Toolbar): Для тестирования responsive верстки и эмуляции различных устройств, разрешений, touch-событий.
4. Фильтрация и поиск: На вкладке Network или в DOM-дереве активно использую фильтры (Filter в Network, Ctrl+F в Elements).
5. Создание воспроизводимых сценариев: Для передачи разработчику я точно фиксирую:

    *   Шаги воспроизведения.
    *   Ошибку в консоли (с текстом и стектрейсом).
    *   Неправильный сетевой запрос/ответ (скриншот вкладки Network).
    *   Состояние DOM/CSS в момент ошибки.

Таким образом, проверка через DevTools — это не пассивное наблюдение, а активный исследовательский процесс. Компетентное использование этих инструментов позволяет QA-инженеру не просто находить поверхностные баги, но и глубоко анализировать их первопричину, локализовать проблему (frontend/backend) и предоставлять разработчикам детальную и ценную диагностическую информацию, значительно ускоряя процесс исправления. Это навык, превращающий тестировщика из регистратора дефектов в полноценного технического расследователя.