То, что видно на экране, – единственное, что имеет значение для конечных пользователей. Компании необходимо проверить, как выглядит и функционирует сайт, прежде чем он будет запущен в эксплуатацию. Чтобы обеспечить безупречный графический интерфейс пользователя (GUI), необходимо провести тестирование фронтенда (frontend testing).
В этой статье рассмотрено, что такое тестирование фронтенда, его виды, важность и чем оно отличается от тестирования бэкенда (backend testing).
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Что такое тестирование фронтенда?
Фронтенд – это клиентская часть программы. Можно сказать, что она включает в себя все, что видит пользователь при взаимодействии с приложением. Любое веб-приложение имеет трехуровневую архитектуру: клиент, сервер и база данных. Презентационный слой включает в себя клиента. Тестировщики фронтенда тестируют этот слой. Они выполняют тестирование графического интерфейса и удобства использования сайта или приложения.
Например, нужно протестировать приложение для покупок. Проверки будут включать оценку соответствия внешнего вида сайта требованиям клиента и работы таких необходимых функций, как поиск и добавление товара в корзину. Тестирование фронтенда охватывает широкий спектр стратегий и техник, но прежде чем погрузиться в эту тему, следует рассмотреть, чем тестирование фронтенда отличается от тестирования бэкенда.
Чем отличаются фронт- и бэкенд тестирование?
Бэкенд приложения включает в себя серверный уровень и базу данных. Другими словами, в нем заложены функциональность и бизнес-логика, обеспечивающие работу приложения.
Тестирование бэкенда не затрагивает пользовательский интерфейс (UI) приложения. В основном оно проверяет, как в базе данных хранится информация, поступающая от клиента или сервера. Кроме того, тестировщики оценивают, как отправляются запросы к базе данных и какие ответы приходят на сервер.
Итак, в чем же основные различия двух видов тестирования?
Знания
В первую очередь тестировщики фронтенда работают с требованиями заказчика. Кроме того, им необходим опыт работы с фреймворками автоматизации для оптимизации процесса тестирования. Тестировщики бэкенда, в свою очередь, должны обладать знаниями о базах данных и SQL-запросах.
Что тестируется
Тестировщики фронтенда проверяют, соответствует ли графический интерфейс приложения требованиям. Кроме того, они должны оценить каждый элемент, например, кнопки, ярлыки, поля ввода и т.д.
Тестирование бэкенда включает в себя работу с базой данных, при этом графический интерфейс может и не использоваться. Тестировщики проверяют, нет ли потери данных или взаимной блокировки.
Инструменты
К числу важных инструментов для тестирования фронтенда относятся Grunt, Karma, Mocha и многие другие. Популярными инструментами для тестирования бэкенда являются TurboData, Data Generator и другие инструменты для тестирования API.
Зачем тестировать фронтенд?
Конечные пользователи не очень хорошо представляют себе, как работает бэкенд. Они сталкиваются только с теми проблемами, которые возникают в пользовательском интерфейсе. Чтобы быть успешным, приложение должно быть быстрым и работать без сбоев. Именно здесь на помощь приходит тестирование фронтенда, при котором оценивается работа программы на различных устройствах и браузерах.
W3C (The World Wide Web Consortium) ввел новые критерии, касающиеся дизайна, юзабилити и доступности веб-приложений. HTML-код должен соответствовать определенным стандартам, а сайт — быть доступен для всех, особенно для людей с ограниченными возможностями. Вот почему тестирование на доступность обязательно входит в список проверок фронтенда.
Кроме того, Интернет вещей (IoT) вывел разработку приложений на качественно новый уровень. С широким распространением взаимосвязанных приложений на смарт-часах, смартфонах и “умных” телевизорах тестирование фронтенда стало необходимым для проверки поведения программы в многоуровневой архитектуре.
Типы тестирования фронтенда
Разработчики отвечают за согласованную и стабильную работу продукта. Но они не могут добиться этого без тестировщиков. Тестирование фронтенда охватывает множество стратегий. Чтобы понять, что лучше всего подходит для вашего проекта, необходимо знать типы тестирования фронтенда.
Модульное тестирование (Unit Testing)
Каждый фрагмент кода должен функционировать независимо. Под модулем понимается наименьшая часть программного обеспечения, которую можно тестировать. Модульное тестирование – это самый низкий уровень тестирования. Здесь тестировщики проверяют отдельные компоненты программы или приложения. Данный тип тестирования позволяет убедиться в том, что отдельные части кода работают в соответствии с ожиданиями. Модульное тестирование включает в себя вычисления и проверку входных данных.
Приемочное тестирование
При приемочном тестировании тестировщики оценивают соответствие системы бизнес-требованиям. После этого они проверяют, насколько продукт готов к запуску. Например, если вы собираете дом из конструктора Lego, вы проверяете, идеально ли подогнана каждая деталь. Это относится к модульному тестированию. Следующий шаг – убедиться, что все инструкции из требований были выполнены. Приемочные тесты сканируют работающее приложение. Они проверяют правильность логики User flow, реакций приложения на ввод определенных данных и т.д.
Регрессионное тестирование
Всякий раз, когда в приложение вносится какое-либо изменение, существует вероятность того, что какая-то из ранее существовавших функций может выйти из строя. Вот тут-то и пригодится регрессионное тестирование. Визуальное регрессионное тестирование – это еще один вид регрессионного тестирования, связанный с пользовательским интерфейсом. Оно предполагает создание скриншотов пользовательского интерфейса и сравнение их с предыдущими изображениями. Визуальное регрессионное тестирование характерно только для фронтенда. Тестировщики используют специальные инструменты сравнения изображений для выявления различий между двумя снимками.
Тестирование доступности
Как было сказано выше, тестирование доступности призвано обеспечить возможность работать с приложением всем желающим, в том числе и людям с ограниченными возможностями. К ним относятся пользователи старшего возраста, а также люди с нарушениями слуха и зрения. Тестирование доступности в основном включает в себя проверку совместимости приложения с программами чтения с экрана (screen reader).
Тестирование производительности
Производительность сайта или приложения имеет первостепенное значение для пользователей и бизнеса. Тестирование производительности определяет стабильность, отзывчивость и скорость работы продукта. Кроме того, оно позволяет определить, как работает устройство в определенных условиях. Существует множество инструментов для тестирования производительности. Большинство из них работают по принципу “подключи и работай“. Однако некоторые инструменты позволяют кастомизировать ход выполнения тестов.
Сквозное тестирование (End-to-End Testing)
Сквозное тестирование – это валидация приложения полностью, от начала до конца, то есть оно гарантирует, что приложение будет вести себя в соответствии с ожиданиями на протяжении всего времени его работы. Оно также выявляет системные зависимости и обеспечивает целостность данных.
Интеграционное тестирование
Интеграционное тестирование объединяет различные блоки приложения и тестирует их как единое целое. Можно протестировать отдельные функциональности и убедиться, что они работают без дефектов, но это не гарантирует, что после интеграции не возникнут проблемы. Например, выпадающий список на сайте может перестать работать после того, как он будет интегрирован в панель навигации. В случае, если какая-то функциональность еще не готова или к ней нет доступа, используются тестовые заглушки и тестовые драйверы.
Тестирование кросс-браузерной совместимости
Тестирование кросс-браузерной совместимости является одним из важнейших типов тестирования фронтенда. Оно направлено на обеспечение одинаковых возможностей для пользователей различных браузеров, ОС и устройств. Иными словами, функции, доступные в одном браузере, должны быть доступны и в других.
Как создать тест-план?
План тестирования помогает определить потребности проекта и выстроить оптимальную стратегию процесса. Ниже рассмотрены основные нюансы, на которые стоит обратить внимание при создании тест-плана.
Подсчет бюджета
Необходимо заранее рассчитать, какие суммы будут затрачены на необходимые инструменты и работу сотрудников. Даже если бюджет ограничен, можно обеспечить высокое качество тестирования путем оптимизации расходов. Например, если приложению требуется кросс-браузерное тестирование, можно сэкономить на покупке различных устройств, браузеров или операционных систем, воспользовавшись облачной платформой.
Подбор инструментов
По мере того как происходит подсчет бюджета, необходимо составить список инструментов, которые будут использованы в ходе тестирования. При тестировании фронтенда возникает множество задач, и не всегда их можно решить с помощью одного инструмента. Заранее принятое решение о том, какие инструменты будут использованы, будут ли они платными или бесплатными, поможет ускорить процесс тестирования и точнее рассчитать затраты.
Определение временных рамок
Работа по Agile методологии подразумевает установку жестких временных рамок. При тестировании фронтенда необходимо охватить множество аспектов, в связи с чем нехватка времени может стать серьезным ограничением. Вот почему важно заранее определить, сколько времени понадобится для каждого этапа тестирования.
Оценка масштабности проекта
Существуют различные браузеры, ОС и устройства. Для обеспечения высокого уровня тестирования необходимо знать, чем пользуется целевая аудитория, чтобы верно определить масштабность проекта. Это поможет подобрать оптимальные инструменты тестирования и в конечном итоге сократить расходы и время на разработку.
Популярные инструменты для тестирования фронтенда
Различные инструменты тестирования выполняют различные функции. В связи с этим выделяют следующие типы инструментов:
Инструменты для запуска тестов (Test Launchers)
Запустить тест в Node.js или браузере можно с помощью средств запуска тестов. Они используют интерфейс командной строки (CLI) или пользовательский интерфейс (UI) с пользовательской конфигурацией. Инструменты для запуска тестов входят в состав различных фреймворков, например, Karma, Jest, Jasmine и др.
Assert функции
Инструкции assert — это булевы выражения, которые проверяют, является ли условие истинным. Они определяют, соответствуют ли результаты тестирования ожиданиям. Среди инструментов для работы с assert функциями можно назвать Chai, Jest, Jasmine и TestCafe.
Отслеживание выполнения тестов
Еще одной обязательной задачей тестировщика является проверка хода выполнения теста. Поэтому тестировщики используют инструменты отслеживания состояния запланированного тестирования с помощью встроенных отчетов. Данная функция доступна в таких фреймворках, как Mocha, Jest, TestCafe, Jasmine и Karma.
Моки (Mocks) и заглушки (Stubs)
В модульном тестировании, чтобы уловить побочные эффекты тестов, необходимо изолировать некоторые части тестируемого приложения. Для этого используют моки (имитаторы), заглушки и их комбинации. Подобные функции обеспечивают Sinon, Enzyme, Jest, Jasmine и др.
Сравнение скриншотов
Сравнение скриншотов применяется для проверки правильности реализации изменений. Для этого используются инструменты Jest и Ava. Для автоматизированного сравнения снимков существует такая многофункциональная платформа, как Testim.
Покрытие кода
Каждый тест охватывает определенную часть кода. Покрытие кода – это показатель того, какой объем кода покрывают тесты. Parasoft Jtest и Cobertura – инструменты, позволяющие вычислить данный показатель.
Контроллеры браузера
Для функциональных тестов имитация действий пользователя возможна с помощью контроллеров браузера. Для этого тестировщики используют комбинацию различных инструментов. К ним относятся TestCafe, Nightwatch и Puppeteer.
Визуальная регрессия
Инструменты визуальной регрессии позволяют сравнить сайт с его предыдущей версией. К ним относятся Applitools, Percy и WebdriverCSS.
Проблемы тестирования фронтенда и способы их решения
Любая работа, будь то разработка или тестирование, сопряжена с определенными трудностями. Тестирование фронтенда не является исключением. Ниже рассмотрены некоторые общие проблемы и способы их решения.
Команда впервые использует автоматизацию
Тестирование фронтенда, особенно кросс-браузерное и регрессионное, требует автоматизации. Если команда использует автоматизацию впервые, она может столкнуться с трудностями при настройке и написании многократно используемых тест-кейсов. Перевод большого количества тест-кейсов из ручного тестирования в автоматизированное может занять много времени. В худшем случае команда не успеет завершить тестирование.
Чтобы избежать этого, следует начать подготовку еще до начала проекта и обучить команду тем фреймворкам автоматизации, которые будут использованы на проекте. Для оптимизации времязатрат тестировщики могут подготовить тест-кейсы до того, как команда разработчиков завершит свою работу.
Имитация “реального мира”
Еще более серьезной проблемой является то, что тестировщики не всегда могут угадать, как поведет себя реальный пользователь при работе с приложением. Трудно предсказать сценарии, отражающие то, как пользователь будет взаимодействовать с той или иной страницей или функцией.
Тестирование удобства использования позволяет оценить, как реальный пользователь будет использовать приложение. Можно попросить коллег или других членов команды воспользоваться приложением в качестве тест-группы. Это поможет убедиться, что не осталось сценариев, которые пропустила команда тестировщиков при написании тест-кейсов. Также стоит уделить внимание тестированию производительности. Оно покажет, как ведет себя приложение при одновременной работе с ним большого числа пользователей. Тестирование производительности позволит убедиться в том, что приложение готово к внезапному наплыву пользователей или большому количеству интернет-трафика.
Agile и регрессия
Agile предоставляет заказчику большую свободу действий. После завершения каждого спринта клиент может проверить приложение и попросить внести какие-либо изменения. Он может попросить вашу команду добавить определенную функцию или убрать ту, которая ему не нравится. При частых изменениях в приложении возрастает риск возникновения регрессионных ошибок.
Важно проводить регрессионное тестирование каждый раз после того, как разработчик выполнит запрос на изменение. Можно использовать инструменты визуальной регрессии и/или сравнения скриншотов. Эти инструменты позволят команде тестирования легко найти любые регрессионные ошибки, что значительно снизит вероятность возникновения значимых дефектов при развертывании приложения на сервере.
Фронтенд или бэкенд?
После обнаружения и заведения бага тестировщик должен назначить дефект на определенного разработчика для исправления. Например, было обнаружено, что одна ячейка в таблице базы данных отображает неверные данные. Сотрудник, отвечающий за фронтенд, может решить, что это проблема на стороне бэкенда, то есть код не может обеспечить получение корректных данных из базы. В свою очередь, разработчик бэкенда может сказать, что с его стороны код корректен, а баг кроется в коде фронтенда.
Чтобы предотвратить подобные проблемы, необходимо поощрять команду следовать лучшим практикам. Пусть они думают и работают как Agile-команда. В Agile тестировщики должны быть осведомлены о некоторых особенностях разработки, равно как бэкенд и фронтенд разработчики должны иметь представление о работе друг друга. Если тестировщик по ошибке назначает дефект не тому человеку, то этот человек должен разобраться в ошибке, найти ее первопричину и попросить соответствующего специалиста исправить ее.
Заключение
Даже самые незначительные ошибки могут повлиять на репутацию компании. Если пользователи заметят небольшую задержку или лаг на сайте или в приложении, они не задумываясь перейдут к конкурентам, предлагающим более качественный продукт. Несомненно, это делает тестирование фронтенда еще более важным.
Перевод статьи «Front End Testing: A Complete Conceptual Overview».