Testes de regressão visual – falsos negativos

Como evitar resultados falsos negativos quando se trata de testes de regressão visual

Este conteúdo é o terceiro e último de uma série de posts sobre testes de regressão visual com a ferramenta Applitools. Caso você não tenha assistido aos videos dos conteúdos anteriores, recomendo vê-los antes de ler este post. Seguem os links: teste de regressão visual – bug real e testes de regressão visual – falha esperada.

Agora que você já assitiu aos conteúdos anteriores, vamos ao último assunto da série: falsos negativos. Este post é baseado em um projeto real.

Sabe aquele jogo: encontre as 7 diferenças? Pois aqui vai um mais fácil: encontre as duas diferenças na imagem abaixo.

O teste acima falhou com um resultado falso negativo, ou seja, apesar de o teste ter falhado na verificação visual, não havia nada de errado com a aplicação. Você encontrou as duas diferenças? Pois aí vão. O ícone de status da lista de salas visitadas recentemente mudou de verde para cinza; e a informação de que uma pessoa estava na sala que era exibida deixou de ser mostrada, quando comparando a screenshot baseline com a screenshot corrente (current). A propósito, o ícone de status muda da cor cinza para verde quando tem ao menos uma pessoa na sala.

Porém, a informação de quantas pessoas estão na sala vem do back-end, e no momento da screenshot corrente tal informação ainda não havia sido devolvida pelo servidor, fazendo o teste falhar com um resultado falso negativo.

Agora veja como era o código de tal teste no momento da falha:

const testDescription = "login modal opened";
it(testDescription, () => {
    eyes.open(browser, "appear.in", testDescription, {800, 600});
    helper.click(appearInRoom.signUpButton);
    helper.click(signUpForm.logInButton);
    eyes.checkWindow(testDescription);
    eyes.close();
});

Perceba que logo após a execução das ações para abrir o modal de login (linhas 4 e 5), o método checkWindow (linha 6) do Applitools Eyes já é chamado, o qual bate a screenshot corrente e então compara com a baseline.

Porém, neste momento pode ser que o servidor ainda não tenha devolvido a informação da lista de atividades, fazendo a verificação visual falhar. Ao mesmo tempo, para tal elemento não podemos simplesmente utilizar o recurso do Applitools de ignorar uma região (ignore region), visto que ainda queremos comparar tais elementos visualmente.

Veja abaixo o mesmo teste, porém agora com uma linha a mais, previnindo que tal problema venha a ocorrer:

const testDescription = "login modal opened";
it(testDescription, () => {
    eyes.open(browser, "appear.in", testDescription, {800, 600});
    helper.waitForElementVisibility(roomActivity.statusText);
    helper.click(appearInRoom.signUpButton);
    helper.click(signUpForm.logInButton);
    eyes.checkWindow(testDescription);
    eyes.close();
});

Agora, antes mesmo de abrir o modal de login, aguardamos pela visibilidade do elemento statusText (lina 4), que é exatamente a informação do número de participantes na sala. Com isso, quando a verificação visual ocorrer o elemento dinâmico que também queremos comparar visualmente já está na tela, e o teste então provém um resultado confiável.

A conclusão é que podemos (e devemos) criar testes robustos, os quais provêm resultados reais ao time e nos quais podemos confiar quando estiverem falhando.

Por fim, sugiro a leitura do seguinte post, o qual escrevi em 2015, mas que continua atual, onde explico a difereça entre falsos negativos, falsos positivos, verdadeiros negativos e verdadeiros positivos.

Extra

Aos interessados em como integrar testes e2e escritos utlizando o framework Protractor com a ferramenta Applitools, segue o código exemplo da própria documentação do Applitools.

Espero que tenha gostado do conteúdo e bons testes!