A qualidade não está no teste, ele simplesmente atesta se ela existe ou não. Tentar lutar contra bugs é caro, ineficiente e muitas vezes contraproducente, pois não traz qualidade, apenas confirma que ela não existe. Mas ao se analisar a natureza dos erros pode-se entender quais medidas preventivas podem ser efetivas e reduzir o custo de testes, retrabalho e desgastes de imagem.
“Uma grama de prevenção vale mais que um quilo de remédio” (Benjamin Franklin)
Diversos estudos, dentre eles alguns publicados pela Quality Faster, mostram os principais tipos de erro:
1. Defeito de implementação
A especificação estava correta, mas a implementação teve um erro. À primeira impressão é o erro mais comum. Entretanto apenas 20% dos erros ocorrem durante o período de implementação. Apesar de ser um patamar elevado e passível de ser reduzido, ele mostra que com frequência o investimento em qualidade está sendo feito no lugar errado.
Defeitos desse tipo ocorrem quando analistas, por mais experientes e capacitados que sejam, geram defeitos em funcionalidades de uma aplicação quando estão implementando novas features.
A melhor forma de detectar esse tipo de erro é através de testes regressivos, sejam eles executados manualmente ou automatizados, como é o caso dos testes executados nas aplicações da plataforma Atlas.
2. Delimitação de escopo
Alterações frequentes no escopo durante a execução do processo de desenvolvimento geram aproximadamente 15% dos erros, mas são responsáveis por parcela muito mais significativa nas alterações de custo e prazo. Assim, apesar de representarem estragos significativos no processo de entrega e merecem atenção dos gestores, problemas em REQM (gerenciamento de requisitos) também não representam a maior fonte de e erros.
3. Erros de comunicação e expectativas divergentes
Erros no processo de especificação técnico-funcional representam 65% dos erros detectados nos processos de homologação, mas esse percentual tende a subir quando a variável computada deixa de ser o erro, mas o investimento feito na correção. Nesse caso, esse índice sobe para próximo de 80% da despesa com retrabalho. Isso ocorre quando sempre que usuários não conseguem sistematizar suas necessidades, não compreendem o output do que estão demandando ou não conseguem determinar com clareza tal output. Com isso “pedem errado” ou “aprovam algo errado”.
Uma forma de proeminente de se mitigar tais erros é a utilização do desenvolvimento focado em testes (Testing Driven Development – TDD) na qual as especificações possuem um caráter “executável”, estabelecendo e delimitando critérios de aceitação que poderão ser melhor avaliados pelos usuários finais e pactuados entre as partes. Nesse caso, o desenvolvimento será voltado para atender os resultados definidos com antecedência. Isso simplifica o processo de codificação, antecipa erros, reduz retrabalho e minimiza frustrações durante o processo de entrega. Por essa razão esse tem sido o principal foco de investimento da equipe de Quality Assurance da BRITech em 2017.
