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

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.

Rob Meaney

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

melhorar o processo de testes de software

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:

  1. Elementos por testar
  2. Testes que são lentos ou inexequíveis e que podem levar a uma ausência de testes em determinadas partes
  3. Itens ou componentes que são complexas de testar
  4. Itens que não são fiáveis

Assim, dividimos o quadro em 4 secções:

  1. Impossível/impraticável
  2. Lento
  3. Complexo
  4. 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.

Sérgio FreireTesting debt: como melhorar o processo de testes de software?

Read more in

XTech Community

Readers also checked out

Want to get amazing Big Data, Business Intelligence, Middleware
Mobile articles & news directly from our experts?
Subscribe to our blogs now.