Тестирование

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

Для удобной приемки доработок на вебе подойдет Chromatic, особенно если у вас Storybook в качестве витрины. Назначайте ревьюеров, обсуждайте задачу и принимайте изменения:

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

Например, мы разрабатываем новый компонент в дизайн-систему — радиокнопки. Как будет выглядеть чек-лист:

Функциональность

• Базовое поведение, выбор одного варианта из группы
• Состояния: default, hover, focus, active, disabled, error
• Обработка событий: onChange, onClick
• Контролируемый/неконтролируемый режим

Визуальный дизайн

• Соответствие дизайн-системе: цвета, размеры, отступы, типографика
• Состояния: default, hover, focus, active, disabled, error
• Размеры компонента: small, medium, large
• Адаптивность и отображение на разных разрешениях

Доступность

• ARIA-атрибуты: role="radio», aria-checked, aria-labelledby, aria-describedby
• Группировка через fieldset/legend или aria-labelledby/aria-describedby
• Навигация с клавиатуры: tab, стрелки в группе, пробел для выбора
• Поддержка screen readers

Браузерная совместимость

• Последняя и предпоследняя версия Chrome
• Последняя и предпоследняя Safari
• Последняя и предпоследняя Opera
• Мобильные браузеры: iOS Safari, Chrome Mobile

Документация

• Дизайнерская документация готова к релизу
• Техническая документация готова к релизу

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

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

Ручной регресс рассматривать не будем — это дорогой, медленный и нудный процесс.

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

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