Sei que é uma questão clássica da engenharia de software: espremer o cronograma da fase de testes, testar pouco, testar mal e depois reclamamos – porque a equipe de desenvolvimento não produziu um software de qualidade? Mas ainda assim, penso que vale o esforço de escrever mais esse texto sobre o assunto, pois certamente é uma questão recorrente nas empresas que desenvolvem software.

Oras se as nossas equipes de desenvolvimento cada vez mais tem um pessoal bem qualificado, muitos com pós-graduação em engenharia de software, conhecedores de metodologias de desenvolvimento, por que será que essa questão é recorrente?

Desenvolver software é uma atividade que envolve riscos, e riscos podem se transformar em eventos no projeto ocasionando atrasos , e atrasos certamente resultam em elevação de custos. A etapa de execução dinâmica dos testes inicia-se após o termino da implementação do código, e a essa altura muitos atrasos e mudanças de escopo já ocorreram no projeto, e nesse ponto tanto a equipe de desenvolvimento quanto os patrocinadores estão pressionados a entregarem o software para homologação pelo cliente. E ai caímos na armadilha, que é a questão clássica apresentada nesse texto: precisamos tirar o atraso no cronograma reduzindo os prazos de testes.

prazo

E para isso lançamos mão de vários instrumentos: reduzimos ciclos de testes funcionais, não fazemos testes de performance, (testes de usabilidade e segurança, nem pensar!), reduzimos a massa de dados utilizadas nos testes funcionais, não fazemos regressão , alteramos o código depois do último ciclo de testes, e torcemos para que tudo corra bem na homologação!

O que nos falta não são conhecimentos sobre a engenharia de software, mas sim uma atitude positiva dos gestores em relação a qualidade, essa palavra tão maltratada no nosso dia a dia de desenvolvimento de software. O que eu chamo de atitude positiva dos gestores é o patrocínio de um cronograma realista para o desenvolvimento. A partir desse cronograma realista se tem as condições para que a qualidade se desenvolva. Caso contrário, ficaremos todos nos iludindo, que estamos fazendo o “nosso melhor dado os prazos curtos”, colocamos um software de má qualidade para homologação pelo usuário, e então a qualidade cobra o seu preço: ciclos e mais ciclos de correções, com elevação dos custos, prazos alongados e satisfação zero do cliente. E você como trata a qualidade do software que desenvolve?