Automatizar processos, testes e tarefas do dia a dia sempre tem alguma vantagem. Agiliza, elimina retrabalho, dá liberdade para trabalhar em atividades de inovação e criatividade.

Em projetos de desenvolvimento de software é comum que o time busque alternativas para otimizar o fluxo de trabalho, automatizando testes, builds, deploys dentre outras tarefas. Uma destas tarefas que devem ser otimizadas, são os retestes de defeitos de um fluxo.

Recentemente tive a oportunidade de participar de um projeto em que pude usar esta estratégia. Os testes rodavam em paralelo às correções do desenvolvimento, e enquanto eles atuavam nos ajustes, o time de testes trabalhou automatizando fluxos que estavam diferentes do esperado leia-se defeitos. Ou seja, automatizando os retestes.

Utilizar esta abordagem nos  trouxe algumas vantagens, dentre elas:

• Agilidade no processo de validação das correções
• Garantia de que aquele defeito está sendo monitorado. Caso volte a acontecer, o time será avisado de forma automática.
• Aprendizado com tecnologias para automação de testes com Java, Cucumber, Selenium e versionamento de código
• Início da cobertura de regras de negócio

 

Mas Samuel, e os Asserts?

Assert é o ponto de verificação do teste automatizado. É o que diz se ele passou ou não. Neste caso são defeitos, como digo se o teste passou se o fluxo não foi feito completamente?

Não tinha Asserts. Em um próximo projeto talvez seria interessante repensar esta estratégia, adicionando pontos de verificação errados mesmo. Porém, após a correção será necessário dar manutenção aos testes e a todos os Asserts errados. No nosso caso, o objetivo era dar início a Automação no projeto, e aproveitarmos ao máximo o tempo que tínhamos disponível para fazer isto. Não adicionamos Asserts, mas automatizamos todo o fluxo até o ponto em que o defeito ocorria. Ou seja, quando o defeito fosse corrigido, em alguns minutos teríamos um fluxo automatizado e com a verificação correta.

A “cereja” do bolo – Vinculando a cenários de negócio

Após concluirmos a Automação dos retestes de defeitos de maior prioridade, já estávamos com um número grande de testes automatizados. Então, resolvemos demonstrar o projeto e conversar com alguns colegas mais experientes para contar como foi e colher feedbacks. Dentre alguns pontos colocados, um destes foi:

• Dos defeitos automatizados, quais regras ou fluxos de negócio eles estão validando? Quais cenários de testes podem ser validados?

Chazan. Não tínhamos pensado nisso. Após​ a conversa a primeira coisa que fizemos foi o mapeamento de quantos cenários já estávamos com cobertura de 100% e quais cenários precisavam de algum complemento para que se tornasse agora um cenário automatizado com base no negócio, e não apenas no defeito.

À medida em que os defeitos foram corrigidos, passamos a complementar os retestes automatizados com as validações que faltavam, fazendo o vínculo com os cenários de testes mapeados para as regras de negócio do projeto. E como consequência, aumentamos a cobertura de testes automatizados do projeto. Para ser mais específico, o projeto iniciou com 0% e ao final ficou com 22,73%. **

Acredito que o principal aprendizado desta experiência não são as ferramentas, mas sim o foco em melhoria contínua. Esta foi uma abordagem que utilizamos em nosso contexto para aprender, otimizar, agilizar e aproveitar o tempo que tínhamos disponível. Espero que ajude quem deseja “começar” com a automação em seus projetos, tanto com a abordagem quanto com o mindset. 

– Samuel Lucas

**Cobertura baseada no total de cenários de testes mapeados para o projeto.