Тёмная тема и визуальное тестирование: почему вам нужно вдвое больше тестов
Ключевые моменты
- Тёмная тема механически удваивает поверхность визуального тестирования, и большинство команд это игнорируют
- Визуальные регрессии, специфичные для тёмной темы (контраст, прозрачность, тени), ускользают от классических функциональных тестов
- Автоматизированное визуальное тестирование — единственный реалистичный подход для покрытия обеих тем без взрыва QA-бюджета
- Структурный подход, анализирующий вычисленные CSS-свойства, обнаруживает аномалии, которые попиксельное сравнение пропускает
Тёмная тема стала стандартом. Apple представила её в iOS 13 в 2019. Google последовал с Android 10 в том же году. Сегодня, согласно опросу Android Authority 2023, более 80% пользователей смартфонов включают тёмную тему. Ваши пользователи ожидают, что приложение будет работать одинаково хорошо в тёмном и светлом режимах.
И тут начинаются проблемы.
Тёмная тема — не инверсия цветов
Реализация тёмной темы — это не применение фильтра invert() к CSS. Хорошо спроектированная тёмная тема требует специфических дизайнерских решений. Цвета поверхностей меняются, но не равномерно. Тени работают иначе на тёмном фоне. Акцентные цвета должны быть скорректированы для поддержания достаточного контраста. Изображения, иллюстрации, иконки — всё нужно переосмыслить.
Пять визуальных кошмаров тёмной темы
Недостаточный контраст. Ваш тёмно-серый текст на белом фоне соответствует WCAG с коэффициентом 7:1. В тёмной теме на антрацитовом фоне он падает до 2,5:1. Текст становится нечитаемым, но ни один функциональный тест этого не обнаруживает.
Изображения с прозрачным фоном. Ваш PNG-логотип с прозрачным фоном отлично отображается на белом. В тёмной теме на чёрном фоне — исчезает.
Невидимые тени. Тени, создающие визуальную иерархию в светлой теме, становятся невидимыми на тёмном фоне.
Призрачные границы. Две соседние тёмные поверхности сливаются визуально. Не хватает границ, которые никто не подумал добавить.
Несогласованные интерактивные состояния. Hover, focus, disabled — каждое состояние должно работать в обоих режимах.
Почему ручных тестов недостаточно
При 50 экранах, 2 темах, 3 контрольных точках и нескольких состояниях — легко превышает тысячу визуальных проверок. Ни одна разумная QA-команда не может вручную проверить тысячу комбинаций каждый спринт.
Автоматизированное визуальное тестирование: единственный реалистичный ответ
Автоматизированное визуальное тестирование решает это, систематически проверяя каждый экран в обоих режимах при каждом изменении.
Структурный подход — тот, который использует Delta-QA — не сравнивает пиксели. Он анализирует вычисленные CSS-свойства каждого элемента. Для тёмной темы это принципиально: вместо вопроса «идентичны ли эти два изображения?» задаёт правильные вопросы: «соответствует ли контраст этого текста WCAG?», «видим ли этот элемент на текущем фоне?»
Доступность: угол, который все забывают
Тёмная тема — не только эстетическое предпочтение. Для многих пользователей это функциональная необходимость. WCAG 2.1 не делает различий между светлым и тёмным режимами. С вступлением в силу European Accessibility Act в июне 2025 у европейских компаний есть юридическое обязательство.
Что Delta-QA даёт для тестирования тёмной темы
Delta-QA анализирует фактический рендеринг ваших страниц для обнаружения визуальных аномалий, специфичных для тёмной темы. Контраст автоматически проверяется по порогам WCAG. Элементы с цветом переднего плана, слишком близким к фону, помечаются. Проблемные изображения идентифицируются. Всё без единой строки тестового кода.
FAQ
Тёмная тема действительно требует вдвое больше визуальных тестов?
Да, и это арифметика. Каждый экран существует в двух версиях, каждая может ломаться независимо.
В чём разница между попиксельным и структурным тестированием для тёмной темы?
Попиксельное сравнивает скриншоты, не понимая причину изменения. Структурное анализирует вычисленные CSS-свойства и обнаруживает реальные проблемы — такие как недостаточный коэффициент контрастности.
С чего начать, если команда не тестирует тёмную тему визуально?
Начните с самых посещаемых экранов. Тестируйте компоненты дизайн-системы индивидуально. Затем интегрируйте в CI/CD.