Нефункциональное тестирование Frontend части

Что такое нефункциональное тестирование для frontend части проекта? Какие бывают нефунциональные проверки? Когда и кто проводит такое тестированиеи и всегда ли при этом должен участвовать QA-инженер? Ответы на вопросы читайте в этой статье.

Екатерина Кузнецова
Екатерина Кузнецова · 13 ноября 2023
QA

Исходя из классификации тестирования существует два ключевых вида тестирования в соответствии с целями:

  1. функциональное тестирование - проверяется корректность работы функциональности приложения. Тестировщик проверяет выполняет ли продукт свои функции так, как это заявлено в требованиях, т.е. проверяет то, что система делает
  2. нефункциональное тестирование - тестирование свойств системы на соответствие нефункциональным требованиям. Тестировщик проверяет как система работает

В свою очередь нефункциональное тестирование можно разделить на:

Последние 5 пунктов этой классификации можно объединить в блок нефункциональных проверок frontend части приложения

1. Сравнение внешнего вида страницы с макетом

Заказчик может не принять работу, если вёрстка будет отличаться от согласованного макета. Поэтому веб-разработчик должен не просто сверстать сайт по образцу, а сделать это близко к согласованному макету.

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

Примеры инструментов, которые помогут тестировщику для проверки соответствия:

Но порой перфекционизм излишен и приводит к увеличению объема кода, а так же времени разработки. В случаях расхождений с макетом желательно обсудить правки с дизайнером или заказчиком: возможно, стоит внести правки в макет или проигнорировать ошибку.

2. Проверка адаптивности страницы

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

Чтобы «подогнать» вёрстку под разные разрешения, применяют один из подходов: адаптивный и респонсивный дизайн.

Адаптивный дизайн

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

При разработке адаптивного сайта создают несколько макетов фиксированной ширины. Стандартный набор состоит из шести самых популярных форматов: 320, 480, 760, 960, 1200 и 1600 пикселей. Если окно браузера например уменьшается до 960 пикселей, дизайн меняется под этот размер.

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

Пример адаптивного сайта https://www.apple.com/. Через инструменты разработчика если выбрать в настройках разрешений “Responsive” и плавно растягивать сайт, то можно увидеть как при определенных размерах верстка как-бы ломается и перестраивается.

Респонсивный дизайн

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

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

Пример респонсивного дизайна https://www.stoloto.ru/6x49. Если попробовать “растягивать” сайт то он плавно будет перестраиваться под любой размер без скачков в определенных точках.

Инструменты для проверки адаптивности

1. Инструменты разработчика в браузере

2. Онлайн-сервисы для проверки адаптивности

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

Одним из таких сервисов проверки адаптивности страницы под мобильные устройства является созданный компанией Google сервис Mobile Friendly. Указав в сервисе ссылку на вашу страницу, вы получите сообщение о том, оптимизирован ли ваш сайт под использование на мобильных устройствах.

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

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

3. Проверка локализации и интернационализации

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

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

Основные пункты для проверок:

  1. Установка и удаление продукта при использовании локали, отличной от дефолтной. Раз мы можем и должны использовать различные локали, то мы должны иметь возможность устанавливать и удалять приложение, используя любой язык.
  2. Настройка приложения на локали, отличной от дефолтной. Все изменения в настройках должны сохраняться и использоваться.
  3. Приложение должно работать на окружении, локаль которого отличается от дефолтной локали нашего приложения.
  4. При запуске приложения на новой локали вам нужно проверить, что форматы даты, времени, спец.символы алфавита, денежных валют, календари и прочие вещи, связанные с культурными особенностями можно переключать в приложении без каких-либо ошибок (вручную или автоматически). Как правило такие ошибки выявляются при первом запуске новой локали.
  5. Локализованный текст, изображения и прочие ресурсы не вшиты (hard-coded) в приложение. Баги такого рода вы найдёте достаточно быстро, ведь, к примеру, оставшиеся английские слова будут сразу видны на фоне азиатского текста.
  6. Обратить внимание на то, что документы (к примеру гайды, FAQ и т.д.) переключаются на нужный вам язык при смене локали.

4. Тестирование доступности

Accessibility testing - это тестирование приложения на соответствие рекомендациям документа W3C, а именно положению Web Content Accessibility Guidelines (WCAG) 2.1. Это проверка программ на пригодность к использованию людьми с нарушениями слуха, зрения, двигательной активности. По сути это часть Usability Testing.

Люди с ограниченными возможностями для использования программ применяют вспомогательные технологии, например:

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

Чек-лист для тестирования доступности может включать, среди прочих, следующие вопросы:

Подробный чек-лист для тестирования доступности (на английском) https://www.webfx.com/blog/web-design/website-accessibility-checklist/.

Чтобы протестировать доступность сайта или приложения, нужно встать на место пользователя. При тестировании используйте все инструменты ввода: клавиатуру, мышку, тач-скрин, голосовой ввод.

Автоматические инструменты и расширения для браузеров: aXe, Lighthouse и Wave. Проверяют код, контрастность, размер шрифтов и т.д. После проверки такие инструменты выдают грубые несоответствия и рекомендации по улучшению.

5. Тестирование удобства

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

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

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

На сегодняшний день применяются следующие критерии при оценке удобства и комфортности взаимодействия с веб-сайтами:

https://userinyerface.com/game.html - пример ужасно неудобного интерфейса (игра)

💡 Кто и когда проводит тестирование

Рациональнее всего проводить такое тестирование на этапе завершения разработки, до передачи фронтенд-разработчиком в работу QA. Это так называемый дизайн-ревью (или “прикрутка”). На стадии дизайн-ревью задача дизайнера состоит в том, чтобы сверять дизайн-макеты и логику работы вместе с фронтенд-разработчиком. На этапе ревью могут всплыть дополнительные нюансы, которые не были учтены в работе: забыли показать все состояния компонентов, шрифт на экранах плохо читаем, на дизайне контраст. Так же согласовать возможные варианты реализации, когда нет возможности со стопроцентной точностью выполнить разработку в соответствие с макетом.

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

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

Некоторые проверки могут проходить уже и после реализации приложения, на стадии продуктового тестирования, при сборе соответствующих метрик и, например, usability тестировании, которое проводят менеджеры продуктов. Опять же это не исключает роли QA в тестировании того же удобства до передачи приложения в продакшн, если изначально были поставлены подобные требования, а так же стоит на это обращать внимание на этапе прикрутки.

Список источников:

  1. https://htmlacademy.ru/blog/css/pixel-perfect
  2. https://habr.com/ru/articles/532836/
  3. https://habr.com/ru/articles/470091/
  4. https://testengineer.ru/chto-takoe-testirovanie-dostupnosti/
  5. https://testmatick.com/ru/zachem-i-po-kakim-kriteriyam-provodit-yuzabiliti-testirovanie/
  6. https://ru.hexlet.io/courses/css-adaptive/lessons/check-style/theory_unit