Тестирование с Devtools для тех, кто никогда не. Часть 1 — Elements

Что влияет на самооценку джуна-тестировщика? По нашему опыту, один из ключевых факторов – опыт работы с Devtools. Покажем, как мы применяем этот инструмент на практике при тестировании коммерческих проектов.

Для новичков в тестировании панель разработчика – она же Devtools – овеяна ореолом тайны. Ведь там бродят цветные строчки кода, виднеются три тысячи вкладок и даже есть страшное слово «Консоль»… В общем, это что-то на прогерском.

Не так страшна Devtools, как её малюют.

Эта статья – первая в нашем цикле публикаций о панели разработчика. В них мы на конкретных примерах постараемся показать, какие задачи может решать тестировщик с помощью Devtools.

А теперь – к делу!

Devtools (от англ. «development tools») — это инструмент веб-разработки, встроенный непосредственно в браузер. С его помощью можно отлаживать страницы и выявлять проблемы в работе сайта.

Как же попасть в Нарнию… в смысле в панель разработчика?

Горячие клавиши для вызова Devtools будут зависеть от операционной системы вашего устройства и браузера, которым вы пользуетесь. Самый простой и универсальный способ – открыть интересующий сайт и в любом месте щелкнуть правой кнопкой мыши. Нажмите в контекстном меню на кнопку «Посмотреть код»/ «Исследовать» – и появится Devtools.

Обратите внимание, что само расположение панели настраивается: ее можно закрепить слева, справа, внизу или открыть в отдельном окне.

Для примера мы возьмем Devtools в браузере Chrome. К февралю 2024 года он оценивается как самый популярный в мире – с колоссальным отрывом от остальных. Но даже если вы используете другой браузер, сможете сориентироваться – все панели разработчика обладают схожим функционалом.

В этой части речь пойдет о первой вкладке – Elements. Она содержит HTML-код страницы в виде структурированных тегов.

Elements – лучший друг тестировщика номер раз. Когда тестируете верстку – вам сюда. Ведь в Elements можно посмотреть HTML-код элементов, все применяемые (и игнорируемые) CSS-стили.

Рассмотрим случаи, в которых нам пригодится Elements.

Задача 1. Нужно оценить реализацию макета.

Это самое очевидное применение функционала Elements – проверить, совпадает ли сайт с макетом. Воспользуемся инспектором, чтобы выбрать интересующий нас элемент – во всплывающем окне появится основная информация о нем.

Дополнительно: откроем вкладку Styles и проверим все остальные параметры – будь то цвет, шрифт, отступы или бордер-радиус. Здесь же можно посмотреть, как выглядит на кнопке ховер- или актив-эффект. И тоже сравнить их реализацию с макетом, если необходимо.

Чем в данном случае полезна Elements? Разве отличия сайта от макета не видны просто на глаз? Чаще да, но не всегда.

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

Задача 2. При наведении на кнопку курсор не меняется на пойнтер.

В чем может быть дело – подскажет код этого элемента. Воспользуемся инспектором, чтобы выбрать интересующую нас кнопку. Откроем вкладку Styles и увидим, что в элементе наследуется дефолтный курсор и не прописана его замена на пойнтер.

Для сравнения можно взять другой кликабельный элемент на той же странице и посмотреть, как стили реализованы для него.

Дополнительно: можно самим добавить недостающее правило и убедиться, что оно корректно применяется.

Задача 3. Все страницы открываются в той же вкладке.

В рамках лучших практик считается, что как минимум любые юридические документы и соцсети должны открываться в отдельной вкладке.

Если на тестируемом сайте этого не происходит, скорее всего у таких элементов отсутствует атрибут target="_blank". Или он написан с опечаткой – всякое бывает при спешке в разработке :)

Задача 4. Нарушена кликабельность кнопок.

Ошибка может заключаться в верстке – например, кнопка перекрывается другими элементами. Чтобы это понять, нам снова пригодится инспектор из Elements – он показывает расположение блоков, из которых сверстана страница.

