Design system живёт или умирает в зависимости от согласованности своего применения. Определить токены, компоненты и графический стандарт недостаточно — ещё нужно убедиться, что каждый экран в каждом продукте действительно соблюдает эти правила от релиза к релизу. Именно в этом роль визуального тестирования, применённого к design system: обнаруживать, что padding сполз, что вариант кнопки был продублирован локально вместо переиспользования, что фирменный цвет был заменён захардкоженным значением во время быстрой интеграции.
На этой странице собраны статьи, посвящённые пересечению design system и визуального тестирования: структурирование набора тестов по компонентам и страницам, управление baseline при эволюции токенов (смена палитры, типографическая переработка), сочетание проверки на уровне компонентов (Storybook + Chromatic, как правило) и валидации на уровне собранной страницы. Также рассматриваются организационные вопросы: кто валидирует визуальные диффы — команда дизайна, фронтенд-команда, QA? Как избежать того, чтобы визуальный долг тихо накапливался между двумя аудитами? Delta-QA сосредоточена на слое страниц, дополняя инструментарий уровня компонентов, и эти статьи стремятся дать комплексное видение, а не продвигать единственную цепочку инструментов.