Visões sobre teste de software

Um testador de software é qualquer ser humano que testa o software. Então, o que responderiamos se alguém perguntar

"O teste de software precisa de uma habilidade especializada"?

Parece muito simples responder a essa pergunta, não é? Mas claro que não é. O teste de software não é tão fácil quanto comumente se imagina. Desnecessário dizer que é uma das tarefas mais importantes e difíceis em toda a gama de processos do ciclo de vida de desenvolvimento de software.

A reação dos seres humanos neste mundo complexo de acontecimentos varia amplamente com respeito a situações, ambientes, emoções, necessidades, requisitos, período de tempo, dinheiro, crenças, educação, conhecimento, especialização, intuição e assim por diante. A natureza do ser humano é complexa e certamente não existe exceção quando estamos no local de trabalho. Portanto, é simplório dizer que o trabalho que está sendo feito (teste de software) por um testador de software é simples.

No entanto, a qualidade do trabalho de um testador de software é diretamente proporcional a sua maturidade psicológica e profundidade adquirida, adotada e desenvolvida com a idade e principalmente, experiência.

Em "The Art of Software Testing" (1979), Meyers afirma que "A psicologia das pessoas que realizam o teste terá um impacto no processo de teste" (tradução nossa). Nesse mesmo livro, Mayers diz ainda que uma das principais causas de testes insatisfatórios é o fato de que a maioria dos programadores começa com uma definição falsa do termo. Definições do tipo:

• "Teste é o processo de demonstrar que os erros não estão presentes."

• "O objetivo do teste é mostrar que um programa executa o seu objetivo funciona corretamente."

• "Teste é o processo de estabelecer a confiança de que um programa faz o que é suposto fazer."

Aparentemente são falsas ou estão dizendo exatamente o inverso do que é um teste. Ao testar um programa, você deseja adicionar algum valor a dele. Agregar valor por meio de testes significa aumentar a qualidade ou confiabilidade do programa. Aumentar a confiabilidade do programa significa encontrar e remover erros. Portanto, não teste um programa para mostrar que ele funciona; em vez disso, comece com a suposição de que o programa contém erros (uma suposição válida para quase todos os programas) e, em seguida, teste o programa para encontrar o maior número possível de erros.

Assim, uma definição mais adequada, segundo Meyers, seria:

Teste é o processo de execução de um programa com a intenção de encontrar erros.

Embora isso possa soar como um jogo de semântica sutil, é realmente uma distinção importante. Compreender a verdadeira definição de teste de software pode fazer uma grande diferença no sucesso de seus testes.

Os seres humanos tendem a ser altamente orientados para um objetivo e estabelecer o objetivo adequado tem um importante efeito psicológico sobre eles. Se nosso objetivo é demonstrar que um programa não tem erros, então seremos subconscientemente direcionados para esse objetivo; ou seja, tendemos a selecionar dados de teste que têm baixa probabilidade de fazer com que o programa falhe. Por outro lado, se nosso objetivo é demonstrar que um programa possui erros, nossos dados de teste terão uma probabilidade maior de encontrar erros.

A última abordagem agregará mais valor ao programa do que a primeira. Por exemplo, isso implica que o teste é um processo destrutivo, até sádico, o que explica por que a maioria das pessoas acha isso difícil. A definição também tem implicações sobre como os casos de teste (dados de teste) devem ser projetados e quem deve e quem não deve testar um determinado programa. Outra maneira de reforçar a definição adequada de teste é analisar o uso das palavras ''bem-sucedido'' e "malsucedido" - em particular, seu uso por gerentes de projeto na categorização dos resultados dos casos de teste. A maioria dos gerentes de projeto referem-se a um caso de teste que não encontrou um erro de "execução de teste bem-sucedida", enquanto um teste que descobre um novo erro é geralmente chamado de "malsucedido".

Mais uma vez, isso está ao contrário. "Malsucedido" denota algo indesejável ou decepcionante. Em nossa maneira de pensar, um teste de software bem construído e executado é bem-sucedido quando encontra erros que podem ser corrigidos. Esse mesmo teste também é bem-sucedido quando, eventualmente, indica que não há mais erros a serem encontrados. O único teste malsucedido é aquele que não examina corretamente o software; e, na maioria dos casos, um teste que não encontrou erros prováveis seria considerado malsucedido, uma vez que o conceito de um programa sem erros é basicamente irreal.

Um caso de teste que encontra um novo erro não deveria ser considerado malsucedido; em vez disso, ele provou ser um investimento bem feito. Um caso de teste malsucedido deve ser aquele que faz com que um programa produza o resultado correto sem encontrar nenhum erro.

Referências

MYERS, Glenford J. et al. The art of software testing. Chichester: John Wiley & Sons, 2004.

Paper - Why software testing is sometimes ineffective: Two applied studies of positive test strategy. https://psycnet.apa.org/record/1994-31744-001