Um caso de teste é uma única verificação, escrita para que alguém que não a redigiu a consiga executar e obter a mesma resposta. Nomeia um estado inicial, os passos a dar e o que deve acontecer. Se duas pessoas o executarem e discordarem sobre se passou, não está terminado.

É toda a ideia, e é a mesma ideia de um relatório de erro visto pelo outro lado. Um relatório de erro diz “é assim que se faz algo correr mal”. Um caso de teste diz “é assim que se verifica se corre bem”.

O que contém

Seis partes, e só três são as interessantes.

  • Um identificador para poder ser citado num relatório de build ou numa conversa
  • Um título que diga o que está a ser verificado, não onde se está a clicar
  • Precondições: o estado em que o mundo tem de estar para que o passo um faça sentido
  • Passos, numerados, cada um uma ação
  • Resultado esperado, específico o suficiente para poder estar errado
  • Resultado real, preenchido quando é executado

Os três que decidem se funciona são as precondições, o resultado esperado e o título. Os passos são fáceis. Saber que estado o teste pressupõe, e o que significa “correto” com a precisão necessária para se poder discutir, é o trabalho.

Escrever o título

Um título é lido dentro de uma lista de duzentos, por isso deve dizer o que está a ser verificado.

Fraco
Testar a página de início de sessão
Melhor
O início de sessão é recusado, com uma mensagem, quando a palavra-passe está errada

O segundo diz-lhe o que cobre, o que significaria uma falha e se duplica o de baixo. O primeiro não lhe diz nada, e daqui a seis meses ninguém saberá se cobre a mensagem de erro ou não.

Escrever os passos

Numere-os e ponha exatamente uma ação em cada um. O teste não é o sítio para poupar palavras.

Título:       O início de sessão é recusado, com uma mensagem, quando a palavra-passe
              está errada
Precondições: Existe uma conta confirmada para ada@example.com
Passos:
  1. Abrir /login
  2. Escrever ada@example.com no campo de email
  3. Escrever wrongpassword no campo de palavra-passe
  4. Clicar em Entrar
Esperado:     A página fica em /login, mostra "Email ou palavra-passe incorretos",
              e o campo de palavra-passe fica vazio

Repare no que o resultado esperado não diz: “aparece um erro”. Três implementações diferentes satisfazem essa frase e duas delas estão erradas. Também nomeia o que não deveria ter acontecido, ou seja, nenhuma navegação, porque um teste que só verifica a mensagem passa numa página que mostra a mensagem e mesmo assim inicia a sessão.

O que estraga um caso de teste

Depende do teste anterior. Um caso que só passa se o anterior tiver corrido primeiro não pode ser executado sozinho, não pode ser reordenado e cai em bloco quando algo se parte cedo. Cada caso monta as suas próprias precondições.

Verifica seis coisas. Quando falha, fica a saber que uma de seis coisas está errada. Divida-o.

Descreve a interface em vez do comportamento. “Clicar no botão azul em cima à direita” parte-se quando o botão muda de sítio; “Submeter o formulário” não.

O seu resultado esperado é um encolher de ombros. “Funciona corretamente”, “conforme desenhado”, “sem erros” - tudo isso significa que decide quem o executa, que é precisamente aquilo que um caso de teste existe para evitar.

Testa o que não pode falhar. Um caso que verifica se um cabeçalho estático diz as palavras certas custa tempo em cada execução, para sempre. Gaste o esforço onde vive o comportamento.

Casos manuais e casos automatizados

A mesma disciplina, uma economia diferente. Um caso automatizado corre em cada build e tem de ser preciso ou será instável; um caso manual é executado por uma pessoa que pode usar critério, o que é ao mesmo tempo a sua força e a razão pela qual duas pessoas tiram duas respostas de um caso vago.

Escreva casos manuais para o que precisa de critério - se este layout parece errado, se esta mensagem faz sentido - e automatize o que tem uma entrada conhecida e uma resposta conhecida. E mantenha os manuais mais curtos do que pensa: um caso de quinze passos é saltado a meio por qualquer pessoa que o execute pela nona vez.

Quando um falha

Um caso de teste falhado é o início de um relatório de erro, e parte à frente da maioria: os passos já estão escritos, o resultado esperado já está enunciado, e ambos estão numa linguagem sobre a qual alguém pode agir.

O que não leva é o contexto da máquina em que falhou - o navegador, a consola, os pedidos por trás da página. É a distância entre “o caso de teste 47 falhou” e um relatório com que um programador consegue trabalhar.

Session Replay

Extensão gratuita do Chrome. Um clique na página que se está a portar mal captura a captura de ecrã, a consola e o registo de rede, e devolve-lhe um link para colar no ticket.

Instalar a extensão

Anexe o identificador do caso ao relatório e os dois ficam ligados: quem o corrigir pode executar a mesma verificação, e quem executar a verificação na versão seguinte vê que uma vez falhou. O guia de relatórios de erro cobre o resto do que esse relatório precisa.

A versão curta

Uma verificação por caso. Precondições que ele próprio monta. Passos que outra pessoa consiga seguir. Um resultado esperado específico o suficiente para que duas pessoas não possam discordar sobre se aconteceu. Tudo o resto é formatação.