Суть
Что такое фронтенд? Это «лицо» системы, графический интерфейс пользователя (GUI) веб-сайта или веб-приложения — посредством которого пользователь взаимодействует с веб-сайтом или веб-приложением.
Иными словами, фронтенд является как бы публичной частью или, если понимать буквально, «передним концом» ИТ-продукта, то есть той частью цифрового продукта, которая всегда «лицом к пользователю».
Таким образом, тестирование фронтенда (frontend testing) — это проверка юзабельности и функциональности интерфейса сайта/приложения.
Проще говоря, проверка вида и срабатывания меню, форм, кнопок и других элементов, с которыми работает пользователь/клиент.
Почему это необходимость
При разработке сайта (приложения) его создатели хотят убедиться, что все работает корректно и «не будет сюрпризов на проде». И что клиент (пользователь) останется доволен продуктом.
Этого достигают, концентрируя усилия на легкости и простоте использования, идут по тому же пути что и пользователь «идет по приложению», то есть оптимизируют навигацию, пытаются её упростить и приспособить под нужды предполагаемого «среднего пользователя».
Есть в качественном тестировании фронтенда и интерес разработчиков. Кроме надежного деплоя на проде (то есть приложение должно гарантированно работать), нужно обеспечить стабильную работоспособность приложения/сайта на протяжении всего пути пользователя (таким образом обеспечив покрытие бОльшей части значимых дефектов, то есть гарантировать работоспособность «в целом»).
То есть нужно обеспечить работоспособность в пограничных случаях (edge cases), уязвимых и/или критически важных частях приложения/сайта. Обращая особое внимание (ведь речь идет о фронтенде с его особенностями) на «бесконечные загрузки» или «состояния ошибки», из которых пользователь не знает как выйти.
В зависимости от ситуации и от имеющихся требований, фронтенд могут тестировать вручную, или автоматизировать все или большую часть тестовых операций. Суть тестирования фронтенда — проверка клиентской («браузерной») части приложения (сайта) — и эти операции успешно автоматизируются.
Пример. На любом сайте есть кнопки отправки пользовательских данных из формы (или выбора варианта, etc), и нужно верифицировать выполнение этих действий; а также всегда есть гиперссылки, нажатие на любую из них также проверяется; нажатие кнопки влечет за собой какие-то действия на сервере — обработку данных; тестирование обработки на сервере уже является частью тестирования бекенда.
Далее, качественно выполненное тестирование фронтенда обеспечивает надежную защиту от избыточного регресса, то есть излишнего количества операций при регрессионном тестировании. То есть, когда добавлен код сложной необходимой функции, но в части фронтенда не протестирован, и в результате возникли проблемы с другими частями сайта/приложения.
Случается также, что разработчики забывают о проблемном коде, написанном давно, и кое-как протестированном, и добавляют новый код к существующему, что приводит к проблемам на фронтенде. Так бывает в проектах с большим количеством команд и разработчиков. Современные приложения сложные, состоят из огромного количества компонентов, никому не получится реализовать большой проект в одиночку или небольшой командой; и никто не в состоянии знать всё о каждой части кодовой базы. Поэтому тестирование фронтенда — это также проверка, что одни части кода не конфликтуют с другими, и что функциональность на фронтенде в идеальном состоянии.
Таким образом, формируется уверенность в качестве кода — исключаются ситуации, когда пользователи не смогут воспользоваться приложением, или раздраженно удалят его после нескольких минут использования.
QA-департамент вовремя найдет ошибку на фронтенде, или это сделает бета-пользователь (скажем на альфа- и бета-стадиях), ошибка будет вовремя исправлена, и до конечного пользователя она не дойдет. Далее этот дефект будет покрыт повторным тест-сьютом, чтобы 100%-но гарантировать, что он потом не проявится снова.
Итак, чем лучше, качественнее проведено фронтенд-тестирование, чем легче и быстрее будет проходить развертывание (деплой). Руководство департаментов и стейкхолдеры, несомненно, будут удовлетворены, зная что разработка идёт в стабильном и прогнозируемом темпе. Это позволит им надежнее планировать операции департамента.
Ещё одна веская причина качественно проводить фронтенд-тестирование: такие тесты выступают в качестве live-документации. Написание тестов требует понимания логики проекта и правильного описания, что этот конкретный тест делает, и с чем связан тестируемый компонент приложения.
Тесты фронтенда часто включают моки к API компонентов, которые могут выступать в качестве гайдлайнов для разработчиков в будущем. В отличие от написанной вручную документации в виде README-файлов, такие гайдлайны «живут внутри проекта». Если тест просрочился/устарел, он возможно приведет к ошибкам, которые заставят обновить документацию, что часто забывают делать, если она пишется вручную.
Составление тест-сьютов на фронтенде (грамотное группирование тест-кейсов фронтенда) может, и должно, улучшать читабельность и устранять дублирование кода.
Когда разработчику понадобится протестировать небольшую часть кода, и окажется что нужно подтягивать еще излишние моки/компоненты, это заставит рефакторить такой код.
«Чистый код» лучше тестируется, а хороший тестабельный код — как правило «чистый». Лучше для фронтенд-разработчиков, и в конечном счете для конечных пользователей.
Что тестируют на фронтенде
Оптимизируют производительность и улучшают user experience.
До наступления эпохи web 2.0 веб-приложения были статическими. То есть обработка данных производилась на стороне сервера (бекенде), и оптимизация производительности тоже на бекенде. Теперь веб-приложения динамические, значит нужно оптимизировать код фронтенда.
Фокус на таких вещах:
- Кроссбраузерная и кроссплатформенная функциональность — проверка функциональности и респонсивности приложения на разных платформах, девайсах и браузерах.
- Доступность — проверка доступности приложения любому пользователю, включая не только людей с визуальными или слуховыми проблемами, но и например для водителей во время движения.
- Сквозное тестирование — для проверки пользовательских путей по приложению end-to-end, воспроизводя действия реальных пользователей.
- Тестирование отображения рисунков и фото — стандартный сайт или веб-приложение сейчас подгружает множество изображений, в том числе в высоком разрешении; баннеры, логотипы, фотографии. Изображения значительно, в десятки и сотни раз, увеличивают размер среднего приложения (сайта). И, разумеется, для проверки корректности их отображения желательно проводить соответствующее тестирование, с последующей оптимизацией изображений, и при необходимости коррекцией релевантного кода сайта/приложения.
- Тестирование CSS — каскадные таблицы стилей, если прописаны некорректно, ухудшают user experience, поэтому бывает нужна проверка синтаксиса и отображения CSS. Синтаксис это ответственность разработчиков, а отображение CSS — тестировщиков; обычно отображение тестируется как часть регресса после изменений.
Челенджи
Определить самые важные части фронтенда
Тестирование фронтенда затрагивает множество компонентов UI в самых разных сочетаниях в зависимости от проекта: форматирование, видимый текст, графика и CSS. Также функциональные аспекты: кнопки, формы, ссылки.
Проверяют респонсивность, как быстро загружаются компоненты UI и как реагируют; комфортно ли время отклика на действия пользователя, как быстро обрабатываются пользовательские функции, возвращают ли желаемый результат.
Имея перед собой такой объём компонентов, нужно приоритизировать эти проверки. В стандартном виде: присвоить приоритеты группам компонентов, начиная с основного текста, скорости загрузки страниц, видимости и доступности критически важных элементов, которые должны быть на своих местах и работать безукоризненно. Далее убедиться, что другие важные функциональные элементы видимы и отвечают на все действия и запросы. Завершаем проверкой форматирования и качества графики.
Эмуляция реального окружения
Заметную сложность составляет эмуляция работы приложения в реальном окружении. Тестовое окружение всегда контролируется, в отличие от реального, поэтому тяжело составить правильное впечатление, как будет себя вести приложение/сайт вне контролируемого окружения.
Хотя и сложно воссоздать реальное окружение для всех возможных пользователей, вполне реально подготовить тесты, достаточно близко воспроизводящие условия, в которых работает большинство пользователей. Особенно что касается производительности: можно эмулировать нагрузку большого количества одновременных пользователей и запросов. Также можно лимитировать доступную память, мощность процессора, или скорость подключения к сети.
Инструменты
Об инструментах будет подробно в конце, сейчас же кратко обозначим важный момент: при выборе инструментов следует сосредоточиться на правильном наборе функций. Типичный инструмент тестирования фронтенда включает:
- Простое создание и обслуживание тестовых сценариев
- Инсайты по метриках производительности
- Хорошие возможности по репортам
- Бесшовная интеграция с другими инструментами
- И конечно автоматизация
Автоматизация подразумевается по умолчанию, вручную выполнять все тесты с каждым апдейтом нереально.
Человеческий фактор
Существует «софт»-фактор, влияющий на процесс, а именно люди, исполнители. Здесь не имеется в виду, что тестировщики обязательно будут ошибаться в процессе; скорее, что существует вероятность того что разработчики будут склонны пропускать какие-то тесты или этапы цикла по своим причинам. Или же, клиенты могут влиять на процесс, заставляя ускорять релиз. Или руководство проекта, видя недостаточность ресурсов или исполнителей, примет решение изменить процесс.
По некоторым причинам в компании могут существенно уменьшить выделенные ресурсы на фронтенд-тестирование; здесь может быть уместной метафора «разбитого окна»: утверждается, что если проблема видима, но не устраняется, она становится привычной, хоть и не раздражающей, пока ситуация не придет к тому, что проблема становится всеобъемлющей. Применяя метафору к тестированию фронтенда, можно предполагать, что если такое тестирование проведено небрежно, и код написан некорректный, или его состояние неизвестно, эта плохая практика будет воспроизводиться в будущем, а проблемы в продукте будут накапливаться.
Лучшие подходы
Желательно соблюдать проверенные практики при написании тестов.
F.I.R.S.T-принципы
Хороший тест — это:
- Быстрый
- Изолированный (то есть независимый от других)
- Воспроизводимый
- Само-валидируйщийся
- Полный (основательный)
Большинство этих понятий самоочевидны, но уточним: тесты должны быть быстрыми (на любом этапе цикла), изолированными (в том числе от не протестированных компонентов), легко воспроизводимыми в будущем, способными валидировать себя (независимо от того прошел тест или нет), и полными в том смысле, что покрывают все нужные переменные.
Тестовая пирамида должна быть пирамидой
А не чем-то другим (о чем-то другом у нас есть соответствующий материал). Принцип должен соблюдаться, и так процесс будет наиболее правильным. У разработчиков должно хватать времени и желания на качественное выполнение своей части работы — чтобы руководству не пришлось потом во всём полагаться на тестировщиков, заставляя их делать например сложные сквозные в большом количестве, или вообще нагружая несвойственной им работой. Количество юнит-тестов должно быть самым большим; интеграционных уже намного меньше; а сквозных вообще мало, в идеале только критические пользовательские пути.
Приоритизация элементов фронтенда
Фронтенд — это могут быть даже сотни тысяч отдельных элементов UI (функций). Элементы это CSS, текст, графика, формы, линки, кнопки. Разумеется, все это проверить невозможно, без приоритизации не обойтись. В приоритете должны быть: скорость загрузки страницы, базовый (видимый пользователю) текст, изображения (иконки и логотипы), далее главные функции (например в случае магазина — добавление в корзину и оплата), далее графика по ситуации и всплывающие окна, если таковые имеются. Приоритетные элементы должны быть в любом случае видимые и респонсивные. И завершаем остальной графикой и форматированием.
Реальные браузеры и девайсы
Очень желательно, если стоит задача обеспечить надежность, использовать реальные устройства и браузеры — тогда тестовое окружение (почти полностью) соответствует реальному. Эмуляторы и симуляторы, безусловно, дают временную экономию времени и средств — но потом возможно придется переписывать код и еще раз тестировать.
Разновидности
Юнит-тестирование
Фундаментальный уровень. Анализ компонентов и функций и проверка их поведения. Как упоминалось выше, в разделе лучших практик, этому уровню необходимо уделять внимание, это укрепляет стабильность кодовой базы и надежность приложения после релиза.
Подробнее о юнит-тестах на фронтенде
Приемочное
Подтверждение пользовательских вводов, пользовательских путей (то есть user flow), и присвоенных им действий. Выполняется приёмка продукта, чтобы убедиться что финальная версия работает так, как ожидалось при проектировании, как ожидают конечные пользователи.
Визуальное регрессионное
Особый подвид фронтенд-тестов. Сравнивается имеющийся интерфейс с ожидаемым (спроектированным), определяя недостатки/проблемы. В общем случае сопоставляют скриншоты из headless-браузера, запущенного на сервере, и на условно пользовательской машине, сравнивая изображения и затем вносят корректировки.
Доступности
Об этом уже было выше; разновидность юзабилити-тестирования, когда ищут проблемы, мешающие каким-то категориям людей пользоваться продуктом, его отдельными функциями, особенно недостатки в навигации.
Производительности
Анализ производительности сайта/приложения, изучение скорости загрузки, стабильности, масштабируемости, совместимости и респонсивности («отзывчивости» на действия пользователя, плавности интерфейса в сочетании с комфортной его скоростью). Приложение (или сайт) с плохой производительностью, неспособное к расширению пользовательской базы, и грубо говоря тормозящее — не оправдает надежд не только пользователей, но и руководства проекта.
Сквозное
От начала до конца по пути пользователя, имитируя его действия, нащупывая подводные камни, особенно в интерфейсе и API. При этом получают инсайт о всей системе в целом.
Интеграционное
Все современные приложения состоят из множества связанных модулей, и качество связей проверяет интеграционное фронтенд-тестирование.
Подробно о тестировании интеграции
Кроссбраузерное
Собственно, уже сказано выше; один и тот же набор тест-кейсов выполняется в разных браузерах. Успешно автоматизируется.
Подробно + таблицы распространенности девайсов/платформ/браузеров
Инструменты
Перейдем к инструментам. Возможных инструментов, применимых на фронтенде, существуют сотни. Попытаемся обозначить самые распространенные.
Jest
Вероятно, самый популярный JS-фреймворк (после Selenium) с упором на скорость и простоту применения. Параллельное выполнение тестов. Умеет сначала запускать падавшие ранее тесты, и реорганизовать запуски смотря по времени выполнения. Обеспечивает большое тестовое покрытие и удобную работу с моками.
Selenium WebDriver
Кроссбраузерные тесты. Selenium — все еще инструмент веб-тестировщика №1. Поддерживает все языки.
Cypress
Фреймворк автоматизации веб-тестов на JS. Любят и разработчики, и тестировщики (пруф), видимо из-за простого синтаксиса.
WebDriverIO
Автоматизация «веба и мобайла». Простые операции с тестируемым приложением, набор плагинов.
WebDriverJS
Официальная JS-имплементация Selenium, использующая JSON-wire-протокол для работы с браузерами. Почти то же, что Selenium WebDriver.
TestCafe
Node.js-инструмент для автоматизации, открытый, бесплатный, есть end-to-end-возможности.
План при тестировании фронтенда
Бюджет
Перед тем как выбрать инструменты и назначить команду, проджект-менеджер уточняет бюджет проекта.
Инструменты
Зависит от особенностей фронтенда в проекте, и от требований.
Таймлайн
Здесь нужна гибкость, ведь может получиться, что приложение выпущено в срок, а по факту некачественное.
Область тестирования
Должен ли проект быть выпущен в состоянии близком к идеальному, или, возможно, будет достаточно минимально рабочей версии; будет ли учитываться фидбек пользователей, планируется ли быстрое расширение.
***
