Тестирование с Devtools для тех, кто никогда не. Ч.3 – остальные вкладки
Когда только осваиваешь азы тестирования, бывает непонятно – зачем не-программисту в принципе нужна Devtools. Окей, там лежит код, убегают вдаль запросы, складируются кэш и куки…. Но к чему это всё ручному тестировщику? Расскажем в этой статье :)
Сегодня речь пойдет сразу о нескольких вкладках: Console, Sources, Application.
Рассмотрим конкретные случаи, в которых эти вкладки пригодятся тестировщику — все кейсы взяты из нашей практики на проекте «Джуны».
Первое. Console
Console показывает работу JavaScript на странице.
JavaScript, сокращенно JS, – это скрипты, которые приводят в движение анимацию на сайте, обеспечивают красивые переходы по кнопкам, отвечают за плавный автоскролл по странице или выполняют любой другой каприз. А главное — именно в скриптах прописываются методы, которые отправляют запросы на сервер и позволяют сайтам с клиент-серверной архитектурой функционировать. Наглядно это можно отследить в столбике Initiator вкладки Network – там указано, какой код вызвал тот или иной запрос. Для запросов на сервер это JavaScript.
Но вернемся к Console. Получается, что консоль – это журнал (по-айтишному – логи) выполняемых на странице скриптов. Сюда попадают информационные сообщения, предупреждения и сообщения об ошибках JS.
А еще в консоли можно увидеть ошибки, связанные с загрузкой изображений, стилей и других ресурсов страницы.
Скриншоты из консоли с логами JavaScript можно и нужно прикладывать к баг-репортам – разработчику будет легче пофиксить локализованный баг с точными данными об ошибке.
Задача 1. Определенный функционал не работает, но пользователю об этом не сообщается.
Такое случается довольно часто, разработчики в спешке могут просто забыть добавить уведомление для пользователя на фронтенде. А вот в консоли ошибка отобразится.
Задача 2. Необходимо составить рекомендации по оптимизации.
«Побочный эффект» от наблюдений за консолью – начинаешь замечать, какие скрипты регулярно выдают ошибку. Можно поговорить об этом с разработчиком – возможно, скрипты устарели или не используются. Страница будет грузиться и работать быстрее, если избавлять ее от такого мусора.
Важно: в консоль могут попадать ошибки, не связанные с сайтом как таковым. Например, уведомление The message port closed before a response was received означает, что нарушена работа расширения в браузере.
Тестируемый сайт и наши родные разработчики тут не при чем. Поэтому проводить проверки предпочтительно в режиме инкогнито.
Второе. Sources
Вкладка Sources выводит список файлов, из которых построена страница. И – о ужас! – эти файлы даже можно редактировать.
Sources нужнее программисту, чем тестировщику – она по сути представляет собой встроенную среду разработки (IDE). Но её можно использовать и при тестировании, давайте посмотрим как.
Задача 1. Нужно выявить неиспользуемый код.
Неиспользуемые скрипты и стили могут серьезно мешать работе: они расходуют трафик и тормозят загрузку страницы вплоть до того, что пользователи могут отказаться от услуг такого сайта. В Sources есть отдельный инструмент для обнаружения лишнего кода на странице.
Нажмите на кнопку Coverage в нижней части панели. Затем – на круглую стрелку. Через несколько секунд появится подробный отчет.
В колонке Unused Bytes подсчитаны байты кода, которые не используются на странице. Справа – они же, но уже в виде графика. Красные полосы – визуализация неиспользуемого объема кода.
Также на каждую строчку можно кликнуть, чтобы посмотреть, какие именно части кода в каком файле не используются.
Задача 2. Вам нужно поменять элементы сайта так, чтобы изменения сохранялись после перезагрузки.
Задача со звездочкой. В первой части мы научились менять содержимое страницы в моменте через вкладку Elements. Но что делать, если изменения должны сохраняться при работе со страницей и после перезагрузки?
Ответ прост — подменить содержимое можно локально через вкладку Sources.
Откройте вкладку Sources, затем – Overrides. Нажав на плюсик, вы сможете выбрать папку, куда будут сохраняться вносимые вами изменения. Важно после добавления папки дать панели разработчика доступ к этой папке.
После этого отыщем во вкладке Elements ту часть страницы, которую хотим изменить. Копируем класс элемента, возвращаемся в Sources и выбираем поиск по всем файлам.
Найдя элемент, вы можете внести в него желаемые изменения – будь то стиль или текст. После этого нажмите ctrl/cmd + S для сохранения – обратите внимание, во вкладке Overrides появился новый файл со светящейся точкой. Теперь он будет подменять собой изначальный ресурс для сайта.
Созерцаем результат, который не покинет нас даже после перезагрузки страницы <3
Третье. Application
Во вкладке Application хранятся те самые кэш и куки, по поводу которых нас вечно тормошат уведомления на сайтах. Протестировать можно и их.
Задача 1. Необходимо проверить, что без авторизационных куки происходит выход из профиля.
Тут все просто: нужно авторизоваться на сайте, открыть вкладку Application и найти куки, связанные с авторизацией.
Удаляем их либо индивидуально (через правую кнопку мыши), либо чистим все данные на вкладке Storage.
Как только куки исчезнут – должен автоматически произойти выход из профиля.
Задача 2. Нужно протестировать бэкенд (внезапно).
Если на сайте предусмотрены разные роли, то для тестирования API могут пригодиться токены пользователей с разным уровнем доступа.
Например, у нас есть модератор, и только ему доступен просмотр результатов конкурса. Получается, чтобы проверить ручку вывода этих результатов, нам необходимо достать токен модератора из вкладки Application и скопировать токен в авторизацию запроса в Postman (или в другую программу, где мы работаем с бэкендом).
Заодно можно проверить, насколько токен отвечает требованиям безопасности: есть ли у него срок давности? Можно ли воспользоваться ручкой без токена вовсе?
Задача 3. Надо удостовериться, что новым пользователям приходят положенные уведомления, а старых пользователей не донимают одними и теми же вопросами.
Если на сайте используются рекламные или любые другие всплывающие уведомления, может быть полезно проверить, что они показываются всем новым пользователям и не надоедают тем, кто пользуется сайтом давно.
Для этого также откроем Application и найдем куки, отвечающие за всплывающую рекламу или другую информацию. Если их удалить, соответствующие сообщения должны появиться снова.
И наоборот – даже если мы не взаимодействуем с всплывающими окнами, но устанавливаем значение true у куки просмотра этих окон, информация перестает появляться.
Например, новым пользователям показывается предупреждение об использовании куки. Пока пользователь не нажмет на крестик и не покажет, что он видел это предупреждение – всплывающее окно так и будет его преследовать :)
Попробуем, не нажимая на крестик, вручную вписать куки, которые должны сообщить системе: «Пользователь все прочитал».
Уведомление исчезнет, как только система получит соответствующие куки.
Бонус. Lighthouse
Это встроенный инструмент для оценки качества веб-страницы, очень схожий с PageSpeed (который, как и Chrome, разработан Google).
Главная цель Lighthouse – помочь с оптимизацией сайта. Он собирает весь неиспользуемый код, сообщает о перекрытии элементов, устаревших форматах файлов и других уязвимостях.
Грубо говоря, для ручного тестирования здесь мало простора. Но через отчет Lighthouse можно выявить основные проблемы с сайтом и получить конкретные рекомендации для улучшения. А кто как не тестировщик может донести эти ценные мысли до руководства и dev-отдела :)
Итого
Конечно, функционал панели разработчика далеко не исчерпывается этими кейсами. Мы просто надеемся, что с нашими примерами и лайфхаками Devtools стал чуть более понятным и ручным зверем для начинающих тестировщиков.
Если хочется практики, то можно воспользоваться бесплатным тренажером или поучаствовать в тестировании реального проекта в Джунах.
Остаемся на связи <3
Что важно учитывать и с какими неожиданными сложностями вы можете столкнуться при создании и внедрении UI-кита? Делюсь опытом нашей команды: как косячили, ругались и делали выводы.
Привет, ребята! Сегодня поговорим о том, как сделать тестирование пользовательского интерфейса (UI) максимально гладким и избежать распространенных ошибок.
Рынок маркетплейсов динамично меняется, и для того, чтобы быть успешным селлером, нужно постоянно адаптироваться к новым условиям. Весна 2025 года принесет свежие тренды, которые повлияют на продажи, логистику и маркетинг. Разбираем, что будет актуально в ближайшие месяцы и как подготовиться к сезону.
В статье разберу, как протестировать интерактивные прототипы с помощью Pathway. Это относительно новый сервис, который уже внедрили дизайнеры ВкусВилл, Циан и VK.
У вас новый сайт (или приложение, или какой-то другой диджитал-продукт). Вы хотите убедиться, что клиентам он понравится, и вообще, что пользоваться им удобно. Вы заказываете UX-тестирование у сторонней компании, они предлагают правки, вы идете с этими правками в агентство, которое разработало сайт, оно вносит правки и… сайт становится хуже. Как та…
☄ Отрасль Market Research & Insights развивается очень бурно, и нам важно видеть основные направления, чтобы не остаться на обочине.
Когда я начинал разбираться в продукте, A/B тесты казались чем-то из серии: «Сейчас разберёмся, что там сложного». Идея простая: запускаешь тест, смотришь результаты, делаешь выводы.
Картинка с куками просто жиза 😄😄😄
💯
какая следующая подборка?)
Раздумываем над циклом статей про Postman :)
классный тренажер у вас, уже пробовала работать с ним)
Ахахаахах, с первого мема меня вообще вынесло, не мог даже дочитать статью, возвращался к мему и смеялся, ну жиза!
Оч доступно всё, круто и легко написано. Если б я только начинала, мне б зашла такая подача материала 👍