Тестирование верстки
Вы получили задание протестировать верстку и не знаете с чего начать и чем закончить? Велком — мы расскажем все нюансы
Знакомство
Кто мы?
Это наш первый урок, поэтому давайте познакомимся
Всем привет! Меня зовут Женя Пономаренко, я руководитель и создатель компании «Кавычки». Я занимаюсь тестированием более 14 лет, а наша команда помогает улучшать качество уже более 8 лет. Наши команды работают с крупнейшими компаниями России, Европы, Китая и Америки. Мы копили опыт наших сотрудников многие годы и теперь готовы поделиться им с вами. Наших рук не хватает, чтобы помочь всем компаниями в тестировании и обеспечении качества. И теперь наша задача — подготовить качественных тестировщиков, которые будут помогать улучшать веб-продукты других компаний.

Евгений Пономаренко
Руководитель компании «Кавычки»

Екатерина Копцова
QA Lead
Привет! Меня зовут Катерина Копцова, я являюсь QA Lead компании «Кавычки». Свою работу в данной компании я начинала с должности тестировщика и за 3 года работы развила достаточно скилов, чтобы занять должность лида. За все время работы я прошла не один курс по тестированию, обучалась как внутри компании, так и за её пределами. И считаю, что мне есть с чем сравнивать, и я могу выделить положительные и отрицательные моменты, связанные как с подачей информации и её представлением, так и с самим содержанием. В рамках данного курса мы постарались собрать все знания и умения, полученные за годы работы на различных проектах и представить её в максимально понятной форме. Но это не точно :)
Знакомство
Для кого этот урок?
Уверены, что этот урок пригодится всем:) Но проверьте на всякий случай, есть ли вы в списке тех, кому он будет интересен
В первую очередь наш курс будет полезен тем, кто только что получил задание протестировать верстку, но не знает с какой стороны подступиться, чтобы не пропустить баги. Во-вторых, тем кто уже сталкивался с тестированием верстки и даже собаку на этом съел. Да-да, вам тоже стоит заглянуть к нам на огонек. У нас есть для вас пару полезных советов. И, конечно же, наш курс обязательно будет полезен заказчику, который не доверяет своей команде. Ай-ай-ай, кстати. Надо доверять!

Мы расскажем о том, как проверить сайт, если вы плохо находите 10 отличий в детских журналах. Покажем инструменты, с которыми вы минимизируете количество пропущенных ошибок. Поделимся лайфхаками, которые спасли не один десяток сайтов. Поможем не попасть на проблемы с клиентом, если он проверяет ваш сайт на Nokia 3310. И даже, может быть, взрастим в вас вкус к хорошему, качественному и удобному дизайну.

Начнем
Итак, перед вами новенький сайт. С чего начать? Рассмотрим два сценария развития действий:

G) Макетами с вами решили не делиться, потому что: "они не актуальны", "слишком много мелких изменений", "их нет", "они есть, но вам просто необходимо посмотреть, что ничего не развалилось". Что делать?

Ok) В команде есть очень талантливый дизайнер, который три ночи подряд не спал, рисуя макеты, по которым не менее талантливый верстальщик сверстал сайт (конечно же, после согласования макетов с заказчиком). Что делать?
тестирование верстки
Основные моменты
Сейчас мы разберем те места, на которые стоит обращать внимание при тестировании верстки
И начнем мы со сценария G - тестирования без макетов.

Чтобы не создавать баг-листы длиною в жизнь, записывая туда ВСЕ, что попадается на пути, нужно понимать, что относится к багам верстки. Давайте ошибки, которые находим при тестировании web, поделим на 4 основных группы:
— функционал,
— верстка,
— контент,
— usability.

Последняя группа может быть объединена с багами верстки, но чаще всего usability баги заводятся, как предложения по улучшению, поэтому и были вынесены в отдельную группу. Нас интересует пока только то, как сайт будет выглядеть, только его визуальная составляющая и еще немного удобство использования. Поэтому обращаем внимание на:

