.png)
Quantidade de testes x custo dos testes
Estou criando tópicos para tirar dúvidas de leitores que, vez ou outra me escrevem. Este primeiro tópico irá abordar não exatamente uma dúvida, mas um ponto de discordância de um colega de fórum.
---------------------------------------------------------------
Se você deseja particiar de um tópico destes, envie sua dúvida para: fernando.palma@gmail.com
Se você deseja acrescentar algo, use os comentários
----------------------------------------------------------
YvGa,
O nível de qualidade de um serviço ou produto é variável e negociável, depende do que este serviço/produto irá atender.
Entendo que o conceito de desenvolvimento ágil, tais como metodos XP e SCRUM, vão de encontro a esta afirmativa. Entretanto, a depender do cenário, objetivo e metodologia utilizada, a qualidade é uma variável mensurada. Vejamos um exemplo:
Quando um gerente de projetos planeja a entrega do de um sistema, ele precisa analisar conhecer o escopo do sistema a nível de requisitos não funcionais:
- quantos usuários irão utilizar a aplicação;
- quantos acessarão o sistema simultaneamente;
- qual a carga de informação que será tratada nas transações do sistema.
Entre outros.
Baseado nestes requisitos, ele entrará em acordo de nível de qualidade tais como performance, disponibilidade e níveis de serviço em geral que o sistema deve atender. Irá então formalizar os critérios de aceite do sistema e gerenciar a qualidade, através dos processos de controle e garantia da qualidade.
O Analista de testes por sua vez, irá especificar os testes que atendam ao nível de qualidade que o gestor do projeto aprovou com o cliente.
Voltando para o exemplo anterior da tela de consulta:
Eu estou entregando em Novembro um sistema para uso interno em uma Universidade aqui em Salvador. Este sistema irá atender a 3 mil professores entre os meses de Novembro de 2009 e Março de 2010.
Digamos que neste sistema descrito acima, exista uma tela de consulta com 5 campos. Eu com certeza irei orientar que os testes sejam realizados para cobrir apenas uma parte de todas as combinações possíveis (da análise combinatória apresentada).
Exemplo de quantidade de testes que eu faria:
Campo 1 Campo 2 Campo 3 Campo 4 Campo 5
1 0 0 0 0
1 1 0 0 0
1 1 1 0 0
1 1 1 1 0
1 1 1 1 1
Como pode ver, estes não são todos os testes que possíveis de se realizar. Existem mais combinações. Entretanto, eu assumo o risco de não estar testando todas elas.
Razão:
Digamos que ao omitir alguns testes, eu esteja correndo o risco de 5% de ocorrer um bug em produção, nesta tela de pesquisa, ao realizar uma consulta.
Caso eu tenha uma ferramenta que automatize os testes, faria todos eles sem pensar duas vezes. Mas não é minha realidade, atualmente nem para muitos. Em fábrica de software, utilizei ferramentas que traziam este diferencial.
Em caso de utilização de TDD, os testes sobressalentes como estes seriam seriam minimizados ou ausentes, uma vez que o código estivesse pronto. Mesmo assim, ainda existe o risco - alto - das falhas de especificação, que trazem a tona a decisão por equilibrar a velha balança: custo x qualidade.
No exemplo dado, o bug será relatado ao servicedesk e representará um custo, em média de 100 reais por hora para ser corrigido (por conta da indisponibilidade e alocação de recursos.
Lembrando que estes números são ilustrativos.
Na verdade eu estou correndo o risco de 5% com impacto de 100 reais a hora. Em uma estimativa de 10h de paradas (pessimista), eu estou dando um prejuízo de 0,05 * 100 * 10 = 50 reais.
O custo que eu teria para testar todas as possibilidade é maior do que 50 reais, ainda mais pelo fato de eu não possuir uma ferramenta.
Agora tomemos um contra-exemplo: um sistema bancário.
Uma única falha de minutos em um sistema de banco, pode significar milhões em perdas financeiras. Por isso, ao implementar um sistema de banco o nível de qualidade deve ser negociável ao extremo. Deve ter um alto nível de qualidade e isso tem um custo. Planejamento será mais minucioso, testes serão realizados a nívels altos.
O google , por exemplo, deve ter ferramentas poderosas de testes que realizam todas a combinações possíveis em "pesquisa avançada". Isso porque um erro de pesquisa no google é mais custoso do que no meu caso.
Segue abaixo, um gráfico clássico para profissionais de qualidade:
Alinha amarela representa o custo ou quantidade de testes
A linha vermelha representa a quantidade ou prejuízo dos bugs
Esta imagem mostra o numero de testes executados e o número de erros. O Gerente de projetos deve moderar os testes feitos para encontrar o ponto de cruzamento entre a linha amarela e a vermelha: numero de testes começa a ultrapassar o custo do número de erros.
Testar demais é tão ineficiente quanto testar pouco.
0 comentários: