Визуальное тестирование multi-tenant: когда у каждого клиента свой рендеринг

Ключевые тезисы

Multi-tenant архитектура механически умножает визуальные поверхности для тестирования: одна кодовая база, N визуально различных рендерингов
Каждый тенант может иметь свой собственный брендинг (логотип, цвета, шрифты, домен), создавая N визуальных версий одного приложения
Визуальный баг может быть невидим на тенанте по умолчанию и катастрофичен на тенанте со специфичной конфигурацией
Классические визуальные тесты (основанные на единственном baseline) структурно непригодны для multi-tenant
Визуальное тестирование по тенантам — единственный подход, гарантирующий визуальное качество для каждого клиента, а не только для первого

Мульти-тенантность, согласно определению NIST (National Institute of Standards and Technology, SP 800-145), — это «модель архитектуры программного обеспечения, в которой единственный экземпляр приложения обслуживает несколько клиентских организаций (тенантов), каждая из которых имеет логически изолированное представление и конфигурацию, разделяя при этом базовую инфраструктуру и кодовую базу».

Если Вы разрабатываете multi-tenant SaaS, Вы знаете эту реальность: ваша кодовая база уникальна, но каждый клиент видит другую версию вашего приложения. Клиент A имеет свой синий логотип на белом фоне, кастомный домен и шрифт без засечек. Клиент B имеет свой красный логотип на сером фоне, поддомен и шрифт с засечками. Клиент C отключил определённые модули, добавил кастомный footer и настроил полностью кастомную цветовую палитру.

Тот же код. Те же компоненты. Те же шаблоны. Но потенциально очень разные визуальные рендеринги.

И вот вопрос, который никто не задаёт достаточно рано: когда Вы развёртываете обновление, кто проверяет, что оно корректно отображается для каждого из ваших клиентов?

Multi-tenancy умножает визуальные поверхности

Чтобы понять масштаб проблемы, сделаем простой расчёт.

У Вас есть SaaS-приложение с 20 главными страницами. Каждая страница существует на 3 breakpoints (mobile, tablet, desktop). Это 60 комбинаций страница-breakpoint.

Если у Вас только один тенант (одна визуальная конфигурация), нужно тестировать 60 визуальных рендерингов. Это уже существенно, но управляемо.

Теперь добавьте multi-tenant измерение. У Вас 50 клиентов, каждый со своей визуальной конфигурацией. Теоретически, нужно тестировать 60 умножить на 50, или 3 000 визуальных рендерингов.

На практике не все тенанты визуально различны. Многие используют конфигурацию по умолчанию. Но даже если только 10 из 50 тенантов имеют значительно кастомизированную конфигурацию, Вы переходите от 60 к 600 рендерингов для проверки. В десять раз больше.

И этот расчёт не учитывает дополнительных вариаций: тёмная тема по тенанту, языковые настройки, включённые или отключённые модули, кастомные компоненты. Каждое дополнительное измерение — это множитель.

Multi-tenancy не удваивает поверхность визуального тестирования. Она её умножает.

Пять измерений визуальной кастомизации по тенантам

Кастомизация тенанта идёт значительно дальше простой замены логотипа. Вот пять измерений, создающих визуально различные рендеринги.

Брендинг: логотип, favicon, основные цвета

Это самое очевидное измерение. У каждого тенанта есть свой логотип, который может быть горизонтальным, вертикальным, квадратным, со слоганом или без, цветным или монохромным. Логотип вписывается в header, спроектированный под определённый размер. Слишком широкий, слишком высокий или с неожиданными пропорциями логотип может сломать layout header, навигации или страницы входа.

Основные цвета тенанта применяются через CSS-переменные или систему тем. Но яркий жёлтый на белом фоне ведёт себя не как тёмно-синий. Контрасты меняются. Текст на цветных фонах становится потенциально нечитаемым. Интерактивные состояния (hover, focus, active), являющиеся вариациями основного цвета, могут стать неразличимыми.

Типографика

Некоторые SaaS-продукты позволяют тенантам выбирать шрифт своего бренда. Это мощный рычаг кастомизации — и значительный источник визуальных багов.

У каждого шрифта есть собственные метрики: x-height, высота подъёма, высота спуска, средняя ширина символа. Замена шрифта по умолчанию (оптимизированного для вашего layout) на шрифт клиента (не оптимизированного ни для чего конкретно) меняет высоту строк, ширину текстовых блоков, переносы строк и потенциально весь layout каждого компонента, содержащего текст.

