Área de Testes Independente

Até por ser do interesse dele (o professor que está ministrando o tal curso que mencionei no post anterior), ele passou muito tempo falando da importância de se ter uma área independente do desenvolvimento para os testes, com argumentos como é essencial para o CMM3, etc.

Mas é realmente a prática mais aceita como "State of the Art" internacionalmente. O que significa que alguns desses argumentos foram bons, mesmo no lado financeiro que eu posso descrever bem melhor e com exemplos se for o caso (ter um coordenador de testes + alguns testadores é mais barato que parar os desenvolvedores por diversas razões...

Enfim, existem diversas vantagens que a maioria das empresas grandes valoriza mais do que as desvantagens:
* encontrar problemas mais cedo;
* complexidade menor de gerenciar a validação se já são pessoas independentes do desenvolvimento executando os testes;
* diminui a chance de se subdimensionar os esforços de testes (coordenador específico disso);
* possibilidade de execução em paralelo (desenvolvimento/testes);

Porém, claro que há algumas desvantagens de se ter a tal área de testes:
* custos maiores, pelo menos nos custos fixos ( é relativo, mas o benefício de detectar mais bugs, mais cedo pode até ser medido - mas em geral o ROI é de 400-600% segundo diversas estatísticas que foram apresentadas);
* tendência da equipe de desenvolvimento em relaxar na parte que lhe cabe (verificação);
* desentendimento entre as duas equipes (dedo duros Vs. preguiçosos);

Estatística de Descoberta de BUGS

Recentemente, estive fazendo um curso preparatório para o certificado CBTS (certificado brasileiro de teste de software) que me mostrou diversas coisas interessantes para melhorarmos o nosso processo de testes na empresa, porém, vou começar com uma coisa que é apenas a base para se começar... A idéia de que um processo de testes perfeito, provavelmente é uma opção imperfeita! Por isso, vou mostrar as estatísticas de percepção de bugs que foram levantadas há um bom tempo atrás e também mostrar a idéia de quando é bom se parar de testar... Nada objetivo, mas é bom se ter isso em mente sobre um processo de testes antes de começar.

Estatística de percepção de bugs:
- entre 30-50% dos defeitos de um software podem ser pegos por testes unitários;
- 30-50% dos defeitos restantes podem ser pegos com testes de sistema;
- revisão de código pode diminuir mais 20-30% dos defeitos restantes;

- ou seja, 49% dos defeitos podem sair desse processo da verificação, mas a média deve estar mais próxima de 30-40% dos defeitos passam pela verificação;

Conclusões:
- de 30-50% dos defeitos que passam pela verificação podem ser detectados em uma validação;
- não há como provar que não existem defeitos no software, só que nenhum defeito foi encontrado;

Ponto Ótimo de Teste:
- Existe um custo envolvido em não se detectar um defeito (mancha na reputação da empresa, custo de alteração no cliente, etc) e existe um custo envolvido em se detectar estes defeitos (executar os processos de validação, verificação).
- Um dos pontos importantes é saber achar esse ponto, porque buscar o estado de "Zero-Defect" pode sair mais caro do que deixar alguns problemas passarem;
- Conforme se executa verificações e validações, a idéia é ir eliminando os problemas mais graves/prováveis e deixar estes de baixa ocorrência para um possível cliente descobrir, porque chega um ponto onde é mais caro descobrir/corrigir estes problemas do que arrumar o problema do cliente;