Ховеры
Даже если на макетах их нет, но очень не хочется видеть безразличную кнопку или ссылку. И не только кнопку! Почти все элементы, которые при наведении меняют вид курсора на pointer должны иметь ховер. Ключевое слово "почти", потому что есть исключения. Ховер нужен для того, чтобы подсказывать пользователю, что с элементом можно что-то сделать, вероятнее всего кликнуть. От этого правила и отталкиваемся. Есть и обратная ситуация, когда ховер есть, но курсор не меняет своего вида и это тоже баг.

Анимация
Сюда относятся: видео-фон, анимация при прокрутке баннеров, анимация при раскрытии списков, флэш (прости, Господи) и т.п. При проигрывании анимации у пользователя не должно создаваться впечатления, что сайт тормозит. Анимация должна быть плавной. Стоит также обращать внимание на скорость эффектов. Слишком быстрая автоматическая прокрутка слайдеров приводит к тому, что пользователь не успевает воспринять информацию, представленную на них. Слишком медленная анимация выпадающих списков/меню в конце концов надоест пользователю, какой бы красивой она не была.

Попапы
Pop-up - это всплывающее на сайте окно. Еще одно правило хорошей верстки: никаких сообщений в alert! Только попапы, только хардкор! Alert сообщения очень блеклые, явно не в дизайне сайта и просто прошлый век. Хоспади, если у вас вывалится алерт на сайте, вы не сможете покинуть страницу пока не кликните что-то в этом окошке! Этим пользуются порно-сайты и канал ТНТ. Но им можно:) Так что, если в процессе регистрации пользователь увидит alert с невнятным сообщением о том, что он сделал не так, то он скорее всего уйдет, передумав регистрироваться, но это не точно. Но мы же стараемся воспитывать вкус. Поэтому если мы покажем пользователю информативное сообщение в попапе, то он, вероятно, попробует еще раз. В этом примере само представление ошибки играет не такую важную роль, как ее содержание. И это еще один момент, на который стоит обращать внимание.

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

Шрифт
Смотрим на кегль, межстрочный интервал, толщину и цвет. Ориентируемся либо на макеты, либо на здравый смысл, который подскажет, что все заголовки верхнего h1 должны быть одинаковыми, за ними должны следовать h2, h3 и т.д. и основной текст не может быть больше заголовков (НО везде есть исключения).
Важно понимать: Если говорить о тексте, то не весь текст относится к верстке! Нужно отличать баги вёрстки текста от багов контента. Текст, который принадлежит верстке - это чаще всего текст: в кнопках, меню, заголовках статичных разделов, подвале, шапке и в других статичных блоках.Тексты функциональных элементов, которые делают одно и то же действие на разных страницах — должны называться одинаково. Не может кнопка где-то называться "Войти", а где-то на соседней странице "Вход". Или первое, или второе.
Текст функциональных элементов должен быть типографирован. Любите правильные кавычки, различайте тире и дефисы, разносите разряды в числах — тогда ваши пользователи будут легче воспринимать информацию.

Еще пара важных моментов, на которые хочется обратить внимание — переносы текста и висячие строки. Баги, связанные с переносами текста чаще всего возникают из-за того, что верстальщики забывают поставить неразрывный пробел перед числами, дефисами и т.п. Висячие строки — это строки, которые не выровнены по левому краю основного контента. Это касается как обычного сплошного текста, так и списков.

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

Тестирование полей форм (ошибки, нотификация)
Сюда относится все, что валидируется на клиенте, т.е. проверки, которые не требуют обращения к серверу. Зачастую это могут быть проверки на пустые поля, на соответствие введенной строки формату поля и т.п. Сообщения об ошибках должны визуально выделяться, располагаться рядом с тем полем, где возникла ошибка и должны быть информативными. Если пользователь ввел пароль не соответствующий вашим стандартам — скажите ему об этом, расскажите какой пароль должен быть. Если пользователь не выбрал какой-то чекбокс в форме со стопицот полей, то, пожалуйста, попросите верстальщика сделать так, чтобы страница позиционировалась на неверном поле. Не заставляйте пользователя искать проблемное место или думать как исправить свою ошибку.

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

