Testing debt: como melhorar o processo de testes de software?

Por Sérgio Freire

Tive a sorte de poder ir ao Euro Testing Conference 2020, em Amsterdão, em fevereiro e aprendi imenso. Um dos workshops em que participei foi o de Rob Meaney sobre “Exploring Testability”, – completamente inspirador. Aproveitei os insights partilhados pelo Rob para fazer uma experiência com a minha equipa, com o objetivo de melhorar o nosso processo de testes.

Na conferência fizemos um exercício hands-on relacionado com o Testing debt. Testing o quê? Debt! Neste artigo vou explicar o conceito de testing debt, como torná-lo visível, abordá-lo e, assim, melhorar o processo de testes de software.

Todos nós já ouvimos falar sobre o conceito de technical debt – as decisões em desenvolvimento tomadas para alcançar mais benefícios no curto-prazo que acabam, no entanto, por colocar em causa esses mesmos ganhos no futuro. Por outras palavras, é como fazer um hack rápido para disponibilizar uma funcionalidade ao invés de escolher a arquitetura apropriada para esse efeito. A lógica do Testing debt é semelhante.

Já Peter Varhol, coloca a questão de uma forma diferente:

“É o esforço necessário para encontrar e resolver problemas que permanecem no código quando uma aplicação é lançada.”

Em poucas palavras, testing debt é sobre os testes de software que deveriam ter sido feitos antes, mas que por alguma razão não os fizeste.

Depois da conferência, decidi experimentar internamente este exercício para confirmar se tinha valor prático ou não. Ao mesmo tempo, a ideia era conseguirmos identificar alguns pain-points no nosso processo de testes de software.

Fizemos o exercício com um pequeno grupo de trabalho (eu, alguns testers, e o team lead) Apesar do meu papel ter sido essencialmente de facilitador, já que fui product owner do software em causa, também tive a oportunidade de contribuir com alguns inputs no processo.

Começámos por fazer uma retrospetiva ao nosso processo atual de testes, desenhando-o e esquematizando-o. Conseguimos ter uma perceção visual muito clara de quem estava a fazer o quê e quando, e ao mesmo tempo foi logo possível identificar algumas oportunidades para melhorar o processo de testes de software.

Eu vejo este tipo de diagramas como excelentes pontos de partida para a discussão. Ainda assim, é preciso ter alguma cautela, ou, de outra forma, podem surgir longas discussões.

A seguir passámos para a abordagem de Testing Debt Quadrants, escrevendo e adicionado post-its aos quatro quadrantes. Cada um de nós fez a sua reflexão e, no final, houve alguma sobreposição de ideias (diria que é normal isso acontecer).

O espaço e categoria em que adicionamos cada post-it no quadro é subjetivo, no entanto, conforme fomos fazendo as revisões, acabámos por fazer alterações com as quais estávamos todos de acordo. Repara que, por exemplo, alguns itens podem ser lentos e complexos ao mesmo tempo. A categoria em que colocamos os posts-its não tem propriamente uma base lógica científica. No fundo, a categorização é um princípio para uma discussão mais alargada.

Assim, conseguimos chegar a algumas conclusões sobre como resolver os problemas que identificámos. Agora é colocá-las em prática para melhorar o processo de testes de software.

Sempre que olhamos para o todo, é fácil perdermo-nos e começarmos a explorar diferentes tópicos, que nunca mais acabam.

Algumas recomendações para melhorar este processo:

• Define um limite de tempo para a análise e identificação de soluções, para que não se prolongue indefinidamente
• Mantém o foco (sem interrupções)
• Envolve outras áreas e pessoas
• Pensa em fazer melhorias graduais – um passo de cada vez (para evitar que tentes encontrar a solução perfeita)
• Revê o quadro regularmente

Para além destas boas práticas, também aconselho evitar “apontar o dedo” e atribuir culpas. Queremos identificar, melhorar e envolver; tudo exceto culpabilizar.

Deve ser um exercício de equipa, aberto, mas não individual.

Acredito que mapear os problemas no processo de testes – que, como vimos, são também oportunidades para melhorar globalmente o processo de testes de software – utilizando o Testing Debt Quadrants é um exercício simples e de grande valor.

Todas as conversas que tiveres com a tua equipa são importantes para terem uma visão conjunta sobre como abordar o processo de testes e melhorá-lo. Apenas garante que estas partilhas não se tornam pouco úteis, procurando torná-las em ações concretas que podem monitorar e rever em conjunto.