Привет! Я — Таня Перина, 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. Так что, проверьте результат работы и там — если ничего не работает, сообщите об этом команде (можно начать с проектных менеджеров).
Маленький совет: Помните о том, что Google Chrome на Mac OS совсем не тот, что на WIndows.
Проверьте верстку на мобильном устройстве (критично для тестирования фронтенда)
Лайтовый вариант, который не вводит в ужас обычных людей, но вводит в ужас дизайнеров:
Как часто вы открываете сайты с телефона в обычной жизни? Я — часто 😀 Сейчас смартфон заменяет компьютер, люди от быстрой жизни читают, смотрят, изучают всё с телефона. И если есть возможность использовать сайт мобильной версии, то не забудьте посмотреть, как он выглядит. Зачем? Чтобы пользователь, зашедший на сайт со смартфона не выколол себе глаза от ужаса 😀
Проверьте, как выглядят длинные строки в формах ввода
Допустим, у тебя форма регистрации пользователя с именем, почтой и паролем. И где-то на сайте будет отображаться имя. Именем может быть «Ян», а может «Барнаби Мармадюк Алоизий Бенджи Кобвеб Дартаньян Эгберт Феликс Гаспар Гумберт Игнатий Джейден Каспер Лерой Максимилиан Недди Объяхулу Пепин Кьюллиам Розенкранц Секстон Тедди Апвуд Виватма Уэйленд Ксилон Ярдли Закари Усански». И это не моя бурная фантазия, а реальное имя. Имя, которое может всю верстку сломать 🙂
Тестирование фронтенда: Зачем проверять верстку?
Верстка — это важная часть любого веб-проекта. Это то, что пользователи видят в первую очередь. Это обертка, по которой судят. Сделать ее классной — ваш священный долг!
Просто потому что:
- Проект — это чьи то деньги.
- Каждая мелкая деталь важна.
- Слишком просто верстать только под Chrome.
Выполняя эти простые шаги, вы здорово повысите перформанс проекта. И тогда (возможно не с первого раза) тестировщик, заказчик или менеджер не заставят вас переделывать верстку по сто раз. И будет вам счастье!
Спасибо за материал, но к сожалению я побуду занудой — очень поверхностные советы для совсем новичков.
"Смотрите сайт в разных браузерах, ведь верстка должна выглядеть одинаков на разных устройствах, а ещё бывает разная ширина окна, может что-то вылезти за край, будьте внимательны" — весь смысл статьи в одном предложении, причем чтобы получить ценность, достаточно просто помнить об этих вещах, никаких секретов.
в них и метили :) без секретов и открытия Америк.
за фидбек спасибо!
Зачем у Кунг-фу панды подпись скоммуниздили?
Скоммуниздили и скоммуниздили, чего бубнить-то?
Что-то я не помню такого в кунг фу панда🤷🏻♂️
Где пруфы?
не скоммуниздили, позаимствовали)
Рассказывая про верстку сломали ux, хехе. Как-то привычней слева видеть исходник, а справа — результат.
На картинке, судя по описанию, Edge и Chrome. Несостыковочка.
Толстые шрифты в мозилле? Серьезно?
И вы заставили верстальщика это править? Или ещё хуже - frontend dev'a?
Насильно заставлять кого-то делать задачи - не наша история. У нас процесс такой:
Все баги, которые находят тестировщики, попадают в виде задач в Трелло и отправляются на оценку.
Чтобы дизайнер/разработчик не делал задачи в стол, мы сопоставляем потраченное время с возможными бенефитами. Если кажется, что задача не стоит того, чтобы инвестировать в нее X часов времени - она остается в бэклоге. Если X часов все-таки принесут нужное количество пользы - берем в работу.
Конкретно в этом кейсе верстальщику потребовалось 15 минут. Мы посчитали, что срок адекватный и сделали задачу.
Возвращаясь к истории со шрифтами в Мазилле - если хочется, чтобы дизайн соответствовал тому, что получается на выходе, будьте готовы уделять этому время. А вообще все зависит от конкретного проекта - где-то это супер-критично, где-то нет. Здравый смысл никто не отменял :)
"Слева — макет или «то, как должно быть». Справа — то, что получили на выходе."
А почему тогда макет красным крестиком помечен, а результат зеленой галочкой?
проморгали, поправили)
Все ещё в тексте "слева макет, справа результат" красный крестик у макета, зеленая галочка у результата.
думали, что поправили, оказалось, проморгали :))
теперь точно порядок, спасиб!
А расскажите лучше, про какую-нибудь автоматизацию. Как, например, тестят большие сайты на сотни страниц или и-магазы? Не вручную же?
Не наша специфика. Мы больше про продукты, не про интернет-магазины.
Догоняя ваш коммент,
Поспрашивали ребят про автотестирование - кто что читал/смотрел за последнее время. Вот статья, где достаточно информативно и доступно рассказывают про автотесты верстки: http://glivera-team.github.io/structure/2016/03/22/css-test.html
А вообще тема неоднозначная, интересная. Спасибо за идею!
Кто-то занимается тестированием на аутсорсе? Или может кого-то посоветовать?