Bugs visuais que os seus testes automatizados deixam passar: como testar o que os usuários veem

O que são bugs visuais?

Os seus testes de ponta a ponta estão verdes.Então um cliente envia uma captura de tela da página de finalização da compra: o total do pedido está escondido atrás de um banner de promoção.Todos os testes automatizados foram aprovados, porque todos perguntaram ao código da página, e não à tela.Bugs visuais como este são aquilo para que serve o teste visual: ele verifica o que os seus usuários realmente veem.

await expect(
  page.getByTestId('order-total')
).toBeVisible();

Este artigo mostra de onde vem essa lacuna, quais bugs caem nela e como criar testes de ponta a ponta que veem a tela como os seus usuários a veem.

O que “visível” significa para o Playwright, o Cypress e o Selenium

Um teste de ponta a ponta em código encontra um elemento por um seletor e afirma algo sobre ele.A asserção mais próxima do que um usuário vive é “está visível?”.Cada ferramenta responde a isso do seu jeito, e nenhuma delas olha para a tela.

Playwright

O toBeVisible() do Playwright é aprovado quando o elemento tem uma caixa delimitadora não vazia e nenhum estilo visibility: hidden.A documentação dele acrescenta que um elemento com opacity: 0 conta como visível.Ele não pergunta se outro elemento cobre o elemento, nem qual é a cor do texto dele.

As ações são mais rigorosas que as asserções.Antes de um clique, o Playwright verifica se o elemento é o alvo atingido no ponto do clique, então um botão coberto faz o clique esperar até estourar o tempo limite.O Playwright também oferece toBeInViewport() para um elemento que precisa estar dentro da área visível, e toHaveText() lê o textContent do elemento por padrão.

Cypress

Desde o Cypress 16, a checagem de visibilidade padrão delega ao próprio Element.checkVisibility() do navegador.Um elemento conta como oculto quando não tem largura ou altura, tem display: none, visibility: hidden ou, no caso de uma asserção, opacity: 0.Antes de um clique, o Cypress verifica se o centro do elemento não está coberto.

Uma asserção é outra história.A documentação do Cypress diz isso com todas as letras: “O algoritmo moderno não faz teste de acerto, então informa o elemento coberto como visível.”

Selenium

O isDisplayed() do Selenium não é definido pela especificação W3C WebDriver, por causa da “impossibilidade de cobrir todas as condições possíveis”, como diz a documentação do Selenium.Em vez disso, o Selenium executa uma grande função JavaScript, que pondera o estilo do elemento, o seu tamanho e os ancestrais que o recortam.Ela não verifica se outro elemento é desenhado por cima dele, nem se o texto dele pode ser lido sobre o fundo.

Um clique em um elemento coberto falha com um erro “element click intercepted”.Um elemento que o teste apenas lê continua sendo informado como exibido.

9 bugs visuais que passam em uma asserção em código

Cada um destes bugs deixa o elemento no código da página, com um tamanho e o texto certo.Um teste em código que afirma que o elemento existe, está visível ou contém o seu texto é aprovado.O seu usuário vê outra coisa.

1. Um elemento coberto por outro

Um banner de cookies, um widget de chat, um cabeçalho fixo ou uma caixa de diálogo que nunca fechou fica por cima do elemento, muitas vezes depois de uma alteração de z-index.O elemento continua visível por todas as definições acima.Um clique nele é recusado, mas um teste que apenas o lê, como um preço, uma mensagem de erro ou uma confirmação, é aprovado enquanto ninguém consegue vê-lo.

2. Texto que ninguém consegue ler

Texto branco sobre fundo branco, cinza sobre cinza depois de uma mudança de tema, ou um rótulo deixado transparente por uma animação quebrada.Nenhuma checagem de visibilidade lê uma cor.O toBeVisible() do Playwright também aprova opacity: 0.

3. Texto cortado

Um rótulo longo demais para a sua caixa termina em reticências, ou uma altura fixa esconde a segunda linha.A página ainda contém todas as palavras, então uma asserção que lê o texto é aprovada.O seu usuário lê “Confirme o seu pe...”.

4. Um elemento empurrado para fora da vista

Uma tabela mais larga ou um título mais longo empurra o botão Comprar para fora da borda direita de uma tela estreita.O botão mantém o seu tamanho, então o toBeVisible() continua sendo aprovado.O teste só pega isso se também pedir toBeInViewport() para esse botão.

5. A imagem ou o ícone errado

Um produto mostra a foto de outro produto, uma fonte de ícones falha e deixa um quadrado vazio, ou uma atualização de sprite troca dois ícones.O elemento de imagem e a classe do ícone não mudam, então o código parece certo.

6. Um layout quebrado por uma alteração de CSS

Uma regra altera uma margem, a direção de um flex ou uma coluna de grid.Cartões se sobrepõem, uma coluna cai para baixo de outra, um formulário perde o alinhamento.Todos os elementos continuam no código, com o seu texto e o seu tamanho, então todas as asserções são aprovadas.

7. Um rótulo traduzido que não cabe

Palavras em alemão ou francês costumam ser mais longas que em inglês.Um rótulo transborda do seu botão, quebra para uma segunda linha ou empurra o botão seguinte para longe.A tradução está correta, então uma asserção textual é aprovada em todos os idiomas.

8. Uma fonte que não carregou

Quando uma fonte web não carrega, o navegador recorre a outra fonte: as linhas quebram de outro jeito, e os ícones desenhados com uma fonte viram caixas vazias.O texto no código é o mesmo, então nada falha.

9. Um indicador de carregamento que nunca para

