Testing debt: como melhorar o processo de testes de software?
Por Sérgio Freire, Solution Architect & Testing Advocate @Xray
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.
O que é o testing debt?
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.
Testing debt acontece quando uma equipa escolhe, intencionalmente ou não, uma opção que garante benefícios no curto-prazo, mas que, no longo prazo, resulta em custos acrescidos no processo de testes em termos de tempo, esforço ou risco.
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.
Testing debt quadrants
Durante o workshop do Rob, mapeámos a debt utilizando a abordagem de Testing Debt Quadrants.
A abordagem de testing debt quadrants permite visualizar a “dívida”, incluindo:
- Elementos por testar
- Testes que são lentos ou inexequíveis e que podem levar a uma ausência de testes em determinadas partes
- Itens ou componentes que são complexas de testar
- Itens que não são fiáveis
Assim, dividimos o quadro em 4 secções:
- Impossível/impraticável
- Lento
- Complexo
- Não confiável
Nota: não devemos encarar os quadrantes como problemas, mas enquanto oportunidades.
O processo inicia adicionando post-its para identificar “partes da dívida” (por exemplo, alguma coisa que não estejamos a testar completamente ou da maneira que deveríamos).
Enquanto equipa, identificámos os mais relevantes (por exemplo, os que mais contribuem para o testing debt). Para cada parte da dívida, discutimos as estratégias e caminhos para podermos melhorar os testes de software, criando novos post-its. Como resultado, conseguimos delinear ações concretas para diminuir o debt e melhorar os testes de software globalmente.
Da teoria à prática: como fizemos?
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.
Da descoberta às ações
Tendo descoberto e discutido alguns dos itens que contribuem para o nosso testing debt, é fundamental identificar os itens prioritários e que possam ser colocados em prática.
Assim, decidimos criar um quadro no Trello para acompanhar e dar seguimento à implementação dos itens e partilharmos as nossas ideias sobre a sua evolução.
É interessante que da nossa discussão inicial enquanto esquematizávamos o nossos processo de desenvolvimento, incluindo a componente de testes, conseguimos imediatamente identificar potenciais oportunidades significativas de melhoria.
Assim, o quadro do Trello contém não apenas as ações que identificámos durante o exercício de Testing Debt Quadrants mas, também, do mapeamento visual inicial que fizemos sobre o nosso processo de desenvolvimento.
Coisas a ter em mente 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.
E agora?
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.
*Este artigo é uma versão PT do conteúdo original que pode ser lido aqui.
Leave a comment
Comments are closed.