Sou desenvolvedor e líder técnico. Nunca atuei exclusivamente com QA. Porém, ao longo dos últimos anos, trabalhei em times multidisciplinares onde todos eram responsáveis pela qualidade das entregas. Adquiri bastante experiência com cenários de teste e pretendo compartilhar parte dela neste post.

A importância do roteiro

Obviamente, o roteiro é criado com a única finalidade de testar o resultado do desenvolvimento. Certo?

Não!

O primeiro objetivo de um roteiro de testes é garantir o entendimento da funcionalidade. Ao elaborar o roteiro, você é forçado a entender o que será implementado e a pensar em todas as possibilidades de utilização. Assim, você adquire uma visão global do que vem pela frente e consegue planejar o desenvolvimento, evitando retrabalhos e gaps.

Mais de uma vez, ouvi desenvolvedores dizendo: "Poxa… Me esqueci desse cenário. Isso muda tudo. Agora vou ter que reestruturar todo o código..." (Algumas vezes, estava ouvindo minha própria voz)

Mas e se os cenários de testes forem escritos por outra pessoa? Então, sugiro que você os entenda muito bem e se esforce por tentar complementá-los, com seu próprio entendimento. Parece perda de tempo, mas não é. Para complementar alguma coisa, você deve saber o que está faltando. Para saber o que está faltando, você deve descobrir o que já está lá. Assim, ao se empenhar em complementar o roteiro, você se força a compreendê-lo. Não importa que o complemento não seja anexado ao roteiro "oficial". Sua compreensão da funcionalidade terá sido ampliada e solidificada.

Testes automatizados

Há vários anos, testes automatizados são unanimidade em qualquer projeto. Contudo, por mais que eles sejam completos e testem todas as ramificações - e isso é mais comum em testes unitários, no backend - eles não exercem o papel de garantir o entendimento prévio da funcionalidade. Portanto, não eliminam a necessidade de um roteiro de testes.

Em situações específicas, desenvolvedores conseguem escrever roteiros na forma de testes automatizados, matando dois coelhos com uma cajadada só. De qualquer maneira, o importante é ter em mente a função de garantia de entendimento que um roteiro possui.

As 5 dicas

As seguintes dicas podem contribuir para a elaboração de roteiros completos e enxutos.

Dica #1: Uma ação, um resultado.

Respeite o formato do roteiro! Parece óbvio, mas, talvez, um roteiro que respeite o formato proposto seja a exceção, e não a regra.

Normalmente, os roteiros estão estruturados em listas de ações que provocam resultados, por isso, vou utilizar esse formato nos exemplos.

O seguinte caso de testes é uma aberração:

#	Ação	Resultado
1	Logar com um admin e com um cliente.	Eles deverão ser direcionados para a home logada.

E se apenas o login do admin falhar? Você vai dizer que seu teste passou "parcialmente"? Não… Escreva um caso para cada ação.

Outra aberração, maior do que a primeira:

#	Ação	Resultado
1	Efetuar login no sistema.	Se o usuário for admin, deverá acontecer isso. Se for cliente, deverá acontecer aquilo.

Novamente, e se apenas um dos resultados falhar? E quem garante que todos os cenários serão testados, uma vez que o formato leva a entender que apenas uma ação deve ser realizada?

Agrupar os casos não apenas dificulta o controle de sucesso e de erro, mas também oculta cenários e incentiva que os testes não sejam realizados por completo.

Portanto, escreva UMA ação que provoque UM resultado! Pode até ser que a ação seja composta por uma sequência de passos e o resultado seja uma lista de efeitos, mas não devem haver condições nas ações nem nos resultados.

Para o cenário em questão, testes adequados seriam:

#	Ação	Resultado
1	Efetuar login com um admin.	O usuário deverá ser direcionado para a home logada com os menus X e Y habilitados.
2	Efetuar login com um cliente.	O usuário deverá ser direcionado para a home logada com apenas o menu X habilitado.

Dica #2: Seja pessimista.

Não, não estou sugerindo que você se torne uma pessoa pessimista, mas que você tente pensar nas possibilidades de falha quando estiver elaborando o roteiro.

Um roteiro que apresenta apenas os cenários de sucesso, não é de muita valia. Pense nos casos de erro.

E não se atenha apenas às possibilidades mais óbvias. Você deve se fazer perguntas como:

• O que acontece se o usuário clicar duas vezes rapidamente neste botão? Hummm… Melhor exibir um loading!
• E se o serviço estiver fora do ar? Acho que vou exibir um feedback mais amigável.
• E se o cliente fizer isso antes daquilo?...

Muitas dessas perguntas podem estar relacionadas a detalhes de usabilidade pouco relevantes. Outras podem revelar pontos-cegos enormes que passaram despercebidos até então.

Se estiver desenvolvendo uma API de serviços, a lógica será a mesma:

• O que vai acontecer se o usuário informar esse dado inválido? Melhor adicionar um validator.
• E se informar um dado já cadastrado? Vou validar duplicatas.
• E se apenas metade das operações funcionarem? Melhor fazer isso em uma transaction.

E por aí vai.

As perguntas podem revelar cenários relevantes e estes deverão estar presentes no roteiro.