Тестирование ссылок
Ссылки должны работать и вести туда, куда им полагается. Это же касается и ссылки на лого. В хорошей верстке принято, что ссылка в лого ведет на главную страницу, а на главной логотип не кликабелен. Если ссылка просто открывает какой-то попап с дополнительной информацией, то этот клик ни в коем случае не должен переносить пользователя в начало страницы. Пользователь хочет оставаться на месте в такой момент, а не заново искать то место, где он остановился. Давайте не лишать его этой возможности.

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

Отключение JS и изображений
Информация должна быть доступна даже если сайт не загрузился полностью. Если сайт содержит много анимации/скриптов и прочих плюшек, то это, возможно, хорошо, но не для пользователей с низкой скоростью интернета. Поэтому все скрипты должны грузиться в последнюю очередь, а основной контент - в первую. Если же на сайте происходит какая-то асинхронная подгрузка элементов, то не забывайте о том, что должен быть какой-то прелоадер, сообщающий о том, что что-то происходит на странице и она не зависла.

Открытие попапов с формами (например, попап логина/регистрации), визуальные изменения при каких-либо действиях (например, удаление товара из корзины) — это тоже относится к верстке, поскольку данный вид взаимодействия происходит на клиенте. Поэтому прокликайте все функциональные элементы на странице. Убедитесь в том, что открываются и закрываются всплывающие окна, а видео в попапе перестает проигрываться после его закрытия. Если есть ТЗ, то оно должно отвечать на вопросы, что должно происходить, если пользователь добавил товар в корзину, удалил из корзины, поставил лайк или добавил в избранное.

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

Версия для слабовидящих
Если на сайте есть версия для слабовидящих, то ее тоже нельзя оставлять без внимания. К данной версии применяются все правила, описанные выше. Плюс оно правило - все элементы должны быть контрастными. Ну и конечно кегль текста должен быть больше относительно обычной версии. Есть официальные требования ГОСТ (Р 52872-2007 «Интернет-ресурсы. Требования доступности для инвалидов по зрению»). Вот основные выдержки:

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

  1. Все изображения необходимо сопровождать комментариями;
  2. Таблицы должны иметь степень вложенности не более трех;
  3. Таблицы должна иметь не более 15 ячеек.
  4. Также есть международные стандарты W3 Web Content Accessibility Guidelines (WCAG) 2.0. И еще немного о требованиях к страницам для слабовидящих людей:
  5. Контраст — не менее 4.5:1;
  6. Размер шрифта может быть увеличен в 2 и более раз, при сохранении функциональности и без появления горизонтальной прокрутки;
  7. Возможность выбора цвета текста и фона;
  8. Ширина текстового блока не должна превышать 80 знаков;
  9. Выравнивание текста по ширине блока или окна не допускается
Междустрочный интервал полуторный или выше, расстояние между параграфами в полтора раза больше, чем интервал между строками.
тестирование верстки
Тестирование без макетов
Как тестировать, если нет макетов? — Давайте разберемся
Если вам необходимо проверить верстку на корректность отображения или прекрасное graceful degradation ("прелестная деградация" дословно), то здесь наиболее оптимальным инструментом будет ваша внимательность. А если разбавить это опытом, здравым смыслом, интуицией и чувством прекрасного, которое мы здесь пытаемся воспитывать, то цены такому инструменту не будет.

Основной смысл проверки — убедиться в том, что все блоки присутствуют на странице, блоки не развалились и не наехали друг на друга, функциональные элементы нажимаются, и приводят к ожидаемому результату, и тп. Также в эту категорию "прелестной деградации" входит проверка на совсем старых браузерах. Бывает полезно знать, что ваш пользователь придя с ИЕ9 получит необходимую информацию, пусть даже без скругленных уголочков, lazy picture, фейдов и забытого всеми параллакса.

