Geralmente muitos dos princípios de teste de software parecem ser óbvios, mas na verdade conhecê-los ajudam bastante no momento de testar, pois criam uma barreira de consciência no testador, o qual se tornará mais crítico no momento de elaborar os casos de teste e de testar.
1º Princípio: Uma parte importante de um caso de teste é uma definição de resultado esperado.
Se o resultado esperado não tiver sido pré-definido, então resultados errados poderão ser considerados corretos. Devido ao fenômeno de que "os olhos veem o que eles querem ver". Há um desejo no subconsciente de ver o resultado correto. Uma forma de tirar isso é fazer uma análise detalhada de todas saídas em busca de uma ortografia perfeita, antes de verificar a saída esperada pelo programa.
2º Princípio: Um programador deve evitar ser o único a testar seu próprio programa.
Apesar de o programador não ser a pessoa mais indicada a testar seus códigos, quando ele realiza alguns testes, ele provavelmente encontrará muitos dos erros mais óbvios. Porém, quando o teste exige diferentes cenários, onde envolve regras de negócio diferentes para cada perfil do usuário, neste caso, a realização de testes por um testador é essencial.
3º Princípio: Os casos de teste não devem ser grandes e exaustivos.
Um bom roteiro de testes possui casos de teste que são facilmente executados pelo testador, os quais não são executados de maneira ambígua. Para isso, os casos de teste têm que ser bem escritos e objetivos, como também devem possuir o menor número de passos possível.
4º Princípio: Fique atento aos resultados de cada teste.
É normal as pessoas não detectarem certos erros, mesmos quando estes erros podem ser claramente esperados no resultado dos casos de teste.
5º Princípio: Casos de teste devem ser escritos com entradas que são inválidas e não esperadas, como também com entradas válidas e esperadas.
Quando criamos uma tabela de decisão que define para cada entrada o resultado esperado, aumentam-se as chances de se encontrar erros nos casos que não foram previstos pelo programador.
Quando criamos uma tabela de decisão que define para cada entrada o resultado esperado, aumentam-se as chances de se encontrar erros nos casos que não foram previstos pelo programador.
6º Princípio: Examinar um programa para ver se ele não faz que é proposto, é apenas metade da batalha; a outra metade é verificar se o programa faz o que não é proposto.
Este é um corolário para o princípio anterior. Os programas devem ser testados devido a problemas secundários indesejáveis. Por exemplo, um bug em um programa de folha de pagamento que exibe pagamentos válidos para funcionários que não existem.
7º Princípio: Evite casos de teste descartáveis, a menos que o programa seja também descartável.
Muitas vezes o testador executa casos de teste aleatoriamente e quando precisa retestar aquele programa tem que gastar tempo novamente criando novos casos de teste. O problema é que geralmente o reteste não é tão rigoroso quanto o teste original. Assim, se uma nova funcionalidade causar falha, ela provavelmente não será detectada. Ao armazenar os casos de teste em um documento e reexecutá-los novamente a cada iteração, isto é conhecido como teste de regressão.
8º Princípio: Nunca faça um teste assumindo que nenhum erro vai ser encontrado.
Este é um erro que os testadores geralmente cometem, o que é um sinal do uso incorreto da definição de teste. A definição correta é que teste é um processo de executar um programa com o intuito de encontrar erros.
9º Princípio: A probabilidade de encontrar mais erros numa seção de um programa é proporcional ao número de erros já encontrados naquela seção.
Apesar de fazer pouco sentido, isto acontece na maioria das vezes. Por exemplo, tem um programa com 2 módulos, A e B, onde em 'A' foram encontrados 5 erros e em 'B' foi encontrado apenas 1 erro. A probabilidade de encontrar mais erros em 'A' num segundo ciclo de teste é maior que a probabilidade de encontrar mais erros em 'B', porque como em 'A' havia mais erros que em 'B', logo ao corrigir os erros de 'A', há a possibilidade de surgir novos erros. Outra hipótese é que os erros vêm em aglomerados, ou seja, um erro desencadeia outro, e também algumas seções são mais propícias a erros que outras.
10º Princípio: Testar é uma tarefa extremamente criativa e intelectualmente desafiante.
Provavelmente é verdade que a criatividade requerida para testar um programa grande seja maior que a criatividade requerida para criar aquele programa. Sabemos que é impossível tirar 100% dos erros. Existem muitas metodologias para criar casos de teste, mas estas metodologias ainda precisam de muita criatividade.
Então, ao analisar todos os princípio podemos extrair os 3 principais princípios, que são eles:
- Testar é um processo de executar um programa com o intuito de encontrar erros.
- Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto.
- Um excelente caso de teste é aquele que encontra um erro ainda não descoberto.
Referência:
MYERS, G. J. The Arts of Software Testing - 2nd. ed. John Wiley & Sons, Inc.,USA, 2004, chap. 2 pag. 14-20.
Atualizado em: 21/05/2019
Redes Sociais