Заголовок, спроектированный, чтобы помещаться на одной строке с Inter 24px, может перенестись на две строки с Georgia 24px, сдвигая всё, что находится ниже него.

Домен и контекст навигации

Каждый тенант обращается к приложению через свой собственный домен (client-a.your-app.com или app.client-a.com) или через подпуть (/client-a/dashboard). Сам домен не влияет на визуальный рендеринг. Но SSL-сертификат, security headers и правила CSP (Content Security Policy), специфичные для домена, могут блокировать загрузку определённых ресурсов (шрифтов, изображений, скриптов) и создавать деградированные рендеринги.

Включённые модули и функции

В multi-tenant не у всех клиентов одни и те же функции. Клиент A имеет модуль аналитики. Клиент B имеет аналитику и репортинг. Клиент C не имеет ни того, ни другого, но имеет кастомный модуль.

Каждая комбинация модулей создаёт потенциально другой layout: пункты навигации добавляются или удаляются, секции dashboard присутствуют или отсутствуют, столбцы таблиц видимы или скрыты. Каждая комбинация должна быть визуально согласована.

Контент и данные, специфичные для клиента

Тенант приносит не только свой брендинг. Он приносит свои данные. Длинные названия товаров, ломающие layouts карточек. Изображения профилей с нестандартными пропорциями. Описания, превышающие свои предполагаемые контейнеры. Таблицы с 3 столбцами для Клиента A и 15 столбцами для Клиента B.

Кастомизация контента — самое непредсказуемое измерение, потому что оно не контролируется кодом вашей темы. Оно зависит от того, что ваши клиенты помещают в ваше приложение.

Почему ваш текущий подход к тестированию недостаточен

Большинство multi-tenant SaaS-команд визуально тестируют своё приложение одним из следующих способов. Ни один не достаточен.

Подход «тенант по умолчанию»

Вы тестируете только с конфигурацией по умолчанию (стандартная тема, без кастомизации). Это самый частый и самый опасный подход. Баг, который не появляется с вашей цветовой палитрой по умолчанию, может быть кричащим с палитрой конкретного клиента. Layout, который работает с вашим горизонтальным логотипом, может сломаться с квадратным логотипом.

Вы тестируете не ваше приложение. Вы тестируете одну версию вашего приложения и надеетесь, что другие тоже работают.

Подход «эталонный тенант»

Вы тестируете с 2 или 3 эталонными конфигурациями, представляющими самые частые случаи. Это лучше, чем тенант по умолчанию, но это не покрывает экстремальные конфигурации — исключительно широкий логотип, основной цвет с пограничным контрастом, шрифт с необычными метриками. Однако именно эти экстремальные конфигурации генерируют самые серьёзные визуальные баги.

Подход «клиент сообщает о баге»

Вы ждёте, пока ваши клиенты сообщат о визуальных проблемах. Это худший возможный подход по трём причинам. Первая: ваши клиенты не сообщают о мелких визуальных багах — они молча терпят их и теряют доверие к вашему продукту. Вторая: когда они сообщают о баге, ущерб уже нанесён — баг находится в production дни или недели. Третья: каждый клиентский баг — это инцидент поддержки, стоящий времени, денег и репутации.

Архитектура визуального тестирования multi-tenant

Визуальное тестирование multi-tenant требует структурно иного подхода, чем классическое визуальное тестирование. Вот фундаментальные принципы.

Один baseline на тенант

В классическом визуальном тестировании у Вас один baseline (эталонный захват) на страницу и на breakpoint. В multi-tenant у Вас один baseline на страницу, на breakpoint и на конфигурацию тенанта.

Это кажется взрывом baselines, но на практике тенанты группируются в «визуальные профили». Профиль группирует тенантов, разделяющих те же значимые измерения кастомизации. Если 30 из 50 тенантов используют конфигурацию по умолчанию, они разделяют тот же профиль и тот же baseline.

Идея — идентифицировать визуально значимые оси вариации (основной цвет, тип логотипа, шрифт, включённые модули) и создать профиль для каждой уникальной комбинации. Обычно multi-tenant SaaS-приложение имеет от 5 до 15 различных визуальных профилей, независимо от количества тенантов.

Тестовая матрица на профиль

Для каждого визуального профиля Вы определяете тестовую матрицу, покрывающую критические страницы на важных breakpoints. Эта матрица — ваш контракт визуального качества по профилю.

Матрица не должна покрывать все страницы для всех профилей. Некоторые страницы нечувствительны к кастомизации (страница правовой информации, например). Другие очень чувствительны (страница входа, dashboard, фирменные отчёты). Матрица должна быть взвешена в зависимости от чувствительности каждой страницы к кастомизации.