Основные моменты, на которые стоит обращать внимание, мы рассмотрим дальше, но хотелось бы провести сравнение данного метода и метода проверки с помощью Perfect Pixel.


Плюс проверки на корректность отображения

  • Занимает значительно меньше времени.

  • Как правило при таком виде тестирования больше внимания уделяется состоянию элементов на странице (ховерное состояние и т.п.).

  • Больше внимания уделяется также и удобству использования элементов сайта.

  • Легко проверяется на мобильных устройствах в любых положениях (альбом/портрет).


Минусы проверки на корректность отображения

  • При недостатке опыта/внимательности можно оставить за собой не маленькую кучу багов.

  • Субъективное мнение: то, что для вас может показаться багом, на самом деле может таковым не быть или быть фичей.


Здесь стоит обращать внимание на стиль элементов. Зачастую сайт сверстан в одном стиле (имеет одинаковый стиль для кнопок, таблиц и других элементов, представлен несколькими цветами и т.п.) и явное отличие какого-либо элемента от стиля остальных - скорее всего баг. Так что смело рапортуем о таком отщепенце :) Но если, по вашему мнению, все кнопки/списки/таблицы не в дизайне сайта, то стоит задуматься, а не придираетесь ли вы, вдруг этот сайт для детей?

Также обращаем внимание на расположение элементов друг относительно друга, другими словами представляем себе сетку и смотрим, чтобы все элементы сайта были выровнены по этой сетке. Неважно какую сетку выбрал дизайнер: простую, сложную, гибкую или нет — элементы сайта при верстке должны располагаться по сетке. Что такое сетка прекрасно рассказано в статье наших друзей Rambler — https://habrahabr.ru/company/rambler-co/blog/261679/. Данный вариант тестирования отлично подойдет и для случая, когда макетов у нас нет.
тестирование верстки
Тестирование по макетам
Макеты есть, но ошибок слишком много? Что есть ошибка, а что ею не является?
Все это дело (сайт, макеты, ТЗ) присылает вам ваш начальник, припугивает грозным заказчиком и просит протестировать.

Смотрим дизайн-макеты. Дизайн-макет – это графическое представление будущего сайта. Стандартный набор – это архив картинок, на каждой из которых представлен дизайн отдельной страницы. Если сайт адаптивный, то дизайн макеты предоставляются для каждого разрешения (стандартные разрешения: 1360, 1024, 780, 360). Каждый макет представляет собой то, как должна выглядеть веб-страница, при условии, что все элементы на ней в исходном состоянии (не были кликнуты, ховерное состояние неактивно и т.п.). Могут быть вынесены отдельно или представлены на тех же страницах макеты состояний элементов.

Возможно, вам даже передали ТЗ на верстку и дизайн. Пожалуйста, не пропускайте его мимо. В ТЗ также могут быть указаны интересные моменты, которые стоит учесть при тестировании верстки. Например, описание того, с какой частотой должен переключаться автослайдер или что должно происходить при клике на тот или иной функциональный элемент.
Важно понимать: Ваши лучшие друзья – здравый смысл и опыт. Баги есть везде! В том числе в «безупречном ТЗ» и макетах. [Мы ни в коем случае не хотим обидеть чувства дизайнеров и верстальщиков и не сомневаемся в их профессионализме, но от человеческого фактора никуда не деться.]
Поэтому при тестировании верстки по макетам пользуемся следующими золотыми правилами:

— Проверь наличие ошибок в макетах. Практика показывает, что зачастую в макетах одинаковые элементы не одинаковые. Что это значит. По правилам хорошей верстки, если на сайте есть шапка и подвал, то для всех страниц они одинаковы (возможно, за исключением служебных страниц). И если вы видите, что на одном макете элементы меню в шапке черного цвета, а на другом синего, то это ошибка макета. Стоит обращать внимание не только на шапку и подвал. Тут речь может идти об унифицированных элементах на сайте: кнопки и ховеры, формы и попапы, списки, сообщения об ошибках. Нам солянка не нужна — поэтому просим дизайнеров придерживаться одного стиля. Думаем об удобстве использования нашего сайта.

