5. ПРОВЕРЯЕМ РЕЗУЛЬТАТ

Авторы: Д. О. Теплякова
Время чтения: 10 мин.

КРАТКОЕ СОДЕРЖАНИЕ

Тестирование — важнейший этап разработки цифрового сервиса, к которому нужно привлекать совершенно разные группы пользователей, в том числе пожилых людей, людей с ОВЗ и инвалидностью.
Для обеспечения доступности необходим как этап автоматизированного тестирования, так и этап ручного тестирования с участием пользователей.
При автоматизированном тестировании разработчикам помогут такие инструменты, как «Сканер доступности» и Lighthouse: они проверяют сайт или мобильное приложение и предлагают варианты их доработки.
Состав рабочей группы по тестированию зависит от специфики сервиса; в большинстве случаев необходимо участие незрячего и слабовидящего пользователя, а также пользователя с нарушением моторных функций.
Для тестирования можно привлекать сторонние организации, которые проводят аудит, или нанять in-house тестировщика.
Обратная связь от пользователей с ОВЗ — ценный источник информации; нужно уметь правильно ее принимать и обрабатывать.

5.1 ЭТАПЫ И СПОСОБЫ ТЕСТИРОВАНИЯ

Тестирование — необходимый этап жизненного цикла продукта. Особенно это важно для крупных, социально значимых государственных сервисов: в этом случае запуск «сырого» продукта с серьезными недостатками и недоработками может вызвать массовое недовольство пользователей. Это недовольство с большой вероятностью не ограничится самим новым сервисом и его разработчиками, но распространится на государственные организации, стоящие за ним.
Во многих случаях тестирование цифрового сервиса ограничивается выяснением того, «все ли работает». Однако для создания по-настоящему доступного продукта этого недостаточно. При тестировании сервиса необходимо учитывать все аспекты доступности, о которых говорилось выше: возможность быстро найти сервис, разобраться в его устройстве и самостоятельно получить услугу, уровень юзабилити, качество языка, на котором создатели сервиса или государственные органы общаются с потребителями услуг.
«Нужно брать группу пользователей и выяснять у каждого, понял человек написанное или не понял и что именно он понял. Чем важнее документ, тем тщательнее придется его проверять экспериментально на группе обычных людей. Я филолог, мне проще — но я бы привлекал старшеклассников, пенсионеров. Если мы видим сомнения, затруднения или понимаем, что один человек понял текст так, а другой эдак, значит, что-то нужно менять».

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

1. Провести автоматизированное тестирование

Прежде чем проводить тестирование с пользователями, следует провести быструю автоматизированную проверку. Она позволит вам сэкономить время и быстро, без участия пользователей, определить:
  • неподписанные элементы, которые недоступны для незрячих;
  • элементы, контрастность которых недостаточна для слабовидящих;
  • элементы, размер кликабельной области которых меньше, чем требуется.
Для разработчиков на Android существует «Сканер доступности» (Accessibility scanner). Он проверяет мобильное приложение и предлагает варианты его доработки (расширение Lighthouse для веб-разработки проверяет аналогичные параметры в вебе).
Тестируются компоненты, важные для пользователей с ограниченными возможностями здоровья, а именно:
  • ярлыки контента;
  • размер области прикосновения;
  • элементы, реагирующие на клики;
  • контрастность текста и изображений.
Кроме того, можно воспользоваться такими инструментами, как:
  • HTML CodeSniffer — скрипт, который проверяет исходный HTML-код на соответствие определенному стандарту;
  • axe — расширение для браузера, разработанное компанией Deque, которое проверяет код на соответствие стандарту доступности;
  • WAVE — расширение, которое позволяет оценить уровень доступности веб-контента напрямую внутри браузера.
axe DevTools — Web Accessibility Testing // Интернет-магазин Chrome.
Если автоматизированное тестирование показало, что ошибок нет, это не значит, что тестировать продукт с пользователями не нужно, поскольку этот способ проверки показывает лишь часть дефектов доступности.

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

2. Провести ручное тестирование

Перед тестом с пользователем полезно пройти сценарий самостоятельно с помощью скринридера и без использования мышки, только с помощью клавиатуры.

3. Провести тестирование с участием пользователей

Без привлечения тех, кому больше всего нужна доступность, создать доступный продукт невозможно («ничего для нас без нас»). Человек, который использует инструменты экранного доступа каждый день, отличается от человека, который использует их в «искусственных» условиях тестирования. Все особенности программы и все лайфхаки знают только незрячие люди, поэтому если планируется сделать по-настоящему доступный сервис, обойтись без них невозможно.
«Когда впервые видишь, как незрячие люди воспринимают сервисы, это сразу перезагружает восприятие. Например, специально для нас при тестировании сервиса в Сбере незрячий тестировщик снизил скорость воспроизведения скринридера до 1,4, чтобы мы начали хоть что-то понимать. Обычно он использует скорость 2,8 и при этом понимает текст на слух».