Algumas vezes, esse trabalho já terá sido feito em maior ou menor escala durante uma etapa de refinamento. Isso não deve impedir que o desenvolvedor repasse os cenários e tente complementá-los.

Tudo isso parece trabalhoso, mas seu prêmio será gratificante: funcionalidades sólidas, livres de bugs e sem remendos. Você se sentirá seguro em suas entregas, sabendo que você fez o seu melhor para garantir a qualidade.

Dica #3: Escreva, não codifique.

O código vem depois. No roteiro, utilize frases bem escritas e completas. Cenários confusos e mal redigidos podem até fazer sentido enquanto estão sendo escritos, porém, mais tarde, levam a testes malfeitos e incompletos.

Isso se agrava quando outra pessoa vai utilizar o seu roteiro. Ninguém é obrigado a decifrar seus pensamentos. Escreva os casos com clareza e mencione, sempre que necessário, o contexto e as circunstâncias do teste.

Nível de abstração

Utilize o nível de abstração adequado. Num roteiro de testes de APIs, um resultado aceitável seria: "Deverá retornar um erro 404." Já para o teste de uma tela, o mesmo resultado seria péssimo. Um bem melhor seria: "Deverá ser exibido um modal com a mensagem: 'Tente mais tarde'."

A qualidade dos testes está intimamente ligada à sua legibilidade.

Dica #4: Não exagere!

Após ler as dicas anteriores, você pode estar imaginando testes extensos, repetitivos e verbosos. Mas não é nada disso!

Os testes devem ser tão enxutos quanto possível, e devem se ater ao que importa.

Relevância

Notaram que, na dica anterior, um resultado aceitável seria: "Deverá retornar um erro 404."? Talvez a resposta do serviço também contenha uma mensagem, mas, se ela não for relevante, por que mencioná-la?

Da mesma forma, no outro exemplo, utilizei o resultado: "Deverá ser exibido um modal com a mensagem: 'Tente mais tarde'." Por que não mencionei outras características visuais do modal? Porque, provavelmente, o sistema já possui um modelo componentizado de modal, que funciona bem, e não estou interessado em testá-lo agora.

É uma questão de bom senso: Você deve identificar características relevantes no seu contexto e garantir que elas possuam testes específicos. As demais podem ser omitidas ou, talvez, agrupadas.

Agrupamento

Existe uma exceção à regra do “uma ação / um resultado”: Os casos podem ser agrupados quando se referirem a cenários bem conhecidos e mapeados, que provavelmente não foram afetados na implementação.

Para exemplificar: Suponha que a funcionalidade de paginação já tenha sido desenvolvida e testada e que você esteja construindo apenas mais uma tela de listagem. Entendo que o seguinte teste seria adequado:

#	Ação	Resultado
1	Testar a paginação.	Deverá estar funcionando corretamente.

Todos do time sabem como a paginação deve funcionar e saberão realizar os testes sem necessidade de mais instruções. Ao mesmo tempo, é pouco provável que o funcionamento da paginação tenha sido impactado. Portanto, o caso acima parece bem melhor do que:

#	Ação	Resultado
1	Passar para a próxima página.	Deverá passar para a página seguinte.
2	Passar para a página anterior.	Deverá passar para a página anterior.
3	E por aí vai…	...

Dica #5: Não comece tudo de novo!

Normalmente, o roteiro de testes é um fluxo contínuo. Um teste deve ser a sequência do outro. Não é necessário partir sempre da estaca zero.

Se, no passo anterior, você já realizou o login e está na tela em que precisa estar, não é necessário fazer isso novamente, exceto se algum cenário específico demandar. Isso deixa os roteiros mais enxutos e os testes mais rápidos.

Dica bônus: Revise. Atualize!

Após escrever este texto, o reli para garantir que a leitura estava fluida, que não havia erros e que eu não havia me esquecido de nada importante. Em menor proporção, você também deve fazer isso com seu roteiro. Após tê-lo escrito, releia-o com alguma dose de atenção para garantir que está tudo lá, de forma organizada.

Além disso, é bem comum aparecerem novas definições ou entendimentos ao longo do desenvolvimento. É importante que o roteiro seja atualizado com essas definições. Porém, as alterações devem ser pontuais e esporádicas. Se você se pega redefinindo seu roteiro a todo momento, pode haver algo de errado com a operação do seu time ou seu entendimento inicial estava muito raso.

Conclusão

Você deve ter notado que as dicas acima não compõem uma receita de bolo. São sugestões que devem ser aplicadas de acordo com a cultura e as circunstâncias de cada time e cada sistema.

Você também pode estar pensando que pôr em prática tudo isso é custoso e difícil, mas garanto que isso não é verdade. Em pouco tempo, começa a fazer parte da rotina e se torna automático. Já vi isso acontecer: Em poucas semanas, autores de roteiros incompletos e confusos passaram a escrever roteiros completos, objetivos e enxutos.

Enfim, quando o assunto é testes, muitos são os tópicos: Testes automatizados, TDD, testes unitários, end-to-end e por aí vai. Certamente tratarei de alguns deles em outros artigos.

Neste post, porém, apresentei algumas dicas de alto nível, úteis em vários contextos. Espero que possam contribuir para tornar as etapas de testes mais úteis e menos burocráticas, reduzindo o retrabalho e aumentando a qualidade das entregas.