— Найди 10 отличий. Тут начинается самое интересное. Задача тестировщика – найти отличия макета от реализации. Возможно два пути, которым можно следовать: проверка при помощи специального инструмента, либо «на глаз» (на левый/правый или сразу двумя, как вам удобнее)..
тестирование верстки
Pixel Perfect
Идеальный макет. Идеальная ли верстка? Стоит проверить
Одним из наиболее популярных плагинов тестирования верстки является Pixel Perfect. Perfect Pixel - инструмент, позволяющий сравнить сверстанный HTML-шаблон с макетом и выяснить в точности ли (пиксель-в-пиксель) они совпадают. Работает это так: накладываем картинку макета на "картинку" сверстанного HTML-шаблона, обе картинки должны совпасть. Совместиться должны ВСЕ элементы - текст, изображения и т.п.

Perfect Pixel дружит с Chrome, FF, Safari, Opera, IE и Edge. Для остальных браузеров — coming soon! http://www.welldonecode.com/perfectpixel/ — вот и ссылка на проект.

А если вам надо срочно "вчера" протестировать одну страницу, можно воспользоваться сервисом http://www.cssprecise.com/ — загружаете макет, указываете ссылку на страницу, получаете сравнение.

PixelPerfect

Рассмотрим детально как работать с Perfect Pixel:

Устанавливаем PP и открываем web-страницу, которую необходимо протестировать. Запускаем плагин и "скармливаем" ему макет данной страницы. Обычно макеты предоставляются в .psd формате, поэтому нужно сохранить их в .jpg или .png, чтобы Perfect Pixel их распознал.

ВАЖНО!

Стоит запомнить простую, но ОЧЕНЬ важную вещь: устанавливаем такое разрешение экрана, которое будет соответствовать макету. Если вы наложите макет 1600px на страницу при разрешении экрана 1360px, то будете долго и громко ругать верстальщика, недоумевая куда он смотрел, когда верстал эту страницу. Если же поменяете разрешение экрана на нужное, то, вероятно, картина окажется более радужной… но это не точно! :)

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

Теперь о том, как правильно пользоваться этим инструментом. Накладываем макет на страницу таким образом, чтобы совпал сначала самый левый верхний элемент страницы (обычно это логотип сайта, или первый пункт меню в шапке). После их совпадения проверяем, какие элементы справа от него и под ним не совпали. Если имеются (а они обычно имеются) несовпадения в строке ниже первого проверенного элемента, то стыкуем элементы второй строки до совпадения и снова проверяем элементы справа и снизу. И т.д. до тех пор пока не упремся в подвал.

В процессе проверки убедитесь в том, что: отступы между пунктами меню соответствуют макету. Как минимум они должны быть адекватными и одинаковыми для каждого из пунктов меню. Как максимум отступы должны совпасть с макетом, а вы просто обязаны будете в лобик поцеловать дизайнера. Он красавчик! Но это не точно. Мы же еще до подвала не дошли.

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


Плюсы PixelPerfect проверки

  • Наиболее точная проверка согласно макету. Маловероятна вероятность пропуска различия межстрочных интервалов, отступов, наличия/отсутствия блоков и т.п.

  • Инструмент бесплатный и свободно работает в нескольких популярных браузерах.


Минусы PixelPerfect проверки

  • Можно не заметить различия цветов или пропустить мелкий элемент из-за неверной установки настроек прозрачности.

  • Можно пропустить проверку ховерных состояний элементов.

  • Занимает гораздо больше времени, чем тестирование "на глаз".

  • Хрен мы проверим на мобильном устройстве.


А теперь сравним.


Плюс проверки на корректность отображения

  • Занимает значительно меньше времени.

  • Как правило при таком виде тестирования больше внимания уделяется состоянию элементов на странице (ховерное состояние и т.п.).

  • Больше внимания уделяется также и удобству использования элементов сайта.

  • Легко проверяется на мобильных устройствах в любых положениях (альбом/портрет).


