как узнать верстку сайта
Тестировать верстку? Легко
Статья подготовлена Анной anna-che и Ксенией KseMish.
Одной из причин, по которой мы активно взялись за тестирование верстки, стали, как обычно, грабли. Мы с размаху наступили на баг, который стал проявляться после очередного обновления Хрома. Оказалось, что в течение 3-х часов пользователи не могли осуществить перевод средств со счета через личный кабинет нашего интернет-банка. А все из-за того, что в новой версии браузера форма перевода средств с одного счета на другой уехала за пределы окна.
Подобные баги бывают и безобидными. Например, всем известный бренд одежды также наткнулся на эти грабли. Благодаря недостаточному тестированию верстки, пользователи сайта этого бренда вместо кнопки «Узнайте больше» долгое время видели «Узнайте боль…».
Надпись на кнопке, конечно, близка к истине, цены там — реально боль, но это явно не то, что задумывалось создателями сайта. В общем, такие моменты надо отслеживать и исправлять, вне зависимости от того, что они вызывают — неудобство или улыбку.
Осознавая эти проблемы, мы применили практику обязательного design review со стороны наших продуктовых дизайнеров, но не тут-то было. Оказалось, что не во всех командах есть выделенный дизайнер, или у них не хватает времени, или, что еще страшнее, фронт и дизайнер не могут прийти к общему подходу к верстке той или иной страницы, формы или элемента.
Недолго думая, мы отправились искать варианты, как мы можем минимизировать как количество дефектов верстки, так и противостояний «Фронт VS дизайнер». Изучив возможные практики и инструменты для автоматизации тестирования верстки и насобирав шишек, мы внедрили следующий подход.
Коротко о нас:
Сейчас мы разрабатываем единый продукт, над которым трудятся более 20 скрам-команд, каждая из которых отвечает за определенную функциональность, при этом мы стараемся сохранить единый стиль и дизайн самого продукта — визуальную подачу, расположение основных элементов и т.д.
Относительно распределения пользователей по браузерам, на сегодняшний день наши пользователи используют (значения округлены):
Для начала мы захотели решить проблему с договоренностями между фронтом и дизайнером. На начальном этапе формирования макета функциональности фронт и дизайнер совместно описывают «Контракт». В этом контракте они описывают все договоренности по расположению элементов, их стилей, расстоянию и т.д. Благодаря этому при обнаружении несовпадений макета со сверстанной страницей ребятам не придется долго выяснять, кто прав, а кто виноват.
Описывают они свои договоренности в galen-spec файле.
Что такое galen-spec?
Логически, его можно поделить на две части:
1. object definitions
Тут нам надо обязательно указать, какие объекты есть на нашей странице — header, footer, меню, контент и т.д. В общем, перечисляем основные элементы, которые будем проверять, даем им названия и определяем локаторы.
@objects — элементы на странице (можно использовать CSS, XPATH, ID)
2. Когда определили локаторы, надо определить стили и спецификации конкретных объектов. Для этого используется часть спецификации object specs, где мы подробно описываем, например, что наш блок текста (description-text) находится внутри формы описания, ниже хэдера и содержит определенный текст.
Main section — для каждого описанного элемента в @objects описываются параметры проверки.
* язык galen spec чувствителен к отступам в main section, поэтому обращайте на это особое внимание и соблюдайте табуляцию 🙂
Таким образом, «Контракт», заключенный между фронтом и дизайнером и перенесенный на язык Galen, позволяет нам автоматизировано проверить расположение и внутреннее содержание элементов, а также адаптивность и кроссбраузерность.
Пример быстрого старта
Разница в отчетах выглядит следующим образом:
Здесь видим, что проверка не прошла, изображения отличаются более чем на 10% и все эти цветные различия, кроме заливки черным цветом, это и есть разница между элементами.
Если элементы полностью идентичны, разница будет отображаться черным цветом.
Самый частый вопрос, где вообще взять эталонный скриншот?
Ответ: Эталон мы берем либо у дизайнера, либо прогоняя тесты на продовском окружении, которое считаем эталонным. Получаем оттуда картинки наших блоков, которые будем сравнивать, и кладем их в папочку images, откуда спецификации будут выдергивать на них ссылки.
К чему мы пришли, используя этот подход
О технических аспектах работы с Galen Framework, его возможностях и основных проверках мы рассказали на прошедшем Selenium Camp, и еще напишем в блоге.
Возможность использовать galen-spec и новые шаги по проверке верстки мы вынесли в нашу библиотеку Akita, где есть шаблон для быстрого старта, а также мы ведем телеграм-чатик, где вы можете задать интересующие вас вопросы.
Как проверить верстку сайта
Верстку сайта нужно проверять по нескольким направлениям:
Обо всем по порядку.
Наличие ошибок в верстке сайта
Самое простое и быстрое, что Вы можете сделать для проверки, посмотреть ошибки верстки прямо в браузере. Нажмите клавишу F12, откроется панель разработчика.
Если ошибки есть, то справа красным цветом будет отображаться их количество. Посмотреть, что это за ошибки можно здесь же на вкладке Console. Ошибки нужно исправлять. Они могут влиять, как на работу сайта, так и на выдачу в поисковых системах.
Валидность верстки сайта
Иногда не получится исправить абсолютно все ошибки, указанные валидатором validator.w3.org, так как некоторые могут присутствовать в подключаемых сторонних плагинах. Но нужно стараться свести ошибки к минимуму.
Проверять нужно каждую типовую страницу сайта. Например, если у Вас интернет-магазин, проверьте главную страницу, какую-нибудь одну страницу товара, одну страницу категории и далее по такому же принципу. Те страницы, которые не участвуют в поиске, проверять необязательно.
Кроссбраузерность верстки сайта
Для проверки кроссбраузерности сразу в нескольких браузерах и различных их версиях существуют специальные сервисы.
Адаптивность верстки сайта
Современная верстка должна быть адаптивной под различные размеры экрана. Сайт должен корректно отображаться на мобильных устройствах. При просмотре сайта все смысловые блоки страницы выстраиваются в один столбик, а не самые важные элементы скрыты с возможностью их отображение по кнопке.
Быстро проверить адаптивность можно так: просто постепенно уменьшайте браузер по ширине. Вы увидите, как перестраиваются блоки сайта. Чтобы видеть, какие в данный момент размеры окна, нажмите клавишу F12, и после этого меняйте размеры браузера.
Кроссплатформенность верстки сайта
Задавайте вопросы по верстка в комментариях.
Как проверить вёрстку сайта? Пошаговый чек-лист
55 шагов к идеальной верстке. Чек-лист по тестированию и оптимизации HTML-верстки сайта.
1. Кроссбраузерность
Базовое правило верстки сайта — кроссбраузерность. Это подразумевает под собой корректное отображение сайта во всех современных браузерах.
Старые браузеры
Для приемлемой работы сайта в старых версиях браузеров необходимо либо разработать отдельную облегченную версию, либо, если сайт становится абсолютно непригодным для восприятия, выводить уведомление о предложении скачать более новую версию браузера.
2. Разрешения экрана
Подготовьте страницы для корректного отображения при разных разрешениях экрана.
3. Мобильные устройства
Важно ли адаптировать сайт для мобильных устройств?
В 2019 году не меньше 75% трафика приходится на мобильные устройства, поэтому чрезвычайно важно проверить работу сайта на смартфонах и планшетах. Проверяем верстку в landscape- и portrait-режимах (вертикально и горизонтально).
4. Базовые проверки вёрстки сайта
5. Валидность
Тестирование на валидность позволяет обнаружить и исправить очевидные недоработки, а также сделать верстку более правильной с точки зрения стандартов HTML и CSS. Важно понимать, что не все технические решения могут быть одобрены валидаторами, поэтому использовать эти инструменты надо в рамках разумного.
Тестируем вёрстку правильно
Что не так с тестированием вёрстки
Мы часто им пренебрегаем. Написание функциональных, интеграционных и юнит-тестов давно стало повсеместной практикой. Вёрстке мы обычно уделяем гораздо меньше времени.
Проблема тестирования вёрстки в том, что только живой человек может сказать, хорошо свёрстан блок на странице или нет. Поэтому чаще всего мы тестируем HTML и CSS вручную: проверяем, как будет вести себя блок, если в нем будет слишком много (или слишком мало) текста или дочерних элементов; смотрим, чтобы все возможные варианты отображения блока смотрелись корректно; помним о том, как блоки должны адаптироваться к разным устройствам и разрешениям экрана.
Как тестировать вёрстку правильно
Нам не нужно придумывать ничего нового. Мы можем применить те же подходы, которые используем при написании автотестов.
Сначала нужно посмотреть на требования, дизайн. На основе этого составить список всех значимых состояний приложения, которые нужно проверить. Далее, дело за малым — проверить каждый тест-кейс.
В статье я расскажу, как мы создали для себя Makeup, как изменили свой процесс разработки интерфейсов и как это упростило нам жизнь.
Makeup — графический интерфейс для быстрого и комфортного ручного регрессионного тестирования вёрстки, основанной на методологии BEM. Это инструмент, для которого мы готовим тестовые данные так, чтобы можно было проинициализировать любой независимый блок с разными данными и быстро посмотреть его во всех интересующих нас состояниях.
Описанный подход может помочь, если на вашем проекте соблюдаются 2 условия:
Как измерить качество вёрстки
Первая версия Makeup (тогда у него ещё не было имени) возникла в файле spec/index.html. На этой странице прогонялись юнит-тесты по всем модулям (читай: блокам) нашего приложения. Всё было традиционно: мы инициализировали каждый модуль с разными наборами тестовых данных и проверяли тестами то, что нас интересовало.
Но этого было недостаточно. Несмотря на то, что эти тесты были сильно связаны с вёрсткой, они не могли ответить на вопрос, хорошо ли свёрстан модуль и правильно ли он будет вести себя в разных обстоятельствах.
В сети можно найти огромное количество чек-листов на качество вёрстки. Проверку многих пунктов из них можно легко поручить анализаторам кода. Но обычно эти чек-листы проверяют качество работы по косвенным или нерелевантным признакам.
По большому счету, критериев качества вёрстки всего два:
Как проверить соответствие макету
Сравнить вёрстку с исходным макетом и найти отличия. Но это порой не так просто. Помните, в детских журналах были головоломки «найди 10 отличий»?
Любой инженер мгновенно предложит очевидное решение, как проще находить отличия. Достаточно наложить одно изображение на другое и верхнее изображение сделать полупрозрачным.
Можно сделать ещё удобнее — инвертировать цвета для верхнего полупрозрачного изображения. Тогда при идеальном совпадении мы должны увидеть однородный серый фон.
Зачем для этого специальный инструмент
Для реализации подобной задумки не нужен специальный инструмент. Если нужно сравнить вёрстку с исходным дизайном страницы сайта, то такой подход можно реализовать прямо в браузере.
1. Добавляем картинку с макетом
2. Позиционируем поверх свёрстанной страницы
По такому принципу работает огромное количество существующих инструментов:
В чём же проблема
Этот подход применим только в том случае, когда при разработке мы можем построить однозначное соответствие между макетами и страницами верстки.
На деле мы всё чаще работаем со сложными веб-приложениями. И обычно мы не используем термин «страница». В привычных нам терминах веб-приложение с точки зрения вёрстки состоит из произвольного набора BEM-блоков и их состояний.
Состояние блока — это его конечное отображение при определенном наборе элементов, модификаторов и при определенном контенте. Другими словами, каждое состояние блока — это один кейс его использования.
На практике это значит, что если, к примеру, у вас на проекте всего 100 независимых блоков, и для каждого из них предусмотрено всего 10 значимых кейсов использования, то вам придется помнить о 1000 уникальных состояний вашего приложения.
Можно разбивать вёрстку на блоки поменьше, уменьшая количество состояний в каждом, но порядок числа вряд ли сильно изменится.
1000 состояний — это очень много. Ни один человек не в состоянии удержать всё это в голове. И тем более быть уверенным в качестве вёрстки каждого блока.
Как я делал раньше
Раньше при разработке сложных блоков с большим количеством состояний для сравнения верстки отдельного блока с дизайном я использовал невероятно медленный способ.
Эту последовательность можно научиться выполнять по-настоящему быстро, но процесс всё равно будет занимать огромное количество времени. Но такой подход никогда не даст уверенности при регрессии или рефакторинге. Да и заниматься подобной ерундой не хочется.
Как мы сделали ещё один инструмент
Мы не нашли инструмент, который бы нам позволил в любой момент времени…
Сначала мы добавили сравнение с дизайном на страницу с юнит-тестами. Затем добавили пару ползунков для управления отображением блоков. А со временем всё это переросло в отдельный интерфейс, который стал основой рабочего процесса разработки интерфейсов в нашей команде.
На этой иллюстрации почти все возможности Makeup. Это невероятно простой инструмент.
Что нужно для реализации
Вы можете решить, что написание и поддержка актуальных конфигурационных файлов — немыслимая задача. При разработке приложения мы хотим, тратя минимальные усилия на описание структуры блоков, иметь инструмент, который поможет держать под контролем всю вёрстку. Для того, чтобы решить эту задачу, надо тесно интегрировать такой подход со сборкой вашего приложения.
Наша команда почти полностью собирает конфигурацию автоматически на основе имеющихся тестовых данных. Вручную остается дописать только «заплатки» стилей, сниппеты и ссылки на документацию. На этапе сборки приложения формируются все необходимые конфигурационные файлы и создаётся отдельный порт, на котором запущен Makeup. 
Как можно использовать
В нашей команде Makeup — основа разработки интерфейса приложения. Мы активно используем его на всех этапах жизни блока.
Если своевременно добавлять все необходимые тест-кейсы и использовать Makeup на всех этапах разработки, можно спать спокойно — никаких неожиданных неприятностей ваша вёрстка вам не принесет.
Как подобрать тест-кейсы
В начале статьи я использовал термин «значимые состояния». Пора рассказать о том, как мы в работе выбираем значимые кейсы и как пытаемся обеспечить хорошее покрытие для вёрстки.
Мы пришли к выводу, что достаточно фиксировать 3 типа состояний.
Можем ли мы перестать тестировать вёрстку руками
Если нам важно точное соответствие исходному дизайну, к сожалению, нет. Но в наших силах сделать тестирование вёрстки комфортным, быстрым и надежным.
Поэтому мы сделали для себя простой и удобный инструмент. По большому счету он просто выводит те данные, которые мы сами сохраняем в конфигурационных файлах блоков. Но несмотря на кажущуюся простоту, для нашей команды Makeup стал основой рабочего процесса разработки интерфейсов. С его помощью мы всегда знаем о самочувствии проекта и можем в любой момент увидеть полную картинку проекта с точки зрения вёрстки.
Как проверить верстку сайта
Дата публикации: 2015-12-14
От автора: у вас в руках файлы с версткой. Но как проверить ее качество? Какие инструменты существуют для тех, кто не разбирается в HTML и CSS? Какими полезными вещами стоит пользоваться самому верстальщику? Эта статья попробует ответить на эти вопросы.
Почему важно проверять качество верстки
Вопрос, который волнует как заказчиков, так и самых верстальщиков. Первые так могут убедиться в том, что исполнитель выполнил свою работу качественно. Верстальщику же полезно будет проверить верстку сайта перед тем, как посылать ее на одобрение клиента. Это позволит экономить время, иначе может возникнуть ситуация, когда правки придется вносить уже после сдачи проекта. Если вы сами создаете свой сайт, инструменты проверки тоже вам пригодятся.
Инструменты для проверки
Отладчик. Один из самых простых способов, как можно проверить верстку сайта – включить отладчик. Он запускается при нажатии в браузере F12. Этот инструмент помогает увидеть, как изменится вид страницы, если из нее убрать какие-то элементы или стили. Например, вы прописали какое-то новое CSS-свойство, потом прописали еще несколько. Решили посмотреть, как все это будет выглядеть в браузере.
Оказалось, что элементы отображаются не так, как планировалось. Из-за какого свойства произошла такая ошибка? Вручную это определять долго. В отладчике же вы можете быстро отключить любые стили и быстро обнаружить ошибки. Также в нем хорошо видно опечатки. Большинство опытных верстальщиков ищут ошибки именно с помощью отладчика, а не самостоятельно просматривая код.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Рис. 1. С отладчиком находить ошибки проще
W3C Валидатор. Сервис проверки кода на мелкие ошибки. W3C – это организация, которая занимается разработкой и официальной поддержкой веб-стандартов. Поскольку она устанавливает эти стандарты, на ее сайте есть специальный сервис, который может проверить любую страницу в сети на валидность (то есть на ошибки). Нужно сказать, что это достаточно строгий валидатор.
Часто им пользуются заказчики, пытающиеся так определить качество верстки. Даже в хорошо сверстанной страничке валидатор может найти более тридцати ошибок. Однако в этом нет ничего страшного. Сервис считает за ошибку даже то, что вы не поставили пробел перед значением html-атрибута. А теперь представьте, что в таком стиле вы написали весь код. У вас будут сотни ошибок, но на самом деле верстка будет выполнена правильно, просто вы нарушите стандарты, которые W3C установили на счет правильного написания кода.
Подробнее с этими правилами можно ознакомиться на сайте W3C. По сути, единственный сайт, который валидатор проверяет без ошибок, это сайт самой W3C. Поэтому не стоит исправлять все ошибки. И все-таки валидатор может указать на какие-то серьезные проблемы, поэтому проверка верстки сайта в нем желательна. validator.w3.org — валидатор.
IE Tester. Существует такая программа, которая позволяет протестировать сайт в старых версиях Internet Explorer. Многие заказчики сегодня все еще требуют поддержку этого браузера, чтобы сайт в нем отображался так же, как и в других. Возможно, сейчас уже есть онлайн-сервисы, в которых можно выполнить аналогичную проверку. В любом случае, вам достаточно вставить нужный код и программа покажет, как все это отображалось бы в IE 6, 7 и 8.
Обычно поддержка шестой версии уже никому не нужна, а восьмая может вести себя вполне адекватно если, конечно, в вашей верстке не присутствуют новые CSS-свойства. У старых версий IE есть интересная особенность – они читают закомментированный код. Поэтому в одном из комментариев можно подключить таблицу стилей, которая будет создана специально для старых версий этого браузера.
Остальные браузеры просто пропустят этот фрагмент. Такой способ можно использовать, если вам действительно очень сильно нужна поддержка IE.
Другие сервисы. В последнее время сервисов для проверки верстки становится все больше и больше. Нет смысла останавливаться на каком-то отдельном. Большинство этих сервисов работают неплохо, но все равно не проверяют все досконально.
Как проверить адаптивную верстку
Отдельно стоит разговор об адаптивной верстке. Наилучшим вашим инструментом в этом деле будет обычное окно браузера. Просто уменьшайте ширину окна и наблюдайте, как меняется дизайн. Если вы видите, что появляется горизонтальный скролл или какие-то элементы не влазят на страничку, значит, ваша верстка далека до идеала и ее нужно дорабатывать. Если вы хотите увидеть, как будет себя вести сайт на большом экране – уменьшите масштаб. Конечно, если у вас есть планшет и телефон, то можно загрузить вашу верстку на какой-нибудь бесплатный хостинг и зайти на сайт с этих устройств.
Рис. 2. Изменение ширины окна браузера – самый простой способ проверить адаптивность.
Кроссбраузерность
Чем еще проверить верстку сайта? Обязательно должна быть проверка на кроссбраузерность. Нужны открыть сайты в различных браузерах и посмотреть, как они там выглядят. Можно изменять масштаб и размер шрифта. Вы должны убедиться, что хотя бы у большинства пользователей все будет нормально. Если вы проверяете вручную, то можете также попросить знакомых проверить верстку в их браузерах, если их версии отличаются от ваших. Здесь можно дать еще один совет – не используйте слишком специфических свойств, которые поддерживаются только в каком-то одном браузере. А если уже используйте, придумывайте для них какую-то альтернативу в других браузерах. Для некоторых свойств все еще нужно использовать вендорные префиксы. Это связано с тем, что веб-стандарты постоянно развиваются и все браузеры не могут поддерживать всего. Но если уже делать проверку на кроссбраузерность, то делать ее как минимум для таких браузеров: Chrome, Mozilla, Opera, Safari, IE.
Есть очень хорошие зарубежные сервисы продвинутой кроссбраузерной проверки. Например, browserstack.com. Такая проверка может стоить вам денег. Если у вас действительно очень крупный проект и вы хотите досконально проверить его, в таком случае есть смысл пользоваться подобными сервисами.
Проверка на соответствие с макетом
Проверить верстку можно еще так: скриншот сверстанного сайта необходимо добавить к макету в фотошопе в качестве нового слоя. Установить этому слою прозрачность и посмотреть, насколько отображение элементов совпадает с макетом. Для этого можно использовать специальный плагин. Например, Pixel Perfect для Mozilla.
Дополнительные требования
Естественно, в любой нормальной верстке должна быть прописана кодировка и doctype. Также страничку можно проверить на работоспособность при выключенных картинках или при блокировании javascript-кода. Дело в том, что в настройках любого браузера пользователь может отключить эти параметры. Особенно полезно будет прописать атрибуты alt для картинок, чтобы при их исчезновении пользователь хоть как-то мог ориентироваться. На самом деле требований к верстке может быть очень много. Даже в рунете есть достаточно строгий перечень необходимых проверок. Например, с появлением HTML5 верстку можно проверять на правильную семантическую разметку. Однако все это не является критичным. Вышеописанных проверок вполне хватит, чтобы смело запустить нормальный работоспособный сайт.
В этой статье мы описали основные способы проверки верстки с помощью различных программ, сервисов и инструментов. Это поможет вам адаптировать сайт под любые условия.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3