Параллельное выполнение

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

Вот где no-code инструмент визуального тестирования становится бесценным. Ручная настройка тестовых скриптов для каждого тенант-профиля требует значительных усилий разработки. No-code инструмент позволяет визуально настраивать профили, определять тестовые матрицы по профилям и запускать параллельное выполнение без написания кода.

Визуальные баги, специфичные для multi-tenant

Определённые визуальные баги специфичны для multi-tenant архитектуры. Они не существуют в одно-тенантном приложении и не покрываются классическими стратегиями тестирования.

«Утекающая тема»

Тенант применяет свою кастомизацию через CSS-переменные или систему тем. Но обновление кода вводит компонент, не использующий переменные темы — он использует hard-coded цвета. На тенанте по умолчанию hard-coded цвета совпадают с переменными темы, поэтому баг невидим. На тенанте с кастомной палитрой компонент отображается в цветах по умолчанию посреди интерфейса, использующего цвета клиента. Несоответствие кричит.

Логотип, ломающий layout

Новый header-компонент разработан и протестирован с логотипом по умолчанию (скажем, горизонтальным логотипом 160x40 пикселей). В production у Тенанта A квадратный логотип 100x100 пикселей. У Тенанта B горизонтальный логотип 300x60 пикселей. У Тенанта C вертикальный логотип 80x120 пикселей.

Header, который идеально работал с логотипом по умолчанию, ведёт себя непредсказуемо с клиентскими логотипами. Отступы навигационной панели меняются. SPA-меню-гамбургер на мобильном смещается. Высота header варьируется, влияя на позиционирование основного контента.

Основной цвет с недостаточным контрастом

Ваше приложение использует основной цвет тенанта для кнопок, ссылок, активных элементов навигации и бейджей. С вашим цветом по умолчанию (синий с хорошим контрастом) всё читаемо. Но Тенант X выбрал светло-жёлтый как свой основной цвет. Кнопки с белым текстом на светло-жёлтом фоне нечитаемы. Жёлтые ссылки на белом фоне практически невидимы.

Этот баг — проблема доступности столько же, сколько проблема визуального качества. И он напрямую связан с multi-tenant кастомизацией.

Шрифт, изменяющий размер всего

Тенант Y использует кастомный шрифт, символы которого в среднем на 15% шире шрифта по умолчанию. Каждый текст занимает больше места. Кнопки становятся шире. Меню требуют больше пространства. Карточки dashboard больше не помещаются в три столбца — они переходят в два, ломая весь layout dashboard.

Этот баг коварен, потому что каждый компонент по отдельности выглядит корректно — текст читаем, кнопка функциональна. Это страница в целом визуально деградирована.

Отсутствующий модуль, сдвигающий всё

Тенант Z не имеет модуля «аналитика». В sidebar-навигации запись «Аналитика» отсутствует. Это кажется безобидным, но если навигация использует фиксированный layout с вычисленными позициями, отсутствующий элемент сдвигает все последующие элементы. Иконка «Настройки» оказывается в позиции, обычно занимаемой «Аналитикой». Пользователи, привыкшие к позиции Настроек, кликают не на тот элемент.

Это не функциональный баг (ссылка Настроек работает). Это баг пользовательского опыта, существующий только для тенантов без модуля аналитики.

Прагматичная стратегия визуального тестирования multi-tenant

Перед лицом умножения визуальных поверхностей искушение — тестировать всё. Это нереалистично. Вот прагматичная четырёхуровневая стратегия.

Уровень 1: Критические страницы на экстремальных профилях

Идентифицируйте 5 ваших самых визуально чувствительных страниц (страница входа, dashboard, страница настроек, печатный отчёт, публичная фирменная страница). Идентифицируйте ваши самые «экстремальные» визуальные профили — те, что наиболее расходятся с конфигурацией по умолчанию. Тестируйте эти 5 страниц на этих экстремальных профилях.

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

Уровень 2: Все страницы на профиле по умолчанию

Тестируйте все ваши страницы на профиле по умолчанию. Это ваша страховочная сеть для общих регрессий (не связанных с кастомизацией).

Уровень 3: Чувствительные страницы на всех профилях

Тестируйте ваши чувствительные страницы (идентифицированные на Уровне 1) на всех ваших визуальных профилях. Это покрывает взаимодействия между кастомизацией и критическими страницами.

Уровень 4: Исчерпывающее тестирование