Минусы проверки на корректность отображения

  • При недостатке опыта/внимательности можно оставить за собой не маленькую кучу багов.

  • Субъективное мнение: то, что для вас может показаться багом, на самом деле может таковым не быть или быть фичей.

тестирование верстки
Кроссбраузерное тестирование
Надо ли проверять во «всех» браузерах? Ну такое...
Если речь идет о тестирование верстки, то немаловажно помнить о кроссбраузерности и кроссплатформенности! Разберем по порядку.

Кроссплатформенность, как говорит Википедия, - способность программного обеспечения работать более чем на одной аппаратной платформе и (или) операционной системе. Если речь идет о web, то, понятное дело, сайт будет отображаться на всех платформах, был бы только браузер установлен. НО в разных браузерах, да что там, и на разных ОС, сайт может отображаться по-разному. Дело в том, что браузеры по-разному интерпретируют html-код.

Кроссбраузерность - свойство сайта отображаться и работать во всех браузерах идентично. Под идентичностью понимается отсутствие развалов верстки и способность отображать материал с одинаковой степенью читабельности, а JS код отрабатывает свое. К нашему счастью веб-технологии все время развиваются, приемлемую кросс-браузерность можно обеспечить только для последних версий различных браузеров. Стандарты html и css постоянно обновляются, появляются новые библиотеки и правила. Они работают в обновленных версиях браузеров, но могут некорректно отображаться в старых.


Чтобы понимать, в каких браузерах стоит тестировать ваш сайт, а в каких нет, достаточно следить за статистикой их использования. Есть пара веб-статистов, на которых более-менее можно ориентироваться. Это LiveInternet и OpenStat. Но самый топчик — это воспользоваться Яндекс.Метрикой и Google.Analytics для вашего проекта. Эти аналитики будут самыми точными для вас, и вы сможете сформировать свой конфигурационный стек. Очевидно, что в первую очередь сайт проверяется в самых популярных и наиболее часто используемых браузерах, но не стоит игнорировать и те версии, которые используются не таким большим количеством людей, особенно если заказчик принадлежит к числу таковых :) Кстати, если вы заказываете разработку сайтов у компаний разработчиков, пожалуйста, предупредите их о том, каким браузером пользуетесь лично вы. Это сохранит вам нервы и время. Нервы компаний разработчиков можете не жалеть, но свои да!

Топ браузеров на сегодняшний день: Chrome, FF, Safari, Яндекс.Браузер, Опера. Многие тестировщики сейчас согласно покивают головой, если я скажу, что Internet Explorer - самый непредсказуемый браузер, который не понимает половину всех правил и поэтому программистам постоянно приходится придумываются новые хаки, чтобы обойти эту проблему. Но тем не менее, браузер используем достаточным количеством людей, поэтому проверять его верстку в нем стоит, по крайней мере в последней его версии. ИЕ11 до сих пор болтается в топе статистики LiveInternet. Важно заметить, что IE11 и Edge - это два разных браузера, хоть и произведенных одной компанией. Они работают на разных движках, сайты в них могут отображаться по разному. Поэтому тестируем IE11 то тех пор, пока компания производитель официально не откажется от поддержки своего продукта, как это было с ИЕ10.

Есть небольшой лайфхак, который немного упрощает жизнь тестировщикам. Нет большого смысла детально проверять проверять верстку отдельно в Хром, Опера и Яндекс Браузер. В 99% случаев верстка там одинакова, несмотря на разные движки, кто кого копипастит неизвестно. Поэтому достаточно хорошо протестировать сайт в Chrome, а по остальным пробежаться бегло.


Теперь очень важное заявление: ЛИЧНО МЫ ПРОТИВ ЭМУЛЯТОРОВ!

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

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

