A decisão é tomada, “nós vamos resolver a dívida de teste”. Parece positivo, mas ao mesmo tempo nos perguntamos: “Por que acabamos naquele ponto?”.

A dívida de teste é um desperdício que as organizações devem prevenir e eliminar continuamente para manter sua velocidade e reatividade. Caso contrário, cada mudança vem com seu peso adicional, desacelerando a entrega geral do software.

Durante a mesa redonda “Esqueça a dívida de teste: construa riqueza de automação de teste” , compartilhamos a definição e os principais motivos para a dívida de teste antes de compartilharmos formas viáveis ​​de construir riqueza de automação de teste em primeiro lugar. Este primeiro artigo foca na dívida de teste, enquanto o próximo na criação de valor da automação de teste.

Agradeço a cada um dos participantes por sua participação e contribuição:

• Joel Oliveira, Teste de Software e Garantia de Qualidade Evangelista de, Palestrante, Treinador, Gerente de Programa Sênior, Consultor Independente
• Rafael Amaral, Engenheiro de Software Sênior em Teste na Farfetch
• Filipa Nogueira, Líder da Equipe de Engenharia em La Redoute

Em primeiro lugar, vamos começar explorando Test Debt com um exemplo concreto.

Afinal, o que é a dívida de teste?

Uma empresa julga muito lenta sua iteração de alterações de software. A automação de testes é identificada como prioridade para acelerar os ciclos. Uma estrutura é construída rapidamente para automatizar o teste manual existente e produzir vitórias antecipadas. Problemas começam a aparecer.

A precipitação fez com que um conjunto de testes automatizados não funcionasse bem: muitos testes são executados com lentidão e instabilidade, enquanto é difícil implementar alguns testes manuais. Além disso, a única pessoa que conhece o framework deixará a empresa em breve. Abre os testes para tentar ajudar mas eles são muito técnicos e difíceis de entender.

Esperava resultados muito melhores. Um conjunto de testes automatizados rápidos e fiáveis os mais valiosos para a equipe. Uma estrutura conhecida, que pode ser mantida por outras pessoas ou por um fornecedor. Um relatório integrado sobre objetivos e medidas compartilhados da equipe.

A dívida técnica é sobre: ​​Valor esperado do ativo – Valor real do sistema

A dívida técnica e a dívida teste compartilham as características comuns de ser uma lacuna entre o valor esperado e o valor real. A dívida do teste pode ser devido à falta de ações específicas ou ser o resultado de decisões particulares. É importante manter essas duas tipologias em mente, visto que, de forma contra-intuitiva, tanto a inação quanto a ação levam ao endividamento.

A presença de dívida de teste leva à próxima pergunta: por que chegamos lá?

Por que acabamos com a dívida de teste?

Podemos começar por olhar para fora do mundo do software e dos testes, especialmente em finanças, reutilizando nossa analogia. Por que tantas pessoas acabam em uma situação de dívida financeira? Motivos comuns são compartilhados com a dívida de teste.

Um primeiro ponto circula de volta aos dois elementos de medição da dívida de teste, “esperada” e “real”. A definição do valor esperado suponha que foi definido, compartilhado e acordado. Infelizmente, as expectativas de qualidade ainda não são reflexo de exercícios colaborativos, como o Shift-Up . O valor “real” reside em uma característica da dívida de teste: é difícil de medir.

“O complicado sobre a dívida técnica, claro, é que, ao contrário do dinheiro, é impossível medir-la com eficácia.”

Martin Fowler, martinflower.com

A dívida financeira é facilmente medida; deve uma determinada quantia de dinheiro a uma entidade. Para a dívida técnica e de teste, é mais complicado. Pode usar os atributos de qualidade de testes, modelos de dívida técnica e links para indicadores essenciais. Este é o primeiro passo. Sua tecnicidade e falta de alinhamento com os motivadores de negócios podem torná-los difíceis de serem entendidos por outras pessoas.

Um outro fator-chave reside em um cocktail de três fatores perigosos:

1. Foco no curto prazo
2. Falta de compreensão
3. Feedback loops atrasadas

Abordagens de curto-prazos têm o custo de acumular dívidas e efeitos colaterais no médio prazo. As partes interessadas podem empurrar nessa direção para cumprir objetivos específicos, mostrar seu poder ou simplesmente não estarem cientes dos impactos envolvidos, o segundo fator. Nosso trabalho em qualidade é expressar as consequências associadas a escolhas específicas. Não fazer isso resulta no terceiro fator, ciclos de feedback atrasados, que são difíceis de serem antecipados pelos humanos.

Podemos fazer uma analogia com uma situação comum no comportamento humano. Uma criança começa a comer alguns doces. Ele se sente bem, então ele come mais deles. Ninguém lhe falou sobre os impactos dos doces ao longo do tempo no corpo, mente, etc. As crianças não se importam como sendo jovens seu corpo se processa rapidamente, no curto prazo não há problema. Com o tempo, ele começa a ganhar vários quilos até atingir um estado crítico de obesidade e ter que passar por uma cirurgia.