Тестируйте все страницы на всех профилях. Это идеал, и он достижим с автоматизированным инструментом и параллельным выполнением. Но начинайте с Уровней 1–3 и добавляйте Уровень 4, как только ваш процесс стабилизируется.

Delta-QA и multi-tenant: простота там, где она важна

Delta-QA создан для команд, которым нужно тестировать визуально без технической сложности. В контексте multi-tenant это означает возможность настраивать визуальные профили по тенантам, определять тестовые матрицы по профилям и получать отчёты по тенантам — всё без написания кода.

Workflow прост. Вы настраиваете ваши визуальные профили (значимые комбинации кастомизации). Вы определяете страницы для тестирования по профилю. Delta-QA захватывает скриншоты для каждой комбинации, сравнивает с baselines по тенантам и производит ясный отчёт, идентифицирующий регрессии по клиенту.

Результат: Вы знаете, перед каждым развёртыванием, ломает ли обновление что-то для одного или нескольких ваших клиентов. Не после. Не когда клиент звонит. До.

Multi-tenancy — не оправдание, чтобы не тестировать

Аргумент, который мы слышим чаще всего: «У нас слишком много тенантов, мы не можем тестировать всё визуально». Это аргумент о ёмкости, а не о релевантности. Никто не оспаривает, что визуальное тестирование multi-tenant полезно. Возражение — о его осуществимости.

И именно поэтому автоматизация необходима. Вы не можете визуально тестировать 10 тенант-профилей на 20 страницах в 3 breakpoints вручную. Это 600 визуальных сравнений. Никто этого делать не будет.

Но автоматизированный инструмент делает это за минуты. Без усталости, без субъективности, без упущений.

Multi-tenancy умножает визуальные поверхности для тестирования. Автоматизация умножает вашу способность их тестировать. Одно компенсирует другое. При условии, что Вы делаете выбор автоматизировать.

FAQ

Как визуально тестировать multi-tenant SaaS, не взрывая QA-бюджет?

Ключ — стратегия визуальных профилей. Группируйте ваших тенантов по похожим визуальным конфигурациям, а не тестируйте каждого тенанта индивидуально. Начинайте с экстремальных профилей и критических страниц, затем расширяйтесь постепенно. Автоматизированный инструмент визуального тестирования делает этот процесс жизнеспособным даже с десятками профилей.

Нужен ли baseline визуального тестирования на каждого тенанта?

Да, концептуально. На практике Вы создаёте baseline на визуальный профиль, а не на индивидуального тенанта. Тенанты, разделяющие ту же визуальную конфигурацию, разделяют тот же baseline. Это значительно сокращает количество baselines для сопровождения, покрывая разнообразие рендерингов.

Какие типы визуальных багов специфичны для multi-tenant?

Самые специфичные баги: «утекающая тема» (компонент, игнорирующий переменные темы тенанта), логотип, ломающий layout (неожиданные пропорции), цвета с недостаточным контрастом (основной цвет клиента, несовместимый с фоном), кастомные шрифты, изменяющие размер layouts, и отсутствующие модули, сдвигающие навигацию.

Можно ли интегрировать визуальное тестирование multi-tenant в CI/CD-пайплайн?

Да, и это рекомендуется. Подход — запускать визуальные тесты для каждого тенант-профиля параллельно в вашем пайплайне, перед каждым развёртыванием. Визуальное тестирование блокирует развёртывание, если регрессия обнаружена на одном или нескольких профилях. Это гарантирует, что каждый релиз визуально валидирован для всех ваших клиентов.

Как обрабатывать экстремальную визуальную кастомизацию некоторых тенантов?

Некоторые тенанты имеют кастомизации, выходящие за пределы простого брендинга (кастомный CSS, специфичные компоненты, модифицированные layouts). Для этих тенантов создайте выделенный визуальный профиль со специфичным baseline. Дополнительная стоимость скромна (один профиль больше) по сравнению с риском поставки сломанного рендеринга стратегическому клиенту.

Обнаруживает ли визуальное тестирование проблемы контраста, связанные с цветами тенанта?

Визуальное тестирование путём сравнения обнаруживает изменения рендеринга, включая изменения контраста. Однако сам по себе инструмент визуального тестирования не вычисляет коэффициенты контраста WCAG. Рекомендуемый подход — комбинировать визуальное тестирование (которое обнаруживает регрессии) с аудитом доступности (который проверяет соответствие WCAG) для каждого тенант-профиля.

Для углубления

Управляете ли Вы multi-tenant SaaS и хотите гарантировать визуальное качество для каждого клиента?

Попробовать Delta-QA бесплатно →