Во многих браузерах эмуляторы уже встроены, нужно только выбрать в DevTools нужные параметры. В Chrome, например, можно эмулировать кучу разных устройств. В IE 11 можно эмулировать IE 9, но поскольку эмуляция технически происходит подменой UserAgent в заголовке и идет через консоль, то никогда, например, не узнать, что в IE 9 консоль по умолчанию не существует и создается только по факту её открытия, а следовательно, любые console.log() в отсутствие спец. мер будут приводить к ошибкам и падениям скриптов. Если вам очень хочется работать с возможностями браузера при тестировании верстки, то лучше тогда просто используйте консоль и инспектируйте код, наглядно разглядывая css свойства.


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

1) Если у вас есть все устройства, на которых вы хотите проверить свой сайт, то достаточно просто взять эти устройства и проверить. Возможно, воспользовавшись ПО для оптимизации этого процесса.

2) Если нет устройств и хочется хорошего качества, то стоит поискать в интернете сервисы, которые могут предоставить реальные устройства с требуемыми браузерами в ваше пользование.

Чтобы проверить сайт в длинном списке необходимых устройств, не обязательно устанавливать все на свою машину. Тем более, что поставить несколько версий одного и того же браузера на один диск у вас не выйдет. Удобно использовать такой инструмент, как BrowserStack.

3) Сервисы, позволяющие провести кросс-браузерное тестирование. Тут мы расскажем только об одном сервисе. С другими можно ознакомиться по ссылке.

https://docs.google. com/document/d/1z9RPNrr84ocWFoz2g8gQWfeAb9DGVlPveFTur4jD7iM/edit

http://www.browserstack.com/

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

Полный список можно посмотреть здесь: www.browserstack.com/list-of-browsers-and-platforms

А вот чем данный ресурс интересен, так это разнообразием возможностей. В разделе "Responsive" можно бесплатно посмотреть свой сайт на разных мобильных устройствах (их эмуляциях) но, увы, только на родных браузерах.

Раздел "Screenshots" предсказуемо предлагает массовый тест с получением скриншотов. Кроме того есть возможность указать таймаут до изготовления скриншота, что дает хоть какой-то контроль над этим тестом.

"Screenshots" и "Responsive" обслуживаются как единое целое, доступны 100 скриншотов бесплатно. Далее 39$ в месяц. План от 199$ дает доступ к API для автоматического получения скриншотов.

Раздел "Live" — возможность забраться на выбранную ОС и посмотреть сайт в желаемом браузере, или посмотреть эмуляцию желаемого мобильного устройства. Доступно 30 минут бесплатно, далее тарифы начинаются от 39$ в месяц.

И, собственно, что выделяет данный сервис из остальных — раздел "Automate", где можно получить доступ к API, позволяющему реализовать тесты на Selenium на стороне сервиса в желаемых ОС и браузерах. Доступно 100 минут бесплатно. Тарифы начинаются от 99$ в месяц за максимум 8 (2 потока по 4) часов в день.


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

Недостатки — мобильные устройства эмулированные



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

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

Другой вариант - мобильная версия сайта. Чтобы сделать сайт удобным для мобильных пользователей создается отдельная версия сайта, специально ориентированная на пользователя со смартфоном/планшетом.

Раз речь зашла про адаптив, стоит упомянуть и особенность ретина экранов. Особенность дисплея Ретина — это двойная плотность пикселей. Разметка сайта на дисплее Ретина не ломается, просто сайты выглядят нечеткими и видно артефакты на изображениях с низким разрешением. Вообще, мы предлагаем взять за правило — требовать от дизайнеров и верстальщиков иконок в SVG. Адаптивный формат избавит вас от головной боли при различных разрешениях экрана.

Если для мобильной версии разрабатывается свой дизайн и рисуются свои макеты, по которым и можно проверить правильность верстки. То для адаптивного дизайна проверяется корректность отображения сайта на устройстве при изменении ширины браузера. Помните про проверки граничных значений: при ручном изменении ширины браузера с одного брейк поинта на другой — изменение расположения блоков должно происходить корректно как минимум. А как максимум — плавно.

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

Теперь повторим очень важное заявление: МЫ ПРОТИВ ЭМУЛЯТОРОВ!