Евгений Кузнецов,
дизайнер-лид компании Сбер
Ручное тестирование полезно проводить на этапе, когда большинство функций уже работает, но есть возможность многое скорректировать.
Момент для тестирования важно не пропустить. Почти готовый продукт, который окажется недоступным, будет сложно и дорого переделывать. Но и тестировать слишком рано не имеет смысла: основные функции уже должны быть реализованы в коде.

Момент для тестирования важно не пропустить. Почти готовый продукт, который окажется недоступным, будет сложно и дорого переделывать. Но и тестировать слишком рано не имеет смысла: основные функции уже должны быть реализованы в коде.
При этом следует помнить, что онлайн-сервисы предполагают постоянные изменения. Поэтому тестирование доступности должно проводиться регулярно. В этом смысле процесс тестирования доступности ничем не отличается от других видов тестирования: для него можно как привлекать сторонние агентства, которые проводят аудит, так и нанять in-house тестировщика (то есть тестировать сервис силами сотрудника организации).
«Каждый раз, когда вы разрабатываете новую функцию, желательно тестировать ее на доступность. Есть такой инженерный термин — непрерывная интеграция; если доступность станет частью такой непрерывной интеграции, вы всегда сможете тестировать функции продукта перед его релизом. И это будет замечательно».

Кристофер Патноу,
руководитель отдела доступности компании Google

5.2 УЧАСТНИКИ ТЕСТИРОВАНИЯ

Нарушения зрения бывают очень разными, поэтому рекомендуется пригласить:
  • полностью незрячего человека;
  • человека с остротой зрения ниже 30%;
  • людей с другими нарушениями зрения: слепым пятном, туннельным зрением и другими.
В зависимости от специфики продукта может потребоваться привлечь к тестированию глухих людей, людей с нарушением цветовосприятия (дальтонизмом) или людей с ментальными нарушениями. Также желательно пригласить людей с нарушениями моторики рук или без рук. В целом общение с людьми с индивидуальными особенностями и ограничениями поможет услышать разные мнения и лучше понять потребности разных групп пользователей.
Чтобы найти пользователей, можно обратиться:
  • в общества людей с инвалидностью: Всероссийское общество слепых (ВОС), Всероссийское общество глухих (ВОГ), Всероссийское общество инвалидов (ВОИ);
  • на специализированные форумы (например, «Доступная среда») и платформы по подбору персонала с инвалидностью (например, Everland);
  • к экспертам с инвалидностью.
Общаться с тестировщиками нужно уважительно, не акцентируя внимания на их особенностях. Если вы не знаете, как говорить об ограничениях человека (например, называть ли его «слепым» или «незрячим»), лучше всего спросить его самого.
«Универсальное решение — напрямую узнать у человека, что ему комфортно, нужна ли ему помощь и чем именно и как вы можете ему помочь».

Павел Попко,
тестировщик компании Сбер

5.3 ОСОБЕННОСТИ ТЕСТИРОВАНИЯ

В целом тестирование на доступность похоже на любое пользовательское тестирование. Однако есть несколько правил, которые актуальны для тестировщиков с ОВЗ, особенно если речь идет о незрячих пользователях.
1
Когда будете договариваться о времени и месте тестирования, рассказывать про маршрут, уточните, нужна ли будет человеку помощь, чтобы добраться до вашего офиса.
2
Лучше всего дать пользователю возможность тестировать продукт на своем устройстве, поскольку у него уже есть нужные настройки. Если нет возможности использовать устройство пользователя, то нужно попросить его применить привычные настройки.
3
Тестирование полезно наблюдать в процессе: можно сразу увидеть, с какими сложностями сталкивается пользователь, как складывается его путь, а в конце провести интервью.
4
При тестировании готового сервиса необходимо записывать все затруднения и вопросы, которые возникают у тестировщиков в процессе работы.

5.4 ВАЖНОСТЬ ОБРАТНОЙ СВЯЗИ

Нужно помнить о том, что обратная связь — комментарии в AppStore
и Google Play, отзывы — это ценный источник информации, особенно когда речь идет о пользователях с ОВЗ. Каждый пользователь становится в некоторой степени тестировщиком и часто готов поделиться информацией о том, с какими сложностями он столкнулся во время работы, что было хорошо, а что — плохо. Поэтому важно, чтобы разработчики и дизайнеры умели правильно принимать и интерпретировать эту обратную связь.
«Когда незрячий человек не может пользоваться в полной мере тем или иным приложением, он может написать: „У вас в приложении очень много неподписанных кнопок, подпишите, пожалуйста“. Если разработчик не начал заниматься доступностью и не знаком со скринридером, он не поймет, что речь идет о недостатках кода: код написан таким образом, что его не считывает скринридер».

Павел Попко,
тестировщик компании Сбер
Нужно понимать, что не всякий незрячий человек в открытой форме обратной связи может сказать: «Я незрячий пользователь». Разработчик должен правильно считывать, например, и такое сообщение: «Я пользуюсь вашим приложением с помощью программ экранного доступа». Оно означает, что обратную связь оставил человек, который не может пользоваться приложением иначе, а следовательно, ошибка касается доступности.