Контролируем стабильность верстки. Screenshot-Driven Testing

• Кому нужно тестировать верстку?
• Как можно контролировать верстку?
• Screenshot-driven testing
• Выбираем софт, автоматизируем процесс контроля верстки
• Проблема scroll’а при автотестах верстки
• Результат: Screenshot-driven testing (Gemini+BrowserStack) на службе народного хозяйства
• Примеры автоматического тестирования фронтенда и верстки
  • Попроще
  • Посложнее
• Сколько стоит автоматическое тестирование верстки?

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

Серверную сторону проверяют unit-тесты, пользовательские сценарии — Selenium-тесты , Zabbix проверит как справляется ваш сервер и хватает ли ресурсов.

Все эти проверки мы собираем в автоматическую систему контроля качества (continuous integration).

Но есть одна штука на сайте, которую так не проверишь: внешний вид, верстка.

Современный сайт имеет адаптивную верстку , кучу скриптов и должен работать в доброй сотне конфигураций браузер-устройство-разрешение .

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

Это — проблема, и ее надо решать.

Чип и Дейл Отдел сопровождения сайтов ИНТЕРВОЛГИ спешит на помощь и решает этот вопрос.

Представляем вам методику  Screenshot-Driven Testing :-)

Кому нужно тестировать верстку?

Но если у вас:

• сложный фронтенд — адаптив, много эффектов, сложная логика в разных браузерах;

• часто меняются html, стили и клиентские скрипты;

• несколько разработчиков;

• применяются визуальные wysiwyg-редакторы, позволяющие менять стили на странице;

• business-critical сценарии зависятот верстки (например, оформление заказа на мобильных сделано так сложно, что от каждого чиха рассыпается),

то без контроля верстки вы обречены на проблемы.

Как можно контролировать верстку?

Способ первый : никак, клиенты расскажут или сами случайно заметим.

Минусы очевидны: несвоевременная реакция, потери заказов.

Способ второй : специально обученные люди.

Плюс: есть шанс что человек увидит проблему.

Минусы: есть риск, что человек НЕ увидит проблему. Глаза замыливаются. Да и долго очень.

Способ третий : автоматизация.

Автоматизация рулит. Расскажем как это работает.

Screenshot-driven testing

Идея:

1. Берем элементы сайта, которые мы хотим проверять на стабильность.

2. Получаем “эталонный внешний вид”.

3. Отслеживаем состояние этих элементов во всех браузеров.

4. При “ненормальных” отклонениях бьем тревогу.

Это тестирование, основанное на скриншотах.

Сказать легко, сделать сложнее.

Выбираем софт, автоматизируем процесс контроля верстки

Что должен уметь софт, который нам нужен?

Например, видеть css-регрессии (это когда в одном месте поправили, а в другом уехало)

Вот это микроскопическое смещение человек мог и пропустить.

Есть средства, которые это умеют. Кандидаты:

1. Автоматизация на Selenium

2. BackstopJS

3. Gemini

4. Ручной BrowserStack

Мы системно подошли к исследованию, вот результат: