Pontos-chave
- A arquitetura multi-tenant multiplica mecanicamente as superfícies visuais a testar: um código, N renderizações visualmente distintas
- Cada tenant pode ter o seu próprio branding (logótipo, cores, fontes, domínio), o que cria N versões visuais de uma mesma aplicação
- Um bug visual pode ser invisível no tenant por defeito e catastrófico num tenant com uma configuração específica
- Os testes visuais clássicos (baseados num único baseline) são estruturalmente inadequados para o multi-tenant
- O teste visual por tenant é a única abordagem que garante a qualidade visual para cada cliente, não apenas para o primeiro
O multi-tenancy designa, segundo a definição do NIST (National Institute of Standards and Technology, SP 800-145), «um modelo de arquitetura de software no qual uma única instância de uma aplicação serve múltiplas organizações clientes (tenants), cada uma dispondo de uma vista e configuração logicamente isoladas, partilhando a infraestrutura e a base de código subjacentes».
Se desenvolve um SaaS multi-tenant, conhece esta realidade: a sua codebase é única, mas cada cliente vê uma versão diferente da sua aplicação. O cliente A tem o seu logótipo azul sobre fundo branco, um domínio personalizado e uma fonte sans-serif. O cliente B tem o seu logótipo vermelho sobre fundo cinzento, um subdomínio e uma fonte com serifas. O cliente C desativou certos módulos, adicionou um footer personalizado e configurou uma paleta de cores completamente custom.
Mesmo código. Mesmos componentes. Mesmos templates. Mas renderizações visuais potencialmente muito diferentes.
E eis a pergunta que ninguém faz cedo o suficiente: quando faz deploy de uma atualização, quem verifica que se exibe corretamente em cada um dos seus clientes?
O multi-tenant multiplica as superfícies visuais
Para compreender a dimensão do problema, façamos um cálculo simples.
Tem uma aplicação SaaS com 20 páginas principais. Cada página existe em 3 breakpoints (mobile, tablet, desktop). São 60 combinações página-breakpoint.
Se tem apenas um tenant (uma única configuração visual), deve testar 60 renderizações visuais. Já é considerável, mas gerível.
Agora, acrescente a dimensão multi-tenant. Tem 50 clientes, cada um com a sua própria configuração visual. Teoricamente, deve testar 60 vezes 50, ou seja, 3.000 renderizações visuais.
Na prática, nem todos os tenants são visualmente distintos. Muitos utilizam a configuração por defeito. Mas mesmo que apenas 10 dos 50 tenants tenham uma configuração custom significativa, passa de 60 para 600 renderizações a verificar. Dez vezes mais.
E este cálculo não tem em conta as variações adicionais: dark mode por tenant, configurações de idioma, módulos ativados ou desativados, componentes personalizados. Cada dimensão adicional é um multiplicador.
O multi-tenant não duplica a sua superfície de teste visual. Multiplica-a.
As cinco dimensões da personalização visual por tenant
A personalização multi-tenant vai muito além da simples troca de logótipo. Eis as cinco dimensões que criam renderizações visualmente distintas.
O branding: logótipo, favicon, cores primárias
É a dimensão mais óbvia. Cada tenant tem o seu logótipo, que pode ser horizontal, vertical, quadrado, com ou sem tagline, a cores ou monocromático. O logótipo insere-se num header previsto para determinada dimensão. Um logótipo demasiado largo, demasiado alto ou com proporções inesperadas pode quebrar o layout do header, da navegação ou da página de login.
As cores primárias do tenant são aplicadas via variáveis CSS ou um sistema de temas. Mas um amarelo vivo sobre fundo branco não se comporta como um azul-marinho. Os contrastes mudam. Os textos sobre fundo colorido tornam-se potencialmente ilegíveis. Os estados interativos (hover, focus, active) que são variações da cor primária podem tornar-se indistinguíveis.
A tipografia
Alguns SaaS permitem aos tenants escolher a sua fonte de marca. É uma alavanca de personalização poderosa — e uma fonte considerável de bugs visuais.
Cada fonte tem as suas próprias métricas: altura de x, altura de ascendente, altura de descendente, largura média de caracteres. Substituir a fonte por defeito (otimizada para o seu layout) por uma fonte do cliente (otimizada para nada em particular) altera a altura das linhas, a largura dos blocos de texto, as quebras de linha, e potencialmente o layout inteiro de cada componente que contém texto.
Um heading previsto para caber numa única linha com Inter 24px pode passar para duas linhas com Georgia 24px, deslocando tudo o que está abaixo.
O domínio e o contexto de navegação
Cada tenant acede à aplicação via o seu próprio domínio (cliente-a.a-sua-app.com ou app.cliente-a.com) ou via um subcaminho (/cliente-a/dashboard). O domínio em si não afeta a renderização visual. Mas o certificado SSL, os headers de segurança e as regras CSP (Content Security Policy) específicas do domínio podem bloquear o carregamento de certos recursos (fontes, imagens, scripts) e criar renderizações degradadas.
Os módulos e funcionalidades ativados
Em multi-tenant, nem todos os clientes têm as mesmas funcionalidades. O cliente A tem o módulo analytics. O cliente B tem analytics e reporting. O cliente C não tem nenhum mas tem um módulo custom.
Cada combinação de módulos cria um layout potencialmente diferente: itens de navegação a mais ou a menos, secções de dashboard presentes ou ausentes, colunas de tabela visíveis ou ocultas. Cada combinação deve ser visualmente coerente.
O conteúdo e os dados específicos
O tenant não traz apenas o seu branding. Traz também os seus dados. Nomes de produto longos que quebram layouts de cartões. Imagens de perfil com proporções não standard. Descrições que ultrapassam os contentores previstos. Tabelas com 3 colunas no cliente A e 15 colunas no cliente B.
A personalização de conteúdo é a dimensão mais imprevisível porque não é controlada pelo seu código de tema. Depende do que os seus clientes colocam na sua aplicação.
Porquê a sua abordagem de teste atual é insuficiente
A maioria das equipas SaaS multi-tenant testam visualmente a sua aplicação de uma das seguintes formas. Nenhuma é suficiente.
A abordagem «tenant por defeito»
Testa unicamente com a configuração por defeito (o tema standard, sem personalização). É a abordagem mais comum e mais perigosa. Um bug que não aparece com a sua paleta de cores por defeito pode ser flagrante com a paleta de um cliente específico. Um layout que funciona com o seu logótipo horizontal pode quebrar com um logótipo quadrado.
Não está a testar a sua aplicação. Está a testar uma única versão da sua aplicação e a esperar que as outras funcionem também.
A abordagem «tenant de referência»
Testa com 2 ou 3 configurações de referência que representam os casos mais comuns. É melhor que o tenant por defeito, mas não cobre as configurações extremas — um logótipo excepcionalmente largo, uma cor primária com contraste limite, uma fonte com métricas invulgares. São contudo estas configurações extremas que geram os bugs visuais mais graves.
A abordagem «o cliente reporta o bug»
Espera que os seus clientes lhe assinalem os problemas visuais. É a pior abordagem possível, por três razões. Primeira: os seus clientes não reportam os bugs visuais menores, sofrem-nos em silêncio e perdem confiança no seu produto. Segunda: quando reportam um bug, o mal já está feito — o bug está em produção há dias ou semanas. Terceira: cada bug reportado por um cliente é um incidente de suporte que custa tempo, dinheiro e credibilidade.
A arquitetura do teste visual multi-tenant
O teste visual multi-tenant necessita de uma abordagem estruturalmente diferente do teste visual clássico. Eis os princípios fundamentais.
Um baseline por tenant
Em teste visual clássico, tem um baseline (uma captura de referência) por página e por breakpoint. Em multi-tenant, tem um baseline por página, por breakpoint e por configuração de tenant.
Isto parece uma explosão de baselines, mas na prática, os tenants agrupam-se em «perfis visuais». Um perfil agrupa os tenants que partilham as mesmas dimensões de personalização significativas. Se 30 dos seus 50 tenants utilizam a configuração por defeito, partilham o mesmo perfil e o mesmo baseline.
A ideia é identificar os eixos de variação visualmente significativos (cor primária, tipo de logótipo, fonte, módulos ativados) e criar um perfil para cada combinação única. Tipicamente, uma aplicação SaaS multi-tenant tem entre 5 e 15 perfis visuais distintos, independentemente do número de tenants.
A matriz de teste por perfil
Para cada perfil visual, define uma matriz de teste que cobre as páginas críticas nos breakpoints importantes. Esta matriz é o seu contrato de qualidade visual por perfil.
A matriz não precisa de cobrir todas as páginas para todos os perfis. Algumas páginas são insensíveis à personalização (uma página de avisos legais, por exemplo). Outras são altamente sensíveis (a página de login, o dashboard, os relatórios com marca). A matriz deve ser ponderada em função da sensibilidade de cada página à personalização.
A execução paralela
Com vários perfis visuais e várias páginas por perfil, a execução sequencial dos testes visuais não é viável. O teste visual multi-tenant deve ser concebido para a execução paralela: cada perfil é testado independentemente, em ambientes configurados com os parâmetros do tenant correspondente.
É onde uma ferramenta de teste visual no-code se torna valiosa. Configurar manualmente scripts de teste para cada perfil de tenant requer um esforço de desenvolvimento considerável. Uma ferramenta no-code permite configurar os perfis visualmente, definir as matrizes de teste por perfil e lançar a execução paralela sem escrever código.
Os bugs visuais específicos do multi-tenant
Certos bugs visuais são específicos da arquitetura multi-tenant. Não existem numa aplicação mono-tenant e não são cobertos pelas estratégias de teste clássicas.
O «tema que vaza»
Um tenant aplica a sua personalização via variáveis CSS ou um sistema de temas. Mas uma atualização do código introduz um componente que não utiliza as variáveis de tema — utiliza cores codificadas. No tenant por defeito, as cores codificadas coincidem com as variáveis de tema, logo o bug é invisível. Num tenant com uma paleta custom, o componente exibe-se nas cores por defeito no meio de uma interface com as cores do cliente. A inconsistência é flagrante.
O logótipo que quebra o layout
Um novo componente de header é desenvolvido e testado com o logótipo por defeito (digamos, um logótipo horizontal de 160x40 pixels). Em produção, o tenant A tem um logótipo quadrado de 100x100 pixels. O tenant B tem um logótipo horizontal de 300x60 pixels. O tenant C tem um logótipo vertical de 80x120 pixels.
O header que funcionava perfeitamente com o logótipo por defeito comporta-se de forma imprevisível com os logótipos dos clientes. O espaçamento da barra de navegação muda. O menu hamburger mobile fica deslocado. A altura do header varia, o que afeta o posicionamento do conteúdo principal.
A cor primária com contraste insuficiente
A sua aplicação utiliza a cor primária do tenant para botões, links, elementos de navegação ativos e badges. Com a sua cor por defeito (um azul com bom contraste), tudo é legível. Mas o tenant X escolheu um amarelo claro como cor primária. Os botões com texto branco sobre fundo amarelo claro são ilegíveis. Os links amarelos sobre fundo branco são praticamente invisíveis.
Este bug é um problema de acessibilidade tanto quanto de qualidade visual. E está diretamente ligado à personalização multi-tenant.
A fonte que redimensiona tudo
O tenant Y utiliza uma fonte custom cujos caracteres são em média 15% mais largos que a fonte por defeito. Cada texto ocupa mais espaço. Os botões tornam-se mais largos. Os menus necessitam de mais espaço. Os cartões do dashboard já não cabem em três colunas, passam a duas, o que quebra toda a maquetação do dashboard.
Este bug é insidioso porque cada componente individualmente parece correto — o texto é legível, o botão é funcional. É o conjunto da página que está visualmente degradado.
O módulo ausente que desloca tudo
O tenant Z não tem o módulo «analytics». Na navegação lateral, a entrada «Analytics» está ausente. Parece inofensivo, mas se a navegação utiliza um layout fixo com posições calculadas, a ausência de um elemento desloca todos os elementos seguintes. O ícone «Settings» encontra-se na posição habitualmente ocupada por «Analytics». O utilizador habituado à posição de «Settings» clica no sítio errado.
Não é um bug funcional (o link para Settings funciona). É um bug de experiência de utilizador que só existe para os tenants sem o módulo analytics.
A estratégia de teste visual multi-tenant pragmática
Face à multiplicação das superfícies visuais, a tentação é testar tudo. É irrealista. Eis uma estratégia pragmática em quatro níveis.
Nível 1: as páginas críticas nos perfis extremos
Identifique as suas 5 páginas mais sensíveis visualmente (página de login, dashboard, página de configurações, relatório imprimível, página pública com marca). Identifique os seus perfis visuais mais «extremos» — os que mais se afastam da configuração por defeito. Teste estas 5 páginas nestes perfis extremos.
É o seu mínimo vital. Se estas combinações passam, as combinações intermédias têm boas probabilidades de passar também.
Nível 2: todas as páginas no perfil por defeito
Teste o conjunto das suas páginas no perfil por defeito. É a sua rede de segurança para as regressões genéricas (não ligadas à personalização).
Nível 3: as páginas sensíveis em todos os perfis
Teste as suas páginas sensíveis (identificadas no nível 1) em todos os seus perfis visuais. Isto cobre as interações entre personalização e páginas críticas.
Nível 4: o teste exaustivo
Teste todas as páginas em todos os perfis. É o ideal, e é alcançável com uma ferramenta automatizada e uma execução paralela. Mas comece pelos níveis 1 a 3, e acrescente o nível 4 quando o seu processo estiver estabilizado.
O Delta-QA e o multi-tenant: a simplicidade onde importa
O Delta-QA está concebido para as equipas que precisam de testar visualmente sem complexidade técnica. Num contexto multi-tenant, isto significa poder configurar perfis visuais por tenant, definir matrizes de teste por perfil e obter relatórios por tenant — tudo sem escrever código.
O workflow é direto. Configura os seus perfis visuais (as combinações de personalização significativas). Define as páginas a testar por perfil. O Delta-QA captura os screenshots para cada combinação, compara com os baselines por tenant, e produz um relatório claro que identifica as regressões por cliente.
O resultado: sabe, antes de cada deploy, se a atualização quebra algo para um ou vários dos seus clientes. Não depois. Não quando o cliente liga. Antes.
O multi-tenant não é uma desculpa para não testar
O argumento que mais ouvimos é: «Temos demasiados tenants, não podemos testar tudo visualmente». É um argumento de capacidade, não de pertinência. Ninguém contesta que o teste visual multi-tenant é útil. A objeção é sobre a sua viabilidade.
E é exatamente por isso que a automatização é indispensável. Não pode testar visualmente 10 perfis de tenant em 20 páginas a 3 breakpoints manualmente. São 600 comparações visuais. Ninguém vai fazer isso.
Mas uma ferramenta automatizada fá-lo em minutos. Sem fadiga, sem subjetividade, sem esquecimentos.
O multi-tenant multiplica as superfícies visuais a testar. A automatização multiplica a sua capacidade para as testar. Uma compensa a outra. Desde que faça a escolha de automatizar.
FAQ
Como testar visualmente um SaaS multi-tenant sem rebentar o orçamento QA?
A chave é a estratégia por perfis visuais. Agrupe os seus tenants por configurações visuais semelhantes em vez de testar cada tenant individualmente. Comece pelos perfis extremos e as páginas críticas, depois alargue progressivamente. Uma ferramenta de teste visual automatizado torna este processo viável mesmo com dezenas de perfis.
É preciso um baseline de teste visual por tenant?
Sim, conceptualmente. Na prática, cria um baseline por perfil visual, não por tenant individual. Os tenants que partilham a mesma configuração visual partilham o mesmo baseline. Isto reduz consideravelmente o número de baselines a manter cobrindo a diversidade de renderizações.
Que tipos de bugs visuais são específicos do multi-tenant?
Os bugs mais específicos são: o «tema que vaza» (um componente que ignora as variáveis de tema do tenant), o logótipo que quebra o layout (proporções não previstas), as cores com contraste insuficiente (cor primária do cliente incompatível com o fundo), as fontes custom que redimensionam os layouts, e os módulos ausentes que deslocam a navegação.
O teste visual multi-tenant pode ser integrado num pipeline CI/CD?
Sim, e é recomendado. A abordagem consiste em executar os testes visuais para cada perfil de tenant em paralelo no seu pipeline, antes de cada deploy. O teste visual bloqueia o deploy se uma regressão é detetada num ou vários perfis. Isto garante que cada release está visualmente validada para todos os seus clientes.
Como gerir a personalização visual extrema de certos tenants?
Alguns tenants têm personalizações que vão além do simples branding (CSS custom, componentes específicos, layouts modificados). Para estes tenants, crie um perfil visual dedicado com um baseline específico. O sobrecusto é modesto (um perfil suplementar) comparado com o risco de entregar uma renderização partida a um cliente estratégico.
O teste visual deteta os problemas de contraste ligados às cores do tenant?
O teste visual por comparação deteta as alterações de renderização, incluindo alterações de contraste. Contudo, uma ferramenta de teste visual sozinha não calcula os rácios de contraste WCAG. A abordagem recomendada é combinar o teste visual (que deteta regressões) com uma auditoria de acessibilidade (que verifica a conformidade WCAG) para cada perfil de tenant.
Para aprofundar
- Checklist de Teste Visual Pré-Release: 15 Pontos a Verificar Antes de Cada Implantação
- Teste Visual e Conteúdo Dinâmico: Como Testar Quando Tudo Muda a Cada Carregamento
Gere um SaaS multi-tenant e quer garantir a qualidade visual para cada cliente?