Ao integrar o framework de testes e o sistema de rastreamento de bugs, torna-se possível desativar casos de teste para os bugs conhecidos e reativá-los quando o bug é resolvido. Aneta Petkova, líder do grupo de Garantia de Qualidade na SumUp, apresentou a palestra The Framework That Knows Its Bugs (O Framework que conhece seus próprios bugs) no TestCon Moscou, 2019.
Petkova começou explicando o que costuma acontecer quando um caso de teste falha: "Engenheiros são inteligentes, então sempre procuram a solução mais simples: desativar o teste, comentando-o". Mas cada atalho desses é cobrado no futuro; tendemos a esquecer esses testes quando a tempestade passa, e "ficamos expostos aos mesmos problemas novamente, sem controle".
A equipe dela queria automatizar a desativação de testes para bugs conhecidos e garantir que testes fossem reativados quando o bug fosse resolvido. Decidiram integrar o framework de testes e o sistema de acompanhamento de bugs para possibilitar o rastreamento dos casos de teste afetados por um defeito.
Quando começou a trabalhar com essa ideia, o foco de Petkova era inteiramente no framework de testes; ela via o Jira como um repositório fechado, que não podia mudar. Ela usava tags para atribuir identificadores de problemas a todos os testes afetados no código, mas isso significava vários commits e a reconstrução do framework para cada novo defeito.
Depois de apresentar a ideia na SeleniumConf em 2017, Petkova obteve feedbacks que a ajudaram a repensar todo o processo. "Percebi que não estava utilizando bem o Jira". Decidiu então adicionar campos personalizados ao projeto e listar os identificadores de todos os testes afetados.
O processo em si consiste em três etapas e requer muito pouca codificação, explicou. A primeira pode ser feita no Jira, criando-se um filtro para retornar os defeitos que contenham identificadores dos testes e que estejam atualmente ativos, além de terem prioridade baixa o suficiente para permitir inclusão no próximo build. Em seguida, o framework recebe essa lista de defeitos e os testes associados por meio da API REST do Jira, e por fim esses testes podem ser desabilitados usando o executor de testes de funcionalidades adotado, no caso deles o TestNG.
Petkova esclareceu que apenas testes relacionados a erros de baixa prioridade são desabilitados. "Qualquer coisa que seja crítica deve resultar em falhas de testes, então não há como liberar um build contendo problemas sérios". Concluiu que essa abordagem pode ignorar automaticamente problemas menores, mas ainda assim está segura que os estão acompanhando no longo prazo.
O InfoQ falou com Aneta Petkova depois de sua palestra no TestCon.
InfoQ: Você mencionou que a verificação dos resultados de testes automatizados pode levar algum tempo. Pode falar mais sobre isso?
Aneta Petkova: Quando os testes são de alto nível, especialmente de UI de ponta a ponta, pode haver vários motivos para uma falha: de infraestrutura até problemas de rede rede, através de diferentes camadas de aplicativos, e até mesmo no próprio código de teste. Pode ser necessária uma investigação real para chegar à causa raiz, não apenas à manifestação de um problema.
InfoQ: Como você acompanha os testes que estão falhando devido a erros conhecidos?
Petkova: Personalizei o relatório gerado pelo TestNG para que inclua uma lista de todos os casos de teste impactados no momento e os respectivos problemas. Além disso, criei um quadro no Jira, contendo todos os problemas com impacto nos testes de automação. A equipe presta atenção especial a este quadro durante as reuniões de planejamento. Se um defeito permanecer sem dono por mais de um sprint, frequentemente aumentamos sua prioridade, porque ao desabilitar os testes,é criada a possibilidade de outros defeitos passarem pela nossa suíte de testes de regressão. No entanto, eu diria que o acompanhamento é uma questão de processo e de cultura, e a solução técnica é apenas complementar aqui.
InfoQ: Quais são os benefícios de rastrear e gerenciar casos de teste relacionados a defeitos?
Petkova: Como nossa estrutura de testes coleta dados relacionados a defeitos todos os dias, podemos usá-los para fazer algumas análises estatísticas e gerar um alarme quando problemas permanecem sem solução por muito tempo; ou quando os mesmos casos de teste apresentam bugs seguidamente, pois isso é um sintoma de uma funcionalidade muito problemática.
A integração nos fez prestar mais atenção à qualidade dos nossos casos de teste. Ao acompanhar o "tempo fora do ar" em cada cenário, descobrimos que alguns são muito abrangentes, cobrindo muitas partes diferentes do software; ou são muito frágeis e sensíveis a mudanças mínimas na interface com o usuário. Como esses exemplos mostram, a integração em si não vai resolver seus problemas, mas apoiará os esforços de aprendizado, adaptação e melhorias.
Algumas informações sobre Aneta Petkova e a palestra acima estão disponíveis no site do TestCon. Há também uma versão anterior da palestra em vídeo.