Как мы вывели тестирование доступности на новый уровень
На раннем этапе работы над специальными возможностями мы обычно разделяли тестирование на две категории: автоматизированное и ручное. Первый подход позволял быстро выявить очевидные проблемы, обнаруживаемые алгоритмами, а второй — всё остальное, что требовало больше времени и внимания. Автоматизированное тестирование хорошо вписывается в быстрые процессы, такие как непрерывная интеграция (CI), в то время как ручное тестирование требует тщательной координации с квалифицированными тестировщиками, чтобы охватить всё, что не могут сделать автоматизированные инструменты.
По ходу дела мы обнаружили, что на самом деле между этими двумя подходами есть золотая середина. В партнёрстве с Assistiv Labs мы объединили улучшенные процессы с комплексным тестированием сервисов, чтобы создать рабочий процесс, который переосмысливает понятия автоматизированного и ручного тестирования. Это нечто среднее, гибридный подход, который значительно увеличивает охват автоматизированного тестирования и снижает накладные расходы на ручную координацию.
Теперь мы выявляем очевидные и легко исправляемые проблемы за часы, а не недели. Наши новые процессы автоматически определяют, что является срочным, и отправляют проблемы соответствующим командам, которые обычно решают их в течение нескольких дней.
Результаты были как техническими, так и культурными. Мы намного быстрее предоставляем обратную связь по доступности, команды быстрее устраняют ошибки, а инженеры в Asana начали по-другому относиться к проблемам доступности.
Создание процессов для определения приоритета ошибок, связанных с доступностью
При масштабах Asana крайне важен надёжный фреймворк определения приоритетов, поддерживаемый процессами и принципами управления. Команды должны знать, что и когда нужно запланировать в своих бэклогах, а что требует внимания прямо сейчас.
Но легко недооценить, насколько сложно расставлять приоритеты для ошибок, связанных с доступностью. Приоритет основан на головокружительной матрице уникальных факторов, включая вспомогательные технологии, браузеры, затронутые группы пользователей, отзывы пользователей, область продукта, сложность исправления, обходные пути, соответствие WCAG и исторический контекст. Некоторые ошибки, возможно, существовали долгое время, но были обнаружены только недавно. Другие появляются с новыми функциями. А некоторые являются регрессиями — функциональностью, которая раньше была доступной, а теперь нет.
Чтобы создать фреймворк, мы формально определили различные типы ошибок доступности, чтобы разработать оптимизированные рабочие процессы для каждого из них. Важным шагом было определение того, что является регрессией, а что нет.
регрессия (сущ.)
Задокументированная (есть ли какие-либо записи о том, что это работало, например, предыдущие ошибки, цепочки комментариев, снимки экрана или записи экрана?), воспроизводимая (может ли коллега воспроизвести, выполнив описанные шаги?) проблема, которая раньше работала, а теперь нет.
Регрессии, естественно, могут получить высокий приоритет — последнее, чего хочет каждый, — это откат в области доступности. Во многих случаях это может значительно упростить расстановку приоритетов.
Однако есть подвох. Регрессии определяются по снимкам до и после. Например, снимком «до» может быть видео, на котором показано, что функция работает, а снимком «после» — видео, на котором показан новый проблемный результат. У багов, естественно, есть снимки «после». Но поиск моментального снимка «до» обычно требует тщательного анализа.
Без надёжного источника снимков «до» зачастую не стоило тратить время на выяснение, можно ли считать ошибку регрессией. Именно здесь новый вид автоматизации оказался чрезвычайно полезным.
Комплексная автоматизация тестирования доступности
Полностью автоматизированные тесты не являются чем-то новым ни для тестирования доступности, ни для Asana. Раньше axe DevTools и jsx-a11y для React обеспечивали нам широкий горизонтальный охват. Однако они неглубоки. Мы считали, что условная оценка в 30% для автоматизированных тестов по всей отрасли была довольно близка к критериям WCAG, которых мы достигали. Ограниченный охват означал, что ручное тестирование по-прежнему находило ошибки, которые пропустили автоматизированные инструменты.
Нам нужны были инструменты, которые могли бы работать глубже. Инструменты, более точно соответствующие нашим исследованиям среди пользователей и принципам управления. Именно это мы и нашли в Assistiv. Тесты для комплексного сервиса Assistiv пишутся с нуля инженерами Assistiv на основе потоков пользователей и параметров тестирования, которые мы предоставляем. Наборы включают быстрые клавиши, настоящие устройства чтения с экрана, браузеры и машинное зрение на базе облака Assistiv Labs. В результате получается нечто большее, чем просто симуляция: события передаются машине так же, как это делал бы человек-пользователь, что обеспечивает максимальный охват WCAG и более широких проблем доступности.
Комплексная автоматизация доступности радикально отличается от традиционной автоматизации, взаимодействуя с Asana для выполнения задач так же, как это делал бы тестировщик вручную. В зависимости от сценария тестирования можно охватить до 75% критериев WCAG. И за всем этим в режиме реального времени следят эксперты с критическим мышлением. Сотрудники Asana и Assistiv участвуют в разработке репрезентативных действий пользователей и анализе результатов, что значительно повышает планку автоматизированного тестирования с точки зрения объёма, частоты и точности.
Объединение усилий
Благодаря надёжному фреймворку определения приоритетов и новой автоматизации, которая перешла от поиска небольшого количества ошибок к поиску их большинства, мы внедрили мощный рабочий процесс определения приоритетов.
Во-первых, автоматизированные тесты синхронизируются с существующим инженерным конвейером Asana. Новые проблемы обнаруживаются практически в режиме реального времени и соотносятся с изменениями кода, которые, вероятно, их вызвали.
Затем инженер Assistiv проводит проверку, чтобы отфильтровать ложные срабатывания, и создаёт задачу в бэклоге Asana с контекстуализированным описанием влияния на пользователя и рекомендациями по исправлению. Поскольку автоматизированные тесты выполняются непрерывно, снимок предыдущего состояния всегда доступен, и регрессии можно легко классифицировать. Мы поддерживаем автоматизированные рабочие процессы Asana, которые направляют проблему нужной команде.
На практике это означает, что регрессии обычно отмечаются в течение 24 часов после развертывания и документируются таким образом, чтобы их могли легко понять инженеры, не имеющие опыта работы в области доступности. Это позволяет нашей команде по специальным возможностям установить SLA для устранения регрессий и предоставить это дело командам по продуктам. Никому не нужно обосновывать, какая регрессия является первой, второй или последней. Это просто ошибки, требующие внимания.
Эта децентрализация напрямую приводит к более устойчивой программе и более инклюзивному взаимодействию с конечным пользователем. У нас гораздо больше возможностей для действий и влияния, гораздо больше пространства для творчества, потому что нам не приходится постоянно решать возникающие проблемы. А это, в свою оч��редь, означает, что мы более удовлетворены и эффективны.
Рентабельность инвестиций в более быстрые циклы обратной связи
Исправление ошибки, которая остаётся незамеченной в течение нескольких недель или месяцев, обходится дорого. Кто-то должен направить его в соответствующую команду и убедиться, что ему присвоен нужный приоритет. Инженер, которому назначена эта задача, скорее всего, не тот, кто допустил ошибку. Даже если это тот же инженер, трудно восстановить забытый контекст, переключиться на другую задачу или скоординировать действия с другими командами, чтобы разобраться с техническим долгом, возникшим за прошедшие недели и месяцы.
Если выразить проблему в цифрах, то часто цитируемое исследование IBM показало, что обнаружение ошибок в рабочей среде обходится в 30 раз дороже, чем на этапе проектирования. Это звучит правдоподобно.
Когда инженеры развертывают обновление утром, любые признаки регрессий обычно начинают появляться до конца рабочего дня. Цикл обратной связи настолько короткий, что наши сквозные тесты неоднократно первыми предупреждали нас об общих ошибках пользовательского интерфейса, не ограничиваясь программами чтения с экрана или навигацией с помощью клавиатуры.
Когда инженеры начали получать более быструю обратную связь от сквозного тестирования, мы заметили снижение когнитивной нагрузки при определении приоритетов. Неопределённость исчезла. Инженеры думали: «Я несу за это ответственность, потому что выпустил это утром. Вчера это работало, а сегодня сломалось, мне нужно это исправить прямо сейчас». Исправление ошибок доступности становится чем-то вроде мышечной памяти.
В Asana ошибки доступности — это просто ошибки. И их исправляют.
Лучший способ автоматизировать доступность
До внедрения сквозного тестирования специальных возможностей наша команда по специальным возможностям добилась значительных успехов. Что касается операционной деятельности, то команды дизайнеров и инженеров имели задокументированные процессы проверки, определения регрессий и соглашения об уровне обслуживания. Когда дело доходило до тестирования, использовались автоматизированные решения для быстрых, но поверхностных отчётов и ручной контроль качества для тщательных, но трудоёмких проверок.
Благодаря комплексному подходу у нас есть техническое решение, которое дополняет существующие усилия и опирается на них. Регрессии документируются раньше, более детально и с большим количеством доказательств. Практически никто не тратит время на отчёты об ошибках, которые не подлежат исправлению или воспроизведению.
Теперь у нас есть чёткое представление о том, какие ошибки новые, а какие старые, на какие потоки пользователей они влияют и кто отвечает за их исправление. Мы можем действовать на опережение и сосредоточиться на нашем видении доступности Asana в будущем.
Об авторах: Кэмерон Кандифф (технический руководитель) и Цзясинь Чжэн (менеджер технической программы) являются участниками группы Development Lifecycle, занимающейся созданием инструментов, которые позволяют разработчикам быстро, надежно и с удовольствием воплощать идеи в жизнь.