Os dados chegam e as linhas são adicionadas à página, mas a camada de carregamento continua por cima.O teste encontra as suas linhas no código e é aprovado.O seu usuário espera na frente de um indicador de carregamento.

O teste de regressão visual com capturas de tela consegue pegá-los?

Sim, e é a resposta habitual.O teste de regressão visual compara uma imagem da tela com uma imagem de referência tirada antes.

O Playwright traz isso embutido com toHaveScreenshot().A documentação dele avisa que a renderização do navegador pode variar com o sistema operacional do host, a sua versão e configurações, o hardware e o modo sem janela (headless).Por isso, cada navegador e plataforma mantém a sua própria imagem de referência.

O Cypress tira capturas de tela, e a documentação dele diz que ele “não faz por si só a comparação de imagens”.Plugins ou serviços de teste visual acrescentam a comparação.

Serviços como o Percy e o Applitools Eyes acrescentam pontos de controle por imagem aos seus testes em código.O Percy captura e compara capturas de tela durante as execuções dos seus testes.O Applitools Eyes acrescenta uma chamada de asserção dentro de um teste.

Para ver essas ferramentas lado a lado, veja o estudo comparativo.

Por que o teste manual não fecha a lacuna

Uma pessoa vê cada um desses bugs num relance.É por isso que muitas equipes ainda clicam pelo aplicativo antes de uma versão.O teste manual tem os seus limites, porém.

Como criar testes de ponta a ponta que veem o que os usuários veem?

Seja qual for a ferramenta que você usa, seis princípios fazem um teste de ponta a ponta viver o seu aplicativo como um usuário.

1. 1

   Conduzir o aplicativo real

   Clique e digite como uma pessoa faz, na tela real.Um teste que não consegue pressionar um botão coberto falha onde o seu usuário falharia.

2. 2

   Verificar o que é mostrado

   Verifique a tela de três formas: a imagem, para que um elemento tenha a aparência certa; as palavras, para que ele diga a coisa certa; a disposição, para que tudo fique onde deve.

3. 3

   Encontrar o elemento primeiro, depois compará-lo

   Uma janela que se moveu ou uma página que rolou não é um bug.Um teste deve encontrar o elemento onde ele está agora, e depois julgar a aparência dele.

4. 4

   Ignorar o ruído, nunca uma mudança real

   As telas diferem levemente de uma máquina para outra, então a comparação deve ignorar o ruído de renderização e ainda assim pegar toda mudança que uma pessoa notaria.

5. 5

   Mostrar a evidência

   Uma falha deve mostrar a tela esperada ao lado da encontrada, com a mudança marcada, para que qualquer pessoa da equipe consiga lê-la.

6. 6

   Manter baixo o custo da mudança

   Quando o aplicativo muda de propósito, aceitar a nova aparência deve levar um clique, não uma reescrita.

Como o GUI Test Studio testa o que os usuários veem

O GUI Test Studio cria testes de ponta a ponta com base nesses princípios, sem código.Ele testa aplicativos web, aplicativos de desktop do Windows, celulares Android e jogos com um único tipo de teste.Leia mais sobre teste visual e teste de GUI com ele.

Gravar o fluxo uma vez

No GUI Test Runner-Recorder, clique em Gravar e faça o fluxo como sempre faz: ele grava o seu mouse, o seu teclado e a tela.Você também pode descrever o fluxo em um prompt para o Claude, o ChatGPT ou um modelo de IA local que fornecemos ou que você traz, que o grava para você.

Quando você encerra, ele pergunta o que o teste deve verificar.Com as respostas padrão, cada elemento em que você clica ou digita ganha uma asserção visual logo antes da sua ação.O que aparece sozinho, como um menu, uma caixa de diálogo ou uma mensagem, ganha uma asserção de grupo.

Asserções do que a tela mostra

Cada uma tem o seu guia: asserções visuais, asserções textuais e asserções de layout e de grupo.

Encontrar o elemento, depois compará-lo

Toda asserção visual é decidida em duas fases.A Fase de busca pergunta se o elemento está na tela e aguarda por ele até o tempo limite da asserção.O GTS Engine + AI encontra o elemento perguntando primeiro ao aplicativo, pelas informações de acessibilidade dele ou pelos próprios elementos da página, e pela visão quando o aplicativo não diz.Veja como o GUI Test Studio encontra cada elemento.

Quando o elemento é encontrado em outro lugar que não o da gravação, os cliques seguintes são direcionados para onde ele está agora.E um teste nunca clica às cegas através de um banner: quando o elemento está coberto, a asserção dele falha antes do clique.

Ler o que mudou

Depois de uma execução, o Relatório de confiança mostra cada asserção com a imagem esperada ao lado da imagem encontrada, a mudança destacada e o veredito em uma frase simples.

Ampliar

Com a Análise inteligente com IA ativada, uma asserção reprovada também recebe uma segunda olhada de uma IA, que diz em palavras simples o que mudou.Ela é executada com um modelo na nuvem e a sua própria chave, ou com um modelo de IA local no seu próprio computador: um que fornecemos, ou um que você traz.

Quando a mudança é de propósito, aceite a nova aparência a partir do relatório, e o teste passa a esperá-la.A linha de comando, o gtr-cli, executa os mesmos testes a partir de qualquer pipeline de CI/CD, a cada build.

Qual asserção pega qual bug visual

Os nove bugs de novo, com a asserção do GUI Test Studio que pega cada um.

Ampliar

Onde as asserções em código continuam tendo o seu lugar

Perguntas

Selenium, Playwright, Cypress, Percy e Applitools Eyes são marcas comerciais dos seus respectivos proprietários.