sexta-feira, 16 de maio de 2008

Medindo o desempenho do seu teste...

Os testes possuem uma medida de qualidade e estimativa de tempo dos testes (APT) baseada em Pontos por Função que erra por volta de 10%, pelo menos segundo o professor e estatísticas levantadas em uma empresa grande que ele tentou implantar a medida.

Mas como não pretendemos calcular PF na empresa que trabalho, isso já ficou de lado, nem vou comentar muito. Mas ele deu outra estatística (chamada de Defect Removal Efficiency ou DRE), dizendo que o resultado médio das empresas é de 0,3 (sem equipes de testes ou pelo menos um processo de testes bem feito, o que atualmente é raro) e o ideal seria acima de 0,75 (ou ainda chegar acima de 0,9 que é considerado high level). Essa estatística já achei bem mais interessante por ser muito mais fácil de medir e mesmo que não seja 100%, é algum guia.

Esse número é calculado com a fórmula:

NBE = Número de Bugs Encontrados
NBN = Bugs Não Encontrados (achados em produção)

DRE = NBE/(NBE+NBN)

Em média as empresas encontram apenas 1/3 dos defeitos no seu processo de validação. Dito isso eu fiz o cálculo para algumas versões mais simples de calcular, no meu trabalho, o que certamente não é o valor real de verdade, mas deve ser bem razoável (em produção só tenho uma estatística de problemas mais graves, já que detalhes não são pegos lá e são pegos aqui dentro o que distorce um pouco o número).

Por isso acabei descartando os problemas mais simples que encontramos em validação. Ainda assim chegamos em um resultado bem animador de 0,88. Nem perto de estar ruim para uma equipe com um software grande para dar manutenção e sem equipe terceirizada de testes =)

sexta-feira, 9 de maio de 2008

Normatização de Testes

Um ponto importante do curso foi sobre este tema. E vimos que a norma da IEEE ou a formalização do QAI tem modelos de o que deve ser feito no Plano de Testes e guias de como se trabalhar nesse processo.

Não tivemos acesso a norma completa da IEEE, nem sei quanto custa, mas se tiver a possibilidade de comprar pelo pouco que vi, vale à pena para quem está montando o processo do zero.

De qualquer forma, a idéia geral da norma é bem atendica com a implantação de um bugzilla ou mantis (que é um cadastro organizado de bugs...)

Também fiquei com a impressão de que nosso documento do Roteiro de Validação está com texto demais em muitos pontos e faltam alguns campos que o IEEE considera importantes em um RV, mas não é nada grave de qualquer forma... A empresa que trabalho atende bem à norma.

Segundo o IEEE também os tipos de testes deveriam ser realizados durante todo o processo e o fato de não termos uma equipe independente para ir executando estes testes prejudica um pouco, mas se conseguirmos que os testes automáticos abordem todos estes pontos poderemos ter a versão testada em paralelo com muito menos esforço do que fazermos, por exemplo, uma semana de desenvolvimento e outra de testes.

Um outro ponto interessante é que além de abordagens também ficaram algumas estatísticas a respeito do processo de testes:
- 50% do tempo de validação deveria ser gasto com o "planejamento dos testes", 45% com a execução e 5% com a implantação em produção (a "equipe de testes" deveria acompanhar a implantação na produção);
- Por estimativa estatística daria pra dizer que 1-2 horas de teste são necessárias por ponto de função para a execução de um bom teste;
- Um último número mágico é o de que na experiência do professor, os testes devem levar cerca de 10% do tempo de desenvolvimento para alcançarem um bom nível de custo/benefício. Alguns lugares podem levar menos tempo (como em uma promoção de dia das mães que não pode deixar de ser lançada, por mais que tenha bugs ou mais tempo no caso de lugares que precisam presar mais pela qualidade de seus produtos)

quarta-feira, 7 de maio de 2008

Montando um Plano de Validação...

Uma boa prática de Roteiro de Validação segue o seguinte plano:

- Testes Unitários (desenvolvedor) - De preferência automáticos, para garantir que serão bons testes (testes unitários manuais tendem a fazer o "caminho feliz");

- Testes de Sistemas (desenvolvedor) - Verificações com o sistema funcionando ou testes de partes integradas e não mais de funções individuais;

- Validação por Cenários (testador independente - testes trocados) - Execução de roteiros de validação mesmo;

- Testes de Aceitação (usuário final/gerente de produto) - Deixar o produto nas mãos deste usuário para validar as funcionalidades novas, pode encontrar outros problemas, mas não há roteiro envolvido;

Além disso há algumas normas que ajudam a dizer qual o mínimo que se deve fazer para se ter um bom processo. Mas este é um assunto que vai ficar para outro post...

segunda-feira, 5 de maio de 2008

Á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);

domingo, 4 de maio de 2008

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;