Automação de testes tem ROI … investimento e ganhos

Já escrevi sobre a miopia brasileira no que é ROI, diretamente proporcional ao medo que se tem de métricas e indicadores, tão legitima e racional quanto o dito popular de que cachorro mordido por cobra tem medo de linguiça. No receio de que números e informações sejam usadas de forma indevida, melhor sermos “ágeis” e não tê-los.

Hoje perguntei a colegas qual seria o percentual médio de tempo investido no desenvolvimento de testes automatizados em um projeto de ponta, usando cobertura no front (jasmine), no back (junit) e aplicação (protractor). Os próximos 15 minutos foram dedicados a preocupação deles sobre a materialização deste número e como pode ser mal usado.

São consistentes os argumentos de que testes automatizados garantem maior qualidade, que testes de regressão mitigam o risco de erros futuros, tornando a manutenção mais rápida, segura e menos onerosa. Também agrega como auto-documentação, ao adotar TDD também garante um desenvolvimento mais enxuto e consistente.

Métricas

Na maior parte das vezes (todas as semanas), em treinamentos ou consultorias, quando me reclamam que não lhes autorizam ou não é possível trabalhar com testes como deveriam ou que testes são a primeira coisa a serem cortados quando a porca torce o rabo, eu sempre pergunto se há números, métricas de bugs em dev, tsts e prod, quando usando testes automatizados ou não.

Há diferentes formas de arregaçar as mangas e mudar, eu acredito em ROI, apresentar números, um piloto, com tempo de prova, pouca teoria e muita práxis. Mas quando imaginamos ter que levar em consideração o risco e exposição de uma curva de aprendizado, monitoramento e indicadores, a opção de ficar reclamando torna-se atraente.

Curvas e Breakeven

Sou professor acadêmico e na Curva de Tuckman ou em uma curva de aprendizado, temos uma rampa ou aceleração, estas projeções são essenciais. Por exemplo, em linha de produto de software há estudos que mostram que ganhos começam a ser percebidos a partir do terceiro projeto, é o breakeven da construção de serviços de domínio e seu consumo potencial.

A automação de teste é um desafio a cada projeto, em cada sprint planning e design de desenvolvimento discutimos sua cobertura. Nunca participei de um projeto com 100% de cobertura, tudo o que sei sobre isso é que há um breakeven, ponto de equilíbrio, há pontos que urge e outros que não é necessário.

Na minha dissertação no mestrado, estudos de casos mostraram que entre o terceiro e quarto sprint há uma reversão da curva de storming, passando o time a se beneficiar de quase dois meses de trabalho auto-organizado e colaborativo, com planejamento, diárias, refinamentos, reviews e retrospectivas. Até então temos entregas com valor aquém do potencial do time.

ROI

Há um ROI no uso de testes automatizados, mas só o que vejo em eventos e discussões são argumentos teóricos (ou poéticos) e promessas, nos faltam números cruzando estatísticas (80:20) de médias de investimento (custo) x benefícios (métricas) em cases reais. Talvez por isso esteja demorando tanto para tornar-se uma regra.

Sim, fatores intangíveis e alguns controversos podem compor partes do cálculos de ROI, assim muitas vezes é preciso usar uma percepção numérica plausível, média, em comum acordo, algumas vezes buscando ajuda de especialistas. De toda forma, inexiste ROI se não há um cálculo ou abstração de custo ou investimento em relação a ganhos e benefícios.

No caso de testes, é preciso perceber os vetores envolvidos de forma a podermos comparar projetos em custos e ganhos relacionados aos mesmos, entre o uso de testes automatizados e manuais.