Diffs de capturas de ecrã na prática: baselines, limiares e falsos alarmes

No papel, um teste visual é o tipo de teste mais simples do mundo: duas imagens, uma comparação, pronto. Quem experimenta percebe depressa que entre «comparar duas imagens» e «saber com fiabilidade se o site está estragado» está todo um ofício. Esse ofício tem três conceitos centrais — baseline, limiar, falso alarme — e quem os compreende compreende também porque é que os testes visuais são imprescindíveis nalgumas equipas e voltam a ser desligados noutras ao fim de três semanas.

No início está a baseline: um conjunto de capturas de ecrã que fixa o estado desejado da página. Importante é o que a baseline significa — e o que não significa. Não é uma medida objetiva de correção, mas um instantâneo que alguém declarou estado devido. Um diff contra a baseline nunca diz, por isso, «a página está estragada», mas apenas «a página está diferente do estado aprovado». Se diferente também quer dizer pior, isso nenhum algoritmo consegue decidir.

A comparação em si trabalha, no princípio de base, píxel a píxel: para cada posição da imagem é apurado o desvio de cor entre a baseline e a captura de ecrã atual, e a soma dos desvios dá uma medida da alteração. Este princípio de base é robusto e rápido — e tem uma fraqueza incorporada: trata todos os desvios por igual, quer tenha desaparecido um botão de carrinho de compras, quer um tipo de letra tenha sido suavizado de forma minimamente diferente.

É precisamente daí que vem o maior problema prático dos testes visuais: o ruído. A suavização dos tipos de letra sai diferente consoante o sistema e a série de renderização. As arestas são desenhadas ora um subpíxel mais cedo, ora mais tarde. As imagens passam por compressão, que gera desvios mínimos de cor. Nada disto é uma regressão — mas tudo isto gera diferenças de píxeis. Uma comparação ingénua, que dispara o alarme a cada píxel divergente, assinala por isso praticamente sempre alguma coisa.

A segunda fonte de ruído são os próprios conteúdos. Uma hora exibida muda a cada carregamento. Um carrossel nunca está duas vezes na mesma imagem. Os espaços publicitários entregam motivos variáveis, as barras de recomendações produtos variáveis, um aviso de cookies aparece ora antes, ora depois da captura de ecrã. Quem fotografa um site noticioso de manhã e ao meio-dia obtém duas imagens completamente diferentes — e ambas estão corretas.

A ferramenta contra o ruído chama-se limiar: só quando o desvio ultrapassa uma medida definida é que a comparação conta como anómala. Com isso começa uma ponderação que não se deixa otimizar até desaparecer. Um limiar severo assinala cada pequenez e gera fadiga de alarme; um limiar generoso deixa passar erros verdadeiros — uma indicação de preço deslocada pode ficar abaixo do limiar, se afetar apenas alguns píxeis. O valor certo, único, não existe; existe apenas o valor adequado a uma determinada página e a uma determinada equipa.

Para a sua definição há, ainda assim, um procedimento concreto: medir o ruído próprio. Para isso fotografa-se a mesma página duas vezes, imediatamente uma a seguir à outra, sem alterar o que quer que seja, e comparam-se as duas capturas entre si. Qualquer diferença que essa comparação assinale é, por definição, ruído — suavização de tipos de letra, compressão, temporização. Quem repete esta medição para as páginas e combinações de dispositivo mais importantes conhece o nível de base do seu próprio ambiente de verificação e pode fixar o limiar um pouco acima dele, em vez de o adivinhar. O procedimento fornece, já agora, um sinal de aviso precoce: se o nível de base assim medido subir depois de forma sensível, o ambiente ficou mais agitado — e vale a pena ir atrás da causa antes de os alarmes perderem a credibilidade.

A fadiga de alarme não é, nisto, um tema secundário e suave, mas o golpe mortal mais frequente para os testes visuais. Um sistema de verificação que dispara três vezes por dia sem motivo deixa de ser levado a sério por quem quer que seja ao fim de duas semanas — e então o alarme que assinala efetivamente uma página de pagamento estragada é apenas mais um entre muitos que se despacham com um clique de rotina. Um teste visual em que a equipa não confia é pior do que nenhum, porque finge uma segurança que não entrega.

Por isso vale a pena trabalhar nas condições de enquadramento antes de mexer no limiar. Deram bom resultado os dados de exemplo fixos em vez de dados em direto nos ambientes de verificação, as animações desativadas, os estados iniciais consistentes — por exemplo, um diálogo de cookies já respondido —, os tempos de espera suficientes até ao carregamento completo e tamanhos de janela idênticos em cada série. As indicações específicas de cada ferramenta pertencem a qualquer introdução; para o serviço aqui considerado, reúne-as a documentação do ScanU no site do fornecedor. Cada uma destas medidas retira uma fonte de ruído — e torna o limiar menos importante, porque os alarmes verdadeiros e os falsos se separam com mais nitidez.

Para as fontes de ruído persistentes — o espaço publicitário, a data em direto, a zona com comentários de utilizadores — algumas ferramentas oferecem ainda a possibilidade de excluir zonas da imagem da comparação. É eficaz, mas tem um preço que convém conhecer: uma zona excluída é um ponto cego. Precisamente aí pode passar a acontecer tudo e mais alguma coisa sem que ninguém o assinale. A ponderação não é, por isso, «excluir ou aguentar falsos alarmes», mas: esta zona é suficientemente importante para se querer saber das suas alterações? Para um banner publicitário rotativo, a resposta é quase sempre não; para uma coluna de preços, é sempre sim. As zonas de exceção definidas devem, além disso, ser documentadas e revistas de vez em quando — caso contrário acumulam-se manchas silenciosas, e a verificação cobre menos do que todos os envolvidos julgam.

