Axiomas sobre os testes de software
Antes de conhecer os axiomas associados ao teste de software, precisamos saber que um axioma é uma sentença ou preposição que não é provada ou demonstrada e é considerada como óbvia ou como um consenso inicial necessário para a construção ou aceitação de uma teoria.
Por essa razão, é aceito como verdade e serve como ponto inicial para dedução e inferências de outras verdades (dependentes de teoria) (Fonte: Wikipédia)
Assim axiomas de testes de software são afirmações sobre testes admitidas como válidas ! Vamos então conhecer nove axiomas sobre os testes de software.
- O número de entradas, caminhos internos e saídas são muito grandes
Ex.: Uma simples entrada de um número inteiro pode receber um grande número de possibilidades: número inteiros, números reais, caracteres, símbolos como “.” “,”
- A especificação do software é subjetiva, dúbia ou incompleta
- A avaliação de alguns aspectos do software é subjetiva
- Os critérios de avaliação podem mudar com o tempo
Assim nunca se deve dizer que em um determinado software não existem erros, mas apenas que em função dos testes realizados não foram encontrados erros!
Como não é economicamente viável testar todas as funcionalidades de um software, deve-se decidir o que testar, quando testar e o que não testar. A medida que se aumenta a quantidade de testes, reduz-se o número de bugs, entretanto eleva-se proporcionalmente o custo dos testes. Assim deve-se buscar o ponto ótimo de testes, onde o custo dos testes e o numero de bugs apresentam a melhor relação possível.
Assim como um exterminador de pragas, não pode examinar uma casa e afirmar definitivamente que ela não possui nenhum tipo de praga, e um médico não pode afirmar com exatidão que uma pessoa não tem nenhuma doença, um testador de software pode, no máximo, afirmar que não existem indícios de bugs no software. Pois se continuar a testar, ou aumentar o critério de procura, provavelmente irá encontrar outros bugs.
Os bugs tem origem em um entendimento equivocado do problema, o qual gera uma “família” de erros, onde um erro acaba justificando outro.
Assim como com insetos, quando se vê uma barata na cozinha, provavelmente existem outras…
Boris Beizer criou o Paradoxo do Pesticida para os testes de software: que diz que cada método ou técnica usada deixa falhas residuais que não são detectáveis por esse método ou técnica.
Exemplo: Os mesmos testes aplicados repetidas vezes podem não detectar falhas que ainda permanecem no programa.
Razões para não se corrigir os bugs:
- Falta de tempo ou de recursos
- Pouca importância do bug: existem soluções alternativas (reset no computador)
- A correção é muito arriscada. Melhor evitar que as condições de erro aconteçam
- Simplesmente não vale a pena ou não é um bug de verdade.
- Pois a especificação pode estar errada
- O sistema deve ser comportar assim mesmo
- A percepção do analista de teste pode está errada
- O sistema é difícil de entender e pode estar certo
Considerando-se a natureza dinâmica dos negócios ao qual o software sob teste irá atender:
- Deve-se assumir que as especificações vão mudar
- O ambiente é alterado enquanto o software está em desenvolvimento
- Os testes podem mesmo orientar o desenvolvimento como proposto pela metodologia eXtreme Programming (XP)
Sabendo-se que a missão do testador é encontrar erros, ele acaba naturalmente se tornando um portador de más notícias
O testador deve sempre buscar um relato imparcial e profissional do bug
Um relato positivo é sempre bem vindo, comemore um baixo número de bugs
Ex.1 – Relato pouco profissional
O programa está muito ruim. Não executa nada do que foi especificado. Já no início do uso do sistema , teclando Arquivo> Abrir, o programa apresenta uma mensagem de erro.
Ex.2. – Relato mais profissional
Bug encontrado na operação Arquivo>Abrir. O programa exibe a mensagem: Nenhum arquivo foi localizada. O programa deveria exibir uma janela de diálogo para seleção de um arquivo.
Embora historicamente a atividade de testes tenha sido colocada para um segundo plano, ela é uma atividade técnica que exige bons conhecimentos de programação onde a organização é essencial. O testador deve ter facilidade de expressão escrita, diplomacia e profissionalismo e boa experiência. Considere também que essa atividade pode ser divertida
E você, concorda ou não com essas nove verdades sobre os testes de software?
Related posts:
Bom post Gaelote.
Esses axiomas estão presentes diariamente na equipe de desenvolvimento.