Другой проблемой может быть «неправильная» область кликабельности элемента. Например, ссылка может прикрепляться не непосредственно к кнопке, а ко всему блоку, в котором кнопка расположена. Это также можно отследить через инспектор или непосредственно в HTML-коде.

Из-за подобного строения страницы происходят мисклики – пользователь может случайно попасть в ненужный ему раздел или совершить ненужное действие, кликнув далеко за пределами кнопки. Такое поведение тоже стоит отнести к багам UX\UI.

Задача 5. Нужно проверить, как адаптируется верстка.

Верстка у современных сайтов меняется в зависимости от размера, разрешения и ориентации экрана. Это свойство называется адаптивностью.

Ширина, при которой один вариант отображения сайта преобразуется в другой, называется контрольной точкой, или брейкпоинтом. При создании макета дизайнер продумывает брейкпоинты и изображает, как сайт должен выглядеть на разных экранах.

А проверить, правильно ли задумка реализована на практике, можно с помощью Elements.

Например, в макете мы видим варианты главной страницы сайта: для монитора ноутбука и для вертикальной ориентации планшета. В первом случае – четыре блока в строке, в хедере есть кнопки. Во втором – два блока в строке, кнопки хедера исчезают.

Откройте сайт и нажмите тоггл для смены девайса в Elements. В выпадающем списке Dimensions выберите значение Responsive, чтобы получить возможность менять разрешение вручную. Если задать значения ширины, которые предусмотрены для ноутбука и планшета, будет ли сайт соответствовать макету?

Постепенно меняя ширину через стрелки, можно отследить, в правильной ли точке стоит брейкпоинт.

Еще к слову об адаптивности: в Elements можно заменить текст любого элемента и посмотреть, как ведет себя верстка. Растягивается ли блок по длине и ширине текста? Присутствует ли какое-то сокращение длинного текста, например, с помощью троеточия? Адаптируются ли шрифты страницы под разные алфавиты?

Откроем HTML-код блока, который хотим протестировать. Кликнем дважды на текст, чтобы включить режим редактирования. И добавим более короткий, длинный, англоязычный или какой угодно текст, отличный от написанного сейчас.

Магия рассеется в полночь – то есть с обновлением страницы, но этого бывает достаточно для проверки :)

Задача 6. Необходимо посмотреть, как сайт выглядит на разных разрешениях экрана.

Выше мы посмотрели на соответствие сайта заданным в макете брейкпоинтам.

Но если макета нет? Или адаптивность верстки в них никак не описана? Нам все равно стоит посмотреть, как сайт отображается на других мониторах.

Воспользуемся тем же тогглом для выбора кастомного разрешения.

Например, обладатели больших мониторов могут таким образом проверить, как сайт выглядит на маленьких экранах ноутбука – и наоборот.

Если нужно поменять местами высоту с шириной, то есть как бы «перевернуть» виртуальный экран – есть кнопка Rotate.

Еще можно воспользоваться предустановленными расширениями экранов, выбрав в списке Dimensions конкретный планшет или смартфон. Но здесь нужно сделать важный дисклеймер: никто не гарантирует, что на реальном устройстве отображение сайта будет точно таким. Если необходимо проводить кроссплатформенное тестирование, лучше воспользоваться реальными устройствами или хотя бы более надежными эмуляторами.

Конечно, это далеко не все баги, которые можно локализовать с помощью Elements. Скорее нам хотелось показать, чем может быть полезна эта вкладка в процессе тестирования, и заодно развеять миф о том, что Devtools – что-то страшное и непонятное :)

Если хочется попробовать свои силы в решении конкретных задач по тестированию, можно воспользоваться нашим бесплатным тренажером по Devtools.

А в комментариях напишите, что самое трудное для вас в работе с Devtools – мы постараемся разобрать эти моменты в следующих публикациях ♥