Revise seus testes sempre!

Um breve relato de erros que cometemos ao escrever testes.

Um dos grandes fatores também é pela busca de profissionais com esse tipo de conhecimento ter aumentado, aliás virou quase que pré-requisito para boa parte das vagas na área, isso faz com que os profissionais busquem esse aperfeiçoamento.

Iremos abordar nesse artigo práticas que muitos não adotam na hora de escrever seus códigos de testes e iremos analisar friamente a importância de sempre olhar o que foi feito a todo momento.

Dito isso, este artigo tem o intuito de ajudar os profissionais a olhar suas automações com mais detalhes, e que fique claro que, automatizar vai muito além de ver seus cenários sendo executados com sucesso.

Vale ressaltar que não estamos apontando críticas e tão pouco o que for dito será a melhor maneira de atuar, lembrando que cada caso é um caso, a ideia desse post é compartilhar conhecimentos e gerar embates sadios, mas temos certeza que muitos de vocês vão se familiarizar com o que queremos passar e espero que isso ajude muitos de vocês.

Imagine o seguinte cenário, que já aconteceu comigo alguns anos atrás quando comecei a automatizar.

Atuando em um time que entregava n features a cada sprint, olhando para sua suite de testes é possível ver que os testes contemplavam bugs e débitos técnicos daquela sprint, sendo apenas necessário incluir os testes automatizados de novas features caso necessário.

No cenário descrito acima tudo rodava perfeitamente e a cada implementação tínhamos um feedback rápido (local) dos testes automatizados e da aplicação, consequentemente a esteira até produção andava bem o que trazia certa confiança ao time.

Algum tempo depois pudemos notar um crescimento de bugs e inconsistências, onde a análise e correções começaram a ficar cada vez mais difíceis.

Crescimento de bugs reportados

Neste momento foi necessário fazer um rastreamento dos pontos falhos da automação e em paralelo da aplicação e seu ecossistema e chegamos a uma conclusão, viciamos a nossa automação!

O que isso quer dizer?

• Automação também tem bug e não podemos confiar somente nela.
• Automação precisa ser revisitada inúmeras vezes e não deve ser responsabilidade de apenas uma pessoa, era o que mais acontecia, pois gerou vícios, por exemplo: erros aleatórios na execução (flaky tests), validações que não fazia mais sentido e tempo de respostas da aplicação.
• Precisava ser refatorada assim como qualquer outro código de desenvolvimento. Não é porque está sendo executada com sucesso que não precisa passar por isso.
• E precisa ter estratégia de testes englobada quanto existir novas demandas. Não faz sentindo automatizar tudo numa camada apenas e pensar que esta tudo sendo coberto e validado.

Esses foram alguns dos problemas que trouxerem erros ao longo da automação e consequentemente para produção.

Não iremos questionar design patterns, performance, conceitos de testes e afins, ainda mais pelo fato de muitos automatizadores (assim como eu) não terem trabalhado com desenvolvimento de software, iremos apenas fixar pequenas ações que ajudaram muito.

O que mudamos?

• Não sair automatizando tudo, é preciso analisar o contexto do desenvolvimento, e em conjunto com o time encontrar a melhor cobertura de testes a ser aplicada, alinhar as expectativas de onde cada teste deve ser inserido corretamente.
• Suas automações precisam passar por code review, por mais que elas façam o que é esperado, isso ajuda todo o time a ter engajamento dos testes, e vice-versa, olhando para os PRs dos Devs do time, além de ajudar em nosso desenvolvimento pessoal.
• Opte por testes em camadas mais baixas da pirâmide, por exemplo: testes de componentes e contrato são testes rápidos. Foque apenas em testes que geram valor de negócio no topo da pirâmide, neste caso utilizando: testes de e2e ou testes integrados, isso ajuda a diminuir a suite de testes no topo da pirâmide, em sua manutenções de código criado e garante melhor clareza do que propõe o teste.
• Monitoração dos testes, ajudou bastante para termos noção da degradação do sistema.
• Inclusão dos testes em uma pipeline de execução diária, sinalizou problemas mais rápido.
• Incluímos na esteira de desenvolvimento os testes que antes eram feitos apenas por uma pessoa.

Tudo isso mostra o quanto é importante um olhar para todo o fluxo de desenvolvimento, ter essa sensibilidade junto ao time é essencial, isso sim faz com que sejamos inseridos no time desde o inicio da esteira, caso contrário sempre será mais do mesmo, ou seja, um testador/automatizador que atua no topo da pirâmide, por favor tentem evitar de ser esse tipo de profissional.

Vale enfatizar que em alguns lugares esse engajamento será doloroso, será preciso evangelizar o time, e talvez o mais difícil disso tudo, mostrar a importância que essas ações irão trazer para qualidade do produto, quando isso for atingido vai ser evidente a qualidade e que é de responsabilidade de todos.

Considerações finais

Entenda do produto que atua, seu ecossistema como um todo, participe de reuniões técnicas e sempre questione (isso irá reforçar o quanto estamos preocupados com os pequenos detalhes) e essa é a melhor maneira de aprender sobre o produto.
Depois que tiver essa maturidade será fácil entender o que é preciso fazer no contexto que estiver. E aquele antigo teste que existia, revive e se não fizer mais sentido, remova!

Obrigado

Dica de leitura

Onde começa a qualidade!? — artigo do Hugo Pereira que explana muito bem um pouco do potencial que todos podem atingir.