Uma decisão aparentada diz respeito ao enquadramento da imagem. Uma captura da zona visível da janela verifica o que as visitantes e os visitantes veem sem deslizar — rápida e económica, mas cega para tudo o que está por baixo. Uma captura de todo o comprimento da página capta tudo, mas reage com mais sensibilidade: se um elemento na zona superior crescer vinte píxeis, todo o resto da página desloca-se para baixo, e a comparação assinala áreas que, em conteúdo, nem sequer mudaram. Para páginas compactas e estáveis, o comprimento total é quase sempre a escolha certa; em páginas muito longas e movimentadas pode ser mais inteligente verificar de forma dirigida as secções críticas. Também isto não é uma minudência técnica, mas uma decisão sobre que erros se quer ver — e quais se aceita conscientemente.

O segundo grande tema de metodologia é a manutenção da baseline ao longo do tempo. Os sites mudam de propósito: redesenhos, conteúdos novos, campanhas sazonais. Depois de cada alteração desejada, a baseline tem de ser acompanhada, caso contrário cada série futura assinala a mesma diferença esperada. O perigo está na rotina: quem entende as atualizações de baseline como um clique maçador acaba um dia por atualizar por reflexo — e declara assim, mais tarde ou mais cedo, um erro verdadeiro como novo estado devido. A partir daí, cada série verde confirma a versão estragada.

Contra isso ajuda um princípio simples: as atualizações de baseline são aprovações e merecem o mesmo cuidado que uma revisão de código. Alguém olha para a diferença, alguém decide conscientemente, alguém consegue reconstituir a decisão mais tarde. As ferramentas apoiam isto de maneiras diferentes; o ScanU, por exemplo, mostra a baseline e o estado atual lado a lado e gera relatórios partilháveis, de modo que também as pessoas não técnicas consigam julgar um desvio — que funções de comparação estão disponíveis em detalhe mostra-o a página de funcionalidades do serviço. O princípio é, porém, independente da ferramenta: a aprovação de uma baseline é uma decisão de conteúdo, não técnica.

Uma dimensão costuma ser omitida nos textos de introdução: o tempo. As regressões nem sempre se notam de imediato. Começa então a procura: desde quando é assim? Que alteração entra em causa? Aqui compensa o histórico — a possibilidade de consultar estados mais antigos e delimitar o momento da alteração. No ScanU, a conservação depende do nível de preço, de três dias no nível gratuito até 90 dias no maior. Para a metodologia isso significa: quem verifica raramente precisa de historiais que recuem mais no tempo; quem verifica diariamente delimita bem os períodos mesmo com um histórico curto.

Fica o limite mais fundamental do método: a lacuna semântica. Uma comparação de píxeis não sabe o que compara. Dois píxeis de deslocação num botão de pagamento podem ser sintoma de uma grelha de layout estragada; vinte píxeis de deslocação num rodapé são quase sempre irrelevantes. O diff não conhece a diferença — mede área, não significado. A última palavra tem por isso sempre uma pessoa que conhece a página e consegue enquadrar que desvio tem relevância para o negócio.

E, por fim, aquilo que um diff de capturas de ecrã não consegue, por princípio, ver: tudo o que não se traduz na imagem. Uma página pode ter um aspeto irrepreensível e mostrar, ainda assim, dados errados; um formulário pode estar perfeitamente renderizado e falhar no envio; um servidor pode servir corretamente conteúdos desatualizados. Os testes visuais são uma camada no conjunto dos testes — ao lado dos testes funcionais, da monitorização e da curiosidade humana ocasional —, não o seu substituto.

Como as peças se encaixam mostra-o um exemplo percorrido do princípio ao fim — não um estudo de caso, mas uma sequência típica. Semana um: uma equipa cria baselines para dez páginas e encontra na manhã seguinte dezenas de desvios assinalados. A revisão mostra que quase todos remontam a um carrossel e ao diálogo de cookies. Semana dois: acalmar o ambiente de verificação — dados de exemplo fixos, estado inicial definido, animações desligadas; as séries ficam silenciosas. Semana três: uma atualização de dependências desloca, num dos três motores, os espaçamentos da navegação — o primeiro achado verdadeiro, que antes ninguém teria notado, porque no dia a dia ninguém abre por rotina todos os motores. Semana quatro: um redesenho da página inicial gera diferenças esperadas em todas as vistas; depois da revisão, a baseline é atualizada conscientemente. Nada neste percurso é espetacular — e é precisamente aí que está o ponto. O valor não nasce de achados dramáticos, mas da passagem de «presumivelmente está tudo com bom aspeto» para um verificado «desde o último estado aprovado nada mudou contra a nossa vontade». Como decorre tecnicamente uma série de verificação individual mostra-o a apresentação passo a passo do ScanU.

Quem quer começar fica bem servido com uma ordem sóbria: primeiro definir um pequeno conjunto de páginas importantes, depois acalmar o ambiente de verificação, depois gerar as baselines e combinar na equipa quem julga e aprova os desvios — e só depois negociar limiares e frequência de verificação. Uma introdução ao tema em português é dada pela panorâmica do ScanU em português; a metodologia por detrás vale para qualquer ferramenta deste género. Porque essa é, no fim, a ideia central: o valor dos testes visuais não nasce no algoritmo que compara píxeis, mas no procedimento à volta — referências limpas, limiares honestos e pessoas que julgam as diferenças em vez de as despacharem com um clique.