Home

Автор: Мария Дрейк (Marie Drake)
Оригинал статьи
Перевод: Ольга Алифанова

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

Выбор подходящих инструментов

Во-первых, нужно подумать о выборе подходящего для задачи инструмента. Существуют плагины визуального тестирования, напрямую интегрирующиеся в вашу тестовую библиотеку или любимый фреймворк. Некоторые позволяют расширить существующие функциональные тесты, а некоторые – писать абсолютно новые. В зависимости от используемой библиотеки или фреймворка, выбор подходящих инструментов – самый важный аспект добавления визуального тестирования к тест-стратегии. Сейчас на рынке есть множество подобных инструментов – от платных вроде Applitools, Percy, Happo и Chromatic, до библиотек с открытым исходным кодом – например, as AyeSpy, BackstopJS, Wraith, cypress-image-snapshots и многих других. Каждый доступный инструмент нужно проанализировать, чтобы выбрать наиболее подходящий для ваших конкретных требований.

Уровень визуального тестирования

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

Поддержка браузеров

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

Поддержка тестов

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

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

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

Интеграция в процессы

Каков ваш план по интеграции визуальных тестов в ваши процессы непрерывной интеграции? Будете ли вы прогонять их при каждом пулле или мердж-реквесте, чтобы получить быструю обратную связь, или же они будут проводиться только при заливке кода в окружение QA/Stage? Будут ли они прогонятся при каждом коммите, или эта задача запускается вручную человеком, создавшим запрос?

Опыт разработчиков

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

Эталонные изображения

Визуальное тестирование работает, сравнивая тест-изображения с набором эталонных изображений, служащих источником истины. Как вы будете их хранить? Платные плагины позволяют вам хранить эталоны на своих серверах, а при использовании бесплатных надо подумать, как вы будете делиться эталонными изображениями с командой. Вы можете размещать их в репозиториях github, но представьте, если таких изображений сотни – это не идеальное решение. Нужно хранить их в специальном сервисе вроде S3 bucket, поэтому тут понадобится дополнительный труд. Поговорите с командой разработки, какое решение может всех устроить.

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

Работа с динамическими данными

Чтобы избежать массы ложноположительных результатов и падений визуальных тестов, подумайте, как быть с динамическими данными. Большинство плагинов визуального тестирования использует алгоритмы попиксельного сравнения, и вам нужно убедиться, что тестируемая страница по-максимуму очищена от динамических данных. Некоторые техники борьбы с ними включают использование фикстур данных для их имитации, остановку анимации и статичные дату и время. Если вы хотите сравнивать динамические данные, то инструменты вроде Applitools используют ИИ-алгоритмы для сравнения изображений так же, как их сравнивал бы человек. Другой вариант – если вы и ваша команда решили, что динамических данных не будет, эти инструменты умеют исключать определенные элементы, делая снимки экрана.

Ограничения по бюджету и времени

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

Отчетность

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

Сообщество и техподдержка

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

Заключение

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

Обсудить в форуме