É assim que esses três fatores combinados levam as organizações a bater em uma parede, até não serem mais capazes de entregar mudanças de software. Então, eles têm que implementar mudanças drásticas se ainda estão sobrevivendo no mercado. A dívida de teste não acontece durante a noite. É a soma das decisões tomadas e não tomadas por um conjunto de atores do ecossistema.

Identificamos uma prática essencial baseada na intuição e nos dados, os sinais de alerta.

Quais são os sinais de alerta da dívida de teste?

A dívida de teste é difícil de medir factualmente, mas podemos confiar na nossa capacidade humana de detectar, sentir e reagir aos sinais de alerta. Para a automação de teste, podemos sentir comportamentos organizacionais e atributos específicos de automação de teste.

Vamos voltar ao porquê de nossos testes automatizados. Um objetivo de nosso esforço de automação de testes é acelerar a entrega de mudanças de software com confiança. O valor de automação de teste desaparece quando a equipe começa a contornar a campanha de automação de teste, procurar rotas alternativas, pedir exceções. Vários motivos são possíveis, como um longo tempo de execução, instabilidade, falta de compreensão ou outros critérios de manutenção. 

O tempo de execução está diretamente ligado a indicadores essenciais de entrega de software: lead-time para mudanças, cycle-time e MTTA. Essas métricas fazem parte do relatório Accelerate, correlacionando o desempenho da organização com essas medidas. Precisamos restringir nosso tempo de execução de teste para limitar seu impacto sobre essas métricas de aceleração. Para a automação de teste, isso significa menos testes mais valiosos executados com mais rapidez. Também pode ser sobre desacoplar os testes a serem executados sob um determinado perímetro, em vez de executá-los todos cada vez com uma grande campanha de regressão de ponta a ponta.

O segundo fator de instabilidade do teste, também conhecido como flakiness, é medido com o flaky ratio. A instabilidade não está afetando apenas o teste. Isso afeta diretamente a confiança na entrega de software para sua equipe. Portanto, é essencial almejar esse percentual de 100%. Quando este não for o caso, entender e corrigir as causas raízes é uma prioridade. A instabilidade pode ser medida quando tem pelo menos um teste automatizado implementado, verificando sua estabilidade ao longo do tempo. Ao adicionar testes, também pode começar a medir a estabilidade geral do conjunto de testes. 

O último fator se concentra nos sinais de alerta de manutenção de automação de teste. A chave é agir logo no início em indicadores e comportamentos específicos. Avalie regularmente o impacto do teste automatizado perguntando “E daí?”. Tem como objetivo confirmar se os testes automatizados estão afetando os tópicos prioritários. Consegue mostrar esse tipo de correlação? Se ouvir frases como “Não entendo o que o controle de qualidade está fazendo mesmo”, este é um sinal de alerta. A equipe pode se perder em otimizações técnicas.

O perigo da falta de alinhamento é o da otimização local em detrimento de todo o sistema. É perigoso permitir que uma equipe de QA se concentre num rework extenso, otimização de framework e redesenho de teste. Eles começam a adquirir o hábito de otimizar seus próprios ciclos de feedback sem necessariamente agregar valor ao restante da equipe. Esse tipo de comportamento faz com que técnicos satisfeitos se esqueçam completamente do verdadeiro objetivo de seu trabalho. Levado tarde demais, poderá ouvir “É melhor começar um novo framework, ele se tornou muito complexo.”. Isso nos leva ao tema do design de teste.

Os testes automatizados exigem um design como qualquer atividade de engenharia bem feita. Uma série de armadilhas devem ser evitadas, como copiar os testes de um conjunto manual ou deixar os testes criados por um gravador. Pode decidir usar alguns desses ativos uma vez que os trabalhos preliminares de arquitetura, design e modularização tenham sido concluídos. O design de teste também trata da seleção de quais testes não serão implementados, uma importante tipologia de teste a ser esclarecida desde o início.

A tendência desses sintomas é de desequilíbrio. É quando a equação custos/benefícios não é mais satisfatória. 

Adressa a dívida do teste antes que seja tarde demais

As partes interessadas ​​são pessoas que investem dinheiro por dois motivos: ganhar ou parar de perder dinheiro. Pode chegar o dia em que o investimento para, quando a dívida de teste chega a uma lacuna inaceitável entre o valor real e o valor esperado.

“A dívida de teste não acontece durante a noite. É a soma de decisões tomadas e não tomadas por um conjunto de atores dentro do ecossistema. ”

Antoine Craske

Todos nós queremos evitar esta situação. Perceber os motivos que levam à dívida de teste esclarece que os vários fatores não são devidos a uma única pessoa, equipe ou problema. É necessária uma abordagem mais integrada e incremental.

Abordamos essa abordagem no artigo a seguir sobre como capacitar a automação de testes com o Quality Engineering.