Eu escrevi a maior parte do Testing Computer Software há mais de 25 anos. Desde então, apontei para várias partes do livro que considero desatualizadas ou simplesmente erradas. Consulte http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Você pode ver mais (visualizações atuais, mas sem indicadores explícitos de volta ao TCS) no meu site para o Curso de Teste de Software da Caixa Preta (vídeos e slides disponíveis gratuitamente), www.testingeducation.org/BBST
A cultura de teste naquela época era amplamente confirmatória.
Nos testes modernos, a abordagem dos testes de unidade é amplamente confirmatória - escrevemos grandes coleções de testes automatizados que simplesmente verificam se o software continua a funcionar como pretendido. Os testes servem como detectores de alterações - se algo em outras partes do código e esta parte agora apresentar problemas, ou se valores de dados que antes eram impossíveis no mundo real agora estão chegando ao aplicativo, os detectores de alterações são acionados, alertando o programador para um problema de manutenção.
Eu acho que a mentalidade confirmatória é apropriada para testes unitários, mas imagine um mundo em que todos os testes do sistema foram confirmatórios (para pessoas que fazem uma distinção, interprete "testes de integração do sistema" e "testes de aceitação", conforme incluído nos meus comentários sobre o sistema O objetivo do teste era confirmar que o programa atendia às especificações e a abordagem dominante era criar um zilhão (ou pelo menos algumas centenas) de testes de regressão no nível do sistema que mapeou partes da especificação para os comportamentos do programa. (Acho que a confirmação de especificação de comportamento é útil, mas acho que é uma pequena parte de um objetivo maior.)
Ainda existem grupos de teste que operam dessa maneira, mas essa não é mais a visão dominante. Naquela época, era. Escrevi enfaticamente e desenhei contrastes nítidos para destacar pessoas que estavam constantemente sendo treinadas nessa mentalidade. Hoje, alguns dos contrastes acentuados (incluindo o citado aqui) estão desatualizados. Eles são mal interpretados como ataques a visões erradas.
A meu ver, o teste de software é um processo empírico para aprender informações relacionadas à qualidade sobre um produto ou serviço de software.
Um teste deve ser projetado para revelar informações úteis.
Naquela época, a propósito, ninguém falava sobre o teste como um método para revelar "informações". Naquela época, o teste era para (alguma versão de ...) encontrar bugs ou para (alguma versão de ...) verificar (verificar) o programa em relação às especificações. Eu não acho que a afirmação de que os testes são para revelar informações úteis entrou no vocabulário dos testes até este século.
Imagine testes de classificação em termos do valor das informações. Um teste que provavelmente nos ensinará algo que não sabemos sobre o software teria um valor muito alto para as informações. Um teste que provavelmente confirmará algo que já esperamos e que já foi demonstrado muitas vezes antes, teria um valor baixo de informações. Uma maneira de priorizar testes é executar testes de maior valor de informação antes de testes de menor valor de informação.
Se eu simplificasse demais essa priorização para atrair a atenção de um programador, gerente de projetos ou gerente de processos que não tem noção do teste de software, eu diria "UM TESTE QUE NÃO É PROJETADO PARA REVELAR UM ERRO É UMA PERDA DE TEMPO . " Não é uma tradução perfeita, mas para os leitores que não conseguem ou não entenderão nenhuma sutileza ou qualificação, é o mais próximo possível.
Naquela época, e vejo novamente aqui, algumas das pessoas que não entendem o teste responderiam que um teste projetado para encontrar casos de esquina é uma perda de tempo em comparação com um teste do uso principal de uma função principal. Eles não entendem duas coisas. Primeiro, quando os testadores encontram tempo para verificar os valores-limite, os principais usos das principais funções já foram exercidos várias vezes. (Sim, existem exceções, e a maioria dos grupos de testes prestará muita atenção a essas exceções.) Segundo, o motivo para testar com valores extremos é que o programa tem maior probabilidade de falhar com valores extremos. Se não falhar ao extremo, você testa outra coisa. Esta é uma regra eficiente. Por outro lado, se falhar em um valor extremo, o testador poderá parar e relatar um erro ou o testador poderá solucionar problemas ainda mais, para ver se o programa falha da mesma maneira em valores mais normais. Quem faz essa solução de problemas (o testador ou o programador) é uma questão de cultura corporativa. Algumas empresas planejam o tempo do testador para isso, outras planejam os programadores e outras esperam que os programadores corrijam erros de maiúsculas ou minúsculas, sejam eles generalizáveis ou não, para que a solução de problemas não seja relevante. O mal-entendido comum - que os testadores estão perdendo tempo (em vez de maximizar a eficiência) testando valores extremos é outro motivo pelo qual "Um teste que não foi projetado para revelar um bug é uma perda de tempo" é uma mensagem apropriada para os testadores. É um contraponto ao incentivo de alguns programadores para (com efeito) nunca executar testes que possam desafiar o programa. A mensagem é simplificada demais, mas a discussão inteira é simplificada demais.
A propósito, "valor da informação" não pode ser o único sistema de priorização. Não é minha regra quando eu desenho suítes de teste de unidade. Não é minha regra quando eu designo testes de verificação de compilação (também conhecidos como verificações de sanidade). Nos dois casos, estou mais interessado nos tipos de cobertura do que no poder dos testes individuais. Existem outros casos (por exemplo, testes automatizados de alto volume que são baratos de configurar, executar e monitorar) em que o poder de testes individuais é simplesmente irrelevante para o meu projeto. Tenho certeza que você pode pensar em exemplos adicionais.
Mas, como regra geral, se eu pudesse declarar apenas uma regra (por exemplo, falar com um executivo cuja cabeça explode se ele tentar processar mais de uma frase), seria que um teste de baixo valor de informação é geralmente uma perda de tempo.