Тестирование фронтенда: проверяем верстку
Привет! Я — Таня Перина, QA-тестировщик в Purrweb. Рассказываю про мелкие детали, которые сделают мир пользователя лучше. Надеюсь. Верю.
В жизни фронтендера случается так, что он становится немного верстальщиком. Тут очень важно не попасть в капкан собственной уверенности. Вёрстка как у боженьки на рабочем экране не означает, что такой же крутой результат получился везде.
Представь, тебе дали проект — допустим, какой-нибудь сайт. Дизайн сайта прилетел в виде макета: в Figma, Zeplin (Sketch) или Adobe XD. И вот ты его сверстал.
Настало время тестировать! Что делать? Расскажу по порядку.
Кому советую читать:
- Фронтендерам, которые начали этот увлекательный путь боли, страдания и приключений!
- Всем, кто связан с разработкой. Хотя бы ради мыслей «А Я ТАК НЕ ЛАЖАЮ».
А теперь к делу.
Погружаемся в тестирование фронтенда: сравните результат с макетом
Учиться на ошибках чужих — хорошо. Для фронтенд-тестирования это правило работает так же хорошо. Вот что случается, если не сверять верстку с макетом.
Сверху экран Contact Us для нашего сайта. Eще год назад он был в разработке. Справа — макет или «то, как должно быть». Слева — то, что изначально получили на выходе.
Или вот еще пример.
Опять то же самое. Макет справа, реальность слева. Тут проблема с баджами.
Чтобы предотвратить появление этих ошибок на этапе тестирования фронтенда, проверьте совпадают ли размеры элементов, шрифты, цвета. Если нужно сделать 1 в 1 — используйте Pixel perfect.
Посмотрите, как все выглядит на разных экранах
Что может случиться, если не учесть размер экрана при тестировании фронтенда? Давайте посмотрим.
На каких экранах сайт будет открываться? Необходимо выяснить это с командой на берегу. Так, можно минимизировать неприятные сюрпризы, а пользователи смогут без проблем открыть страницу. Даже на каком-нибудь маленьком экране.
Вот 10 популярных разрешений экрана, на которых пользователи открывают наш сайт:
Кто-то любит сидеть за MacBook Air, кто-то обожает огромные дисплеи. Но, открыв страницу сайта, каждый хочет увидеть что-то внятное — круто, когда вёрстка этому не препятствует:)
Протестируйте на кроссбраузерность
Во время фронтенд-тестирования не ограничивайтесь Google Chrome — откройте также Safari, Firefox и Microsoft Edge. Чтобы не произошло такое:
Слишком много нашего сайта. Впрочем, ладно. Держите еще один пример.
В процессе фронтенд-тестирования, cкорее всего, придется проверить и «мертвый» Internet Explorer. Статистика посетителей нашего сайта подтверждает факт, что кто-то до сих пор им пользуется.
Это же касается и IE 11. Потому что бывает вот так:
Поддержка Internet Explorer — главный страх и боль последних лет. Этот браузер часто остается в стороне. НО пользователи IE живы пока жив сам IE. Так что, проверьте результат работы и там — если ничего не работает, сообщите об этом команде (можно начать с проектных менеджеров).
Проверьте верстку на мобильном устройстве (критично для тестирования фронтенда)
Лайтовый вариант, который не вводит в ужас обычных людей, но вводит в ужас дизайнеров:
Как часто вы открываете сайты с телефона в обычной жизни? Я — часто 😀 Сейчас смартфон заменяет компьютер, люди от быстрой жизни читают, смотрят, изучают всё с телефона. И если есть возможность использовать сайт мобильной версии, то не забудьте посмотреть, как он выглядит. Зачем? Чтобы пользователь, зашедший на сайт со смартфона не выколол себе глаза от ужаса 😀
Проверьте, как выглядят длинные строки в формах ввода
Допустим, у тебя форма регистрации пользователя с именем, почтой и паролем. И где-то на сайте будет отображаться имя. Именем может быть «Ян», а может «Барнаби Мармадюк Алоизий Бенджи Кобвеб Дартаньян Эгберт Феликс Гаспар Гумберт Игнатий Джейден Каспер Лерой Максимилиан Недди Объяхулу Пепин Кьюллиам Розенкранц Секстон Тедди Апвуд Виватма Уэйленд Ксилон Ярдли Закари Усански». И это не моя бурная фантазия, а реальное имя. Имя, которое может всю верстку сломать 🙂
Тестирование фронтенда: Зачем проверять верстку?
Верстка — это важная часть любого веб-проекта. Это то, что пользователи видят в первую очередь. Это обертка, по которой судят. Сделать ее классной — ваш священный долг!
Просто потому что:
- Проект — это чьи то деньги.
- Каждая мелкая деталь важна.
- Слишком просто верстать только под Chrome.
Выполняя эти простые шаги, вы здорово повысите перформанс проекта. И тогда (возможно не с первого раза) тестировщик, заказчик или менеджер не заставят вас переделывать верстку по сто раз. И будет вам счастье!
Спасибо за материал, но к сожалению я побуду занудой — очень поверхностные советы для совсем новичков.
"Смотрите сайт в разных браузерах, ведь верстка должна выглядеть одинаков на разных устройствах, а ещё бывает разная ширина окна, может что-то вылезти за край, будьте внимательны" — весь смысл статьи в одном предложении, причем чтобы получить ценность, достаточно просто помнить об этих вещах, никаких секретов.
в них и метили :) без секретов и открытия Америк.
за фидбек спасибо!
Рассказывая про верстку сломали ux, хехе. Как-то привычней слева видеть исходник, а справа — результат.
Зачем у Кунг-фу панды подпись скоммуниздили?
Скоммуниздили и скоммуниздили, чего бубнить-то?
Что-то я не помню такого в кунг фу панда🤷🏻♂️
Где пруфы?
не скоммуниздили, позаимствовали)
На картинке, судя по описанию, Edge и Chrome. Несостыковочка.
Толстые шрифты в мозилле? Серьезно?
И вы заставили верстальщика это править? Или ещё хуже - frontend dev'a?
Насильно заставлять кого-то делать задачи - не наша история. У нас процесс такой:
Все баги, которые находят тестировщики, попадают в виде задач в Трелло и отправляются на оценку.
Чтобы дизайнер/разработчик не делал задачи в стол, мы сопоставляем потраченное время с возможными бенефитами. Если кажется, что задача не стоит того, чтобы инвестировать в нее X часов времени - она остается в бэклоге. Если X часов все-таки принесут нужное количество пользы - берем в работу.
Конкретно в этом кейсе верстальщику потребовалось 15 минут. Мы посчитали, что срок адекватный и сделали задачу.
Возвращаясь к истории со шрифтами в Мазилле - если хочется, чтобы дизайн соответствовал тому, что получается на выходе, будьте готовы уделять этому время. А вообще все зависит от конкретного проекта - где-то это супер-критично, где-то нет. Здравый смысл никто не отменял :)
"Слева — макет или «то, как должно быть». Справа — то, что получили на выходе."
А почему тогда макет красным крестиком помечен, а результат зеленой галочкой?
проморгали, поправили)
Все ещё в тексте "слева макет, справа результат" красный крестик у макета, зеленая галочка у результата.
думали, что поправили, оказалось, проморгали :))
теперь точно порядок, спасиб!
А расскажите лучше, про какую-нибудь автоматизацию. Как, например, тестят большие сайты на сотни страниц или и-магазы? Не вручную же?
Не наша специфика. Мы больше про продукты, не про интернет-магазины.
Догоняя ваш коммент,
Поспрашивали ребят про автотестирование - кто что читал/смотрел за последнее время. Вот статья, где достаточно информативно и доступно рассказывают про автотесты верстки: http://glivera-team.github.io/structure/2016/03/22/css-test.html
А вообще тема неоднозначная, интересная. Спасибо за идею!
Кто-то занимается тестированием на аутсорсе? Или может кого-то посоветовать?