Princípios de Teste de Software

Uma visão simplista dos testes de software é que, se quisermos que nossos sistemas sejam bem testados, tudo o que precisamos fazer é continuar adicionando mais testes até que seja o suficiente. Mas infelizmente não é tão simples.

Na verdade, uma parte muito importante de qualquer processo de teste de software é saber quando interromper o teste. Afinal, os recursos (por exemplo, dinheiro, desenvolvedores, infraestrutura) são limitados. Portanto, o objetivo deve ser sempre maximizar o número de bugs encontrados, minimizando a quantidade de recursos que tivemos que gastar para encontrar esses bugs (isso é engenharia!).

A criação de poucos testes pode nos deixar com um sistema de software que não se comporta como deveria (ou seja, cheio de bugs). Por outro lado, criar testes após testes, sem a devida consideração, pode levar a testes ineficazes (além de custar muito tempo e dinheiro).

Dadas as restrições de recursos, destacamos um princípio importante no teste de software: o teste exaustivo é impossível. Pode ser impossível mesmo se tivéssemos recursos ilimitados. Imagine um sistema de software que tenha "apenas" 300 sinalizadores diferentes (ou definições de configuração). Esses sinalizadores podem ser definidos como verdadeiro ou falso (booleanos) e podem ser definidos independentemente dos outros. O sistema de software se comporta de maneira diferente de acordo com a combinação configurada de sinalizadores. Isso implica que, se fossemos testar exaustivamente esse software, precisaríamos testar todas as combinações possíveis. Um cálculo simples nos mostra que 2 valores possíveis para cada um dos 300 sinalizadores diferentes resulta em $2 ^ {300}$ combinações que precisam ser testadas. A título de comparação, esse número é maior do que o número estimado de átomos no universo. Em outras palavras, este sistema de software tem mais combinações possíveis para serem testadas do que o universo possui átomos.

Dado que o teste exaustivo é impossível, os testadores de software precisam priorizar os testes que realizarão.

Ao priorizar os casos de teste, notamos que os bugs não são distribuídos uniformemente. Empiricamente, observamos que alguns componentes em alguns sistemas de software apresentam mais bugs do que outros componentes.

Outra consequência crucial do fato de que testes exaustivos são impossíveis é que, como Dijkstra costumava dizer

Testes de programas podem ser usados ​​para mostrar a presença de bugs, mas nunca para mostrar sua ausência.

Em outras palavras, embora possamos encontrar mais bugs simplesmente testando mais, nossas suítes de teste, por maiores que sejam, nunca garantirão que o sistema de software esteja 100% livre de bugs. Eles apenas garantirão que os casos testados se comportem conforme o esperado.

Algumas discussões sobre softwares "livres de bug" podem ser encontradas nos fóruns dos moldes do StackOverflow. Vale a pena dar uma olhada aqui pra quem tiver curiosidade.

Para testar nosso software, precisamos de muitas variações em nossos testes. Por exemplo, queremos variedade nas entradas ao testar um método, como vimos nos exemplos acima. Para testar bem o software, no entanto, também precisamos de variação nas estratégias de teste que aplicamos.

De fato, uma descoberta empírica interessante é que se os testadores aplicarem as mesmas técnicas de teste repetidamente, eles perderão em algum ponto sua eficácia. Isso é descrito pelo que é conhecido como o paradoxo do pesticida (que se refere a "bugs" como um termo equivalente para falhas de software):

"Cada método que você usa para prevenir ou encontrar bugs deixa um resíduo de bugs mais sutis contra os quais esses métodos são ineficazes."

Fonte: Software Testing, Ron Patton (2006)

Na prática, isso significa que nenhuma estratégia de teste pode garantir que o software em teste esteja livre de erros. Um exemplo concreto pode ser uma equipe que depende exclusivamente de técnicas de teste de unidade. Em algum ponto, talvez todos os bugs que podem ser capturados no nível de teste de unidade sejam encontrados pela equipe; no entanto, a equipe pode perder bugs que ocorrem apenas no nível de integração.

Do paradoxo do pesticida, concluímos que os testadores precisam usar diferentes estratégias de teste para minimizar o número de bugs deixados no software. Ao estudar as várias estratégias de teste que veremos nessa disciplina, lembre-se de que combiná-las pode ser uma decisão sábia.

O contexto também desempenha um papel importante na maneira como se concebe casos de teste. Por exemplo, desenvolver casos de teste para um aplicativo móvel é muito diferente de criar casos de teste para um aplicativo da Web ou para software usado em um foguete. Em outras palavras: o teste depende do contexto.

Considerações finais

Não nos esqueçamos de que ter um baixo número de bugs não é suficiente para um bom software. Como já dissemos, um programa que funciona perfeitamente, mas não tem utilidade para seus usuários, ainda não é um bom programa. Essa é uma falácia comum (também conhecida como falácia de ausência de erros) que os testadores de software enfrentam quando decidem se concentrar apenas na verificação e não tanto na validação.

Referências

• Software Testing: From Theory to Practice.