Princípios e realidades dos testes

• O objetivo dos testes é encontrar falhas.
• Não é possível testar um software exaustivamente (todas as combinações possíveis) por vários motivos:
  • O número de entradas é muito grande
  • O número de saídas é muito grande
  • O número de de caminhos que podem ser executados é muito grande

Ex.: Imagine um programa que tenha como entrada um campo que aceite um código de 6 caracteres. O primeiro caractere deve ser numérico (‘0’ a ‘9’) e os demais alfanuméricos (‘0’ a ‘9’, ‘a’ a ‘z’ e ‘A’ a ‘Z’).  Quantas combinações seriam necessárias para testar todas as possibilidade de entrada neste campo?

•  
  • 1º caracter: 10 possibilidades: 0, 1, …, 9
  • 2º a 6º: 62⁵ possibilidades
  • Total: 10x(62⁵)=9.161.328.320 combinações

Supondo que cada teste gaste 10s, o teste de todas estas combinações levaria 2.905 anos!

• Para que seja encontrado o maior número de falhas, devem ser usadas técnicas de teste  caixa preta e caixa branca.
• O teste é baseado em riscos: o analista de testes deve decidir o que testar e o que deixar de fora do teste

Fonte: Ron Patton – Software testing

• O teste apenas mostra a presença de falhas e nunca sua ausência.  Não é possível afirmar que um software não possui falhas. Elas apenas não foram encontradas, ainda.
• Nem todos as falhas encontradas serão corrigidas. O que não significa que foi um trabalho perdido. Ou o software será entregue com uma qualidade ruim. Para decidir quais serão corrigidas, deve ser feita uma análise de riscos para ver qual o impacto de não corrigir a falha naquele momento. Só o tempo dirá se a decisão foi correta ou não. Nem todas as falhas são corrigidas pelos seguintes motivos:
  • O tempo acabou
  • A falha encontrada pode não ser uma falha (falso-positivo): podem ser na verdade solicitações, alterações na especificação,…
  • É arriscado corrigir naquele momento. Às vezes é melhor ter uma falha conhecida que se sabe como contornar do que tentar corrigir e introduzir novas falhas ou atrasar o cronograma.
  • Simplesmente não vale à pena. Falhas que aparecem em funcionalidades que não serão muito usadas ou que tem como ser contornadas podem não ser corrigidas. É uma decisão de negócios, baseada em riscos.
• A especificação nunca está pronta. Sempre tem um ajuste a ser feito, por causa do mercado dinâmico, da concorrência, etc.
• O teste deve ser executado em todas as fases do desenvolvimento (incluindo a especificação). Não é uma atividade do fim do ciclo de desenvolvimento.
  • Mito do desenvolvimento de software: Até que o programa esteja “rodando” não é possível avaliar sua qualidade.
  • Realidade:  Os testes devem ser iniciados na fase de especificação, através do teste de especificação.
• Entenda a razão por trás do teste.  Saber o porquê do teste é tão importante quanto saber o que testar e como testar.  Por exemplo, um software que já está sendo comercializado ou em produção sofre uma alteração. Devem ser executados testes de regressão para garantir que não haverá efeitos colaterais no software como um todo.

Fonte: Srinivasan Desikan; Gopalaswamy Ramesh – Software Testing: Principles and Practices

• Teste os testes primeiro. Um teste com defeito é mais perigoso que um software com defeitos.

Fonte: Srinivasan Desikan; Gopalaswamy Ramesh – Software Testing: Principles and Practices

• Testes desenvolvem “imunidade”. Devem ser revistos sempre. Um conjunto de testes exercita somente alguns caminhos no software e pode encontrar falhas somente naquele trecho de código. Uma vez encontradas todas as falhas naquele trecho, ficar executando os mesmos testes não serão encontradas novas falhas. Além disso, quando ocorre uma falha, algumas funcionalidades podem não ter sido testadas. Uma vez corrigida e retestada esta falha, estas funcionalidades podem  ser testadas e novas falhas podem ser encontradas.
• Quanto mais falhas foram encontradas, mais existirão. “A probabilidade de existir mais falhas em uma sessão do programa é proporcional ao número de falhas já encontradas nesta sessão.”[Meyers, 79]. Isto por vários motivos:
  • O programador poderia estar num dia ruim
  • Algumas falhas são apenas a ponta do ‘iceberg’. Várias falhas podem ter a mesma causa raiz
  • Ao corrigir uma falha, outras podem ser introduzidas na mesma sessão.
• Os testes devem prever as falhas. “Prevenir é melhor que remediar”. Os analistas de testes têm condições de prever os problemas que o usuário final poderá encontrar. Uma vez encontrado um problema, sua causa raiz deve ser encontrada, o que ajudará a prevenir novas falhas.
• Os testes devem ter um ajuste fino entre a prevenção e a detecção de falhas. A prevenção de falhas é conhecida como Quality assurance (garantia da qualidade) e a detecção de falhas como Quality control (controle da qualidade).  As duas atividades devem ser combinadas escolhendo o quadrante correto na figura a seguir.

Fonte: Srinivasan Desikan; Gopalaswamy Ramesh – Software Testing: Principles and Practices

• Automação inteligente e bem-planejada é a chave para a execução de testes eficientes. A automação deve ser planejada, avaliada e executada com cuidado. Elas podem não produzir resultados imediatos. A automação deve ser usada quando forem executados testes repetitivos.