Зачем тестировать верстку?
«Если звезды зажигают – значит – это кому-нибудь нужно»? Если макет отрисован до мелочей – казалось бы, так и должно получиться в итоге! Но есть один нюанс: страница должна не только соответствовать макету, но и работать.
- тестирование внешнего вида;
- тестирование адаптированности страницы.
Возникает вопрос: а так ли важно тестирование интерфейса? Это ведь не функционал и не безопасность. Разве не может верстальщик сравнить заданную картинку с тем, что получилось в итоге? Может! Но замечать детали – это все-таки удел тестирования. Кроме того, не стоит забывать и про человеческий фактор: у верстальщика часто просто «замыливается глаз» в процессе работы. Хотите проверить свою внимательность? Посмотрите это небольшое видео, и Вы удивитесь, сколько всего очевидного можно не заметить.
Как тестировать внешний вид страниц?
У современного тестировщика есть множество помощников в виде различных инструментов, стандартов и стайлгайдов (инструкций об общепринятых обозначениях кнопок и визуальных эффектов на сайтах). Опираясь на них, можно качественно и быстро протестировать продукт в целом и верстку в частности.
Начнем с тестирования внешнего вида страницы. В первую очередь сравним имеющуюся страницу с макетом. Блоки должны совпадать с макетом идеально, для текста же существует допустимый зазор в 5 рх. Для измерения таких деталей существует инструмент PerfectPixel: достаточно наложить полупрозрачный макет на итоговое решение – и мы сразу увидим различия, ежели таковые имеются.
После проверки общей картинки переходим к деталям. Разобраться со шрифтами поможет, например, What Font. Проверить многообразие цветов – Color Zilla. Убедиться в правильности написания контента – Spell Checker или Орфограф Артемия Лебедева (в Орфограф мы вводим адрес своей странички, после чего все неизвестные или неправильно написанные слова выделяются цветом, который мы сами выбираем).
Как проверить адаптированность страницы?
Визуальная красота не отменяет необходимости правильной работы страницы. Можно впасть в панику, лишь только вспомнив о разнообразии существующих гаджетов и разрешений экранов. И действительно, сайт, как правило, должен корректно отображаться на любых ПК, планшетах или мобильных телефонах.
В расширении присутствуют популярные размеры окон компьютеров, ноутбуков и смартфонов. Внести наши специфические требования, а также удалить ненужные варианты всегда можно через настройки.
- появление курсора на кликабельных элементах;
- отсутствие курсора, соответственно, на некликабельных;
- очевидное обозначение возможности переноса элемента;
- появление курсора и вводимых символов в поле для ввода текста;
- отображение фавикона.
Копаем вглубь страницы!
Можем ли мы после учета всех перечисленных ранее проверок остановиться и выдохнуть? Нет! Итак, курсор на кликабельных элементах появляется. Теперь пришло время проверять ссылки, ведь они могут открыть как заложенную в логику программы информацию, так и всем нам печально известную страницу 404. Ссылка на наш или чужой контент может устареть, а отследить такие моменты поможет приложение Black Widow. Периодически запуская проверку сайта с его помощью, мы получим возможность отследить битые ссылки раньше, чем их найдут пользователи.
В правильности соблюдения стандарта написания кода мы можем убедиться с помощью сервисов от w3.org: достаточно написать адрес страницы в специально отведенное поле и запустить проверку. Все, что не попадает под «стандарты», будет обозначено словом ERROR.
Как мы можем заметить по скриншотам проверки, валидатор выдает сообщения об ошибках, так как он опирается на самые свежие правила и стандарты. К сожалению, это не всегда можно сказать о ПО: при появлении изменений код далеко не всегда пересматривается и переписывается (тем более, если по факту он остается рабочим). Кроме того, нередко при создании программы применяются «авторские» решения, абсолютно правильные с точки зрения работы страницы, но невалидные для общепринятых стандартов. Сможет ли сам тестировщик определить, насколько критичны найденные ошибки? Скорее всего, потребуется консультация специалиста, умеющего писать код. Некоторые ошибки повлекут за собой серьезные исправления, в других же случаях вполне достаточным будет «причесать» элементы кода или тэги до их обновленной версии. После корректировки код станет идеальным, стандартизированным и не вызывающим ни единого подозрения… До следующего обновления стандартов.
- при отключенных картинках;
- при выключенном Flash;
- при выключенном JavaScript.
Даже во время загрузки страница должна выглядеть достойно: все надписи должны быть читабельны, картинки – подписаны, основной функционал сайта – доступен. Это особенно важно в тех случаях, когда мы имеем дело с низкой скоростью интернета или же с дорогостоящим трафиком у клиента. Но в любом случае все они – наши пользователи: мы их любим и заботимся о них!
Дополнительные возможности тестирования верстки
- Веб-аналитика (Гугл-аналитика, Яндекс-метрика и пр.). Нужно убедиться в наличии самого счетчика в нашем коде и проверить корректность ID счетчика.
- SEO. В этом случае мы обращаем внимание на тэги. На всех страницах, которые индексируются, должны быть прописаны тэги «keywords» и «description»; на не подверженных индексации страницах или конкретных элементах должен быть тэг «noindex».
- Электронная коммерция. Цель тестирования – проверить информацию о завершенных покупках. Например, при просмотре ранее купленного товара должна выводиться информация о том, что данный продукт мы уже покупали. Другая возможность – просмотр всей предыдущей истории заказов: начиная с информации о номере и стоимости заказа и заканчивая видом и количеством товаров и адресом доставки (набор обязательных параметров задает заказчик на свое усмотрение).
- Интеграция с соцсетями. Для отслеживания ответов, перепостов и лайков разработчик прописывает в коде определенный метод. Наша цель – найти этот метод и проверить его на работоспособность. Например, внешний вид кнопок для шаринга или отображаемых блоков для подписки должен быть узнаваем и визуально отличен от стиля другой соцсети. Другой важный момент: мы должны убедиться, что при появлении информации о каком-либо сообществе или человеке контент отобразится корректно (пост будет выглядеть постом, а картинка – картинкой).
Выводы
В заключение хочется рассказать историю о том, как решение пропустить этап тестирования верстки программы привело к остановке работы службы перевозок.
Однажды руководство одной из служб перевозок города N приняло решение добавить строку с именем клиента в окно заказа для водителей. Идея была немедленно передана разработчику. Разработчик буквально за пару часов справился с задачей, после чего было запущено обновление программы. Практически сразу в техническую поддержку начали поступать жалобы на слишком мелкий текст в измененном окошке. Сама идея водителям понравилась, но теперь самую важную информацию – адрес клиента – приходилось искать глазами. Замечания были переданы в разработку.
Вскоре новая версия программы была подготовлена, строку «адрес клиента» увеличили до предыдущего значения. Отдел тестирования приготовился к своей непосредственной работе, но руководство решило отказаться от проверки, основываясь на мнении работников технической поддержки, измученных постоянными звонками: «Да там только адрес увеличили, подумаешь! Пока проверим – наши телефоны взорвутся. Запускайте обновление!»
Как ни странно, после запуска исправленной версии звонки не прекратились, а количество свободных заказов стремительно возрастало. Оказалось, что при увеличении одной строки окошко «поехало», и кнопка принятия заказа исчезла с экранов гаджетов размером менее 5 дюймов. История закончилась благополучным откатом до предыдущей версии, но, как говорится, «осадок остался».
В этой статье мы кратко рассмотрели необходимость тестирования верстки и некоторые методы этого тестирования. Все они – простые или более сложные – послужат на пользу продукту. Выбор же оптимального набора методов в каждом конкретном случае остается за Вами!