Рады поделиться с Вами лайфхаком, как можно удобно протестировать мобильную верстку, выводя изображение с экрана мобильного устройства на экран ПК. Для IOS девайсов есть приложение - Air Server, которое дублирует экран устройства на мониторе вашего компьютера. Т.о., открыв на том же мониторе макеты мобильной верстки и растащив макет и картинку с экрана по разным сторонам монитора, можно заняться тестированием верстки.

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


тестирование верстки
Валидация кода
Что такое W3C и зачем валидировать html. Сейчас объясним
HTML-валидатор - инструмент, который производит проверки непосредственно самого HTML-кода. Основные из них:

Валидация синтаксиса — проверка на наличие синтаксических ошибок.

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

Валидация DTD — проверка соответствия кода указанному Document Type Definition. Она включает проверку названий тэгов, атрибутов, и «встраивания» тэгов (тэги одного типа внутри тэгов другого типа).

Проверка на посторонние элементы — проверка выявляет все, что есть в коде, но отсутствует в DTD. Например, пользовательские тэги и атрибуты.


Плюсы:

Основным аргументом ЗА валидацию HTML является обеспечение кроссбраузерности. Каждый браузер имеет свой парсер и «скармливать» ему то, что понимают все браузеры — это единственный путь быть уверенным, что код будет работать правильно во всех браузерах. Поскольку каждый браузер имеет свой механизм коррекции ошибок HTML нельзя полагаться на невалидный код.


Минусы:

Основным аргументом ПРОТИВ валидации является то, что она слишком строгая и не соответствует тому, как на самом деле работают браузеры. Да, HTML может быть невалидным, но все браузеры могут обрабатывать некоторый невалидный код одинаково.

Очень долго проверять

И актуально только для статических страниц


По адресу http://validator.w3.org располагается, пожалуй, самый распространенный инструмент для проверки отдельных страниц на валидность. Сайт предлагает три способа проверки: по адресу, локального файла и введенного в форму кода.
тестирование верстки
Описание ошибок
Чем ошибка по функционалу отличается от ошибки по верстке? Спойлер: ничем
Не менее важно, после того как ошибка найдена, суметь ее правильно описать. Хотим поделиться своими требованиями к баг-репорту по тестированию верстки:

  1. Заголовок — в нем указать блок или раздел, в котором произошла ошибка, а также емкое короткое описание ошибки.

  2. Ссылка на страницу или раздел, где воспроизводится проблема.

  3. Предусловие (если оно необходимо).

  4. Описание ошибки с полученным результатом.

  5. Браузер (или список браузеров) и его версия, на которой проводилась проверка. Название устройства. Версия операционной системы устройства. Положение устройства (портретная или ландшафтная ориентация).

  6. Ширина экрана.

  7. Скриншот или видео ошибки (скриншот должен содержать URL адрес).

  8. Приоритет.

  9. Статус.

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

https://docs.google.com/document/d/1TNKUPON7sqFwM0dsz8d2UcRHqTfQoM9T7rosX8vf9AI/edit

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

  1. Сложность верстки. Количество элементов на странице, объем страницы, а также дополнительный функционал верстки.

  2. Количество браузеров. Есть список браузеров, составленный по требованию заказчика, но золотой минимум - топ актуальных браузеров + мобильных устройств.

  3. Количество ошибок. Частое несоответствие макетам или вообще все развалилось!

Поэтому, закладывая время на тестирование верстки, стоит посмотреть верстку хотя бы одной страницы тестируемого сайта хотя бы в одном браузере, чтобы иметь РЕАЛЬНУЮ картину того, насколько сайт соответствует макету (если он есть) или выглядит/не выглядит корректно (на ваш взгляд). Ну и после, посчитать суммарное время на тестирование всего сайта не составит труда:

t = nB*nP*tPP

nB - кол во браузеров,

nP - кол-во страниц,

tPP - время на 1 страницу (отличается для PP и на глаз).


завершающее задание
Тестовое задание
Проверьте и закрепите свои навыки, которые вы получили в этом уроке
Помогите клиенту принять решение. Добавьте фразу и кнопку целевого дейставия.