Teste de Software é uma investigação empírica feita para informar os stakeholders acerca da qualidade do produto ou serviço sob teste. Entretanto, esta definição não fala nada sobre a inteligência, o que determina uma diferença sutil entre teste e verificação. Michael Bolton compartilha sua opinião sobre esta diferença e sobre o porquê de haver uma diferença entre as duas.
Segundo Michael,
Verificação é algo que fazemos para confirmar nossas crenças existentes. Verificação é um processo de confirmação, verificação e validação. Quando já tivermos algo que acreditamos ser verdade, tentamos confirmar nossa suposição verificando. Fazemos verificação quando incluímos uma alteração no código e queremos ter certeza de que o que estava funcionando continua funcionando.
Teste é algo que fazemos com o intuito de encontrar novas informações. Teste é um processo de exploração, descoberta, investigação e aprendizado. Quando configuramos, usamos e observamos um produto com a intenção de avaliá-lo ou quando pretendemos reconhecer um problema que não tínhamos antecipado, então estamos testando.
Ainda segundo Michael, as verificações são dependentes de máquina porque elas resultam em respostas binárias entre passou ou não passou. Por outro lado, testes precisam de inteligência. Eles são uma maneira exploratória de aprendizado sobre o sistema e de obter respostas a pergunta como, 'Tem algum problema aqui?'. Isto também nos trás uma diferença entre Testadores e Verificadores.
Uma pessoa que precisa de uma especificação clara, completa, atualizada, não ambígua para fazer suas tarefas é um verificador, não um testador. Uma pessoa que precisa de um script de teste para fazer suas tarefas é um verificador, não um testador. Uma pessoa que não faz nada além de comparar as ações de programa com alguma referência definida é um verificador, não um testador.
George Dinwiddie sugere que tanto a verificação quanto o teste necessitam de inteligência. Ele complementa que o que Michael fala sobre 'exercitar e observar' é uma verificação, entretanto é apenas uma parte de um script de teste. Uma vez que exista um teste que falha, então é necessário inteligência por parte do testador para compreender o que realmente aconteceu. Isto pode incluir a verificação de arquivos de log, contatar alguém para ver se outros sistemas estão funcionando corretamente e fazer um grande número de outras explorações em busca de mais informação. Não há diferenças para os testes exploratórios, exceto por longos atrasos de tempo entre as atividades.
Michael concordou com isto em um certo grau quando mencionou que uma verificação em si é relativamente trivial. Entretanto, bastante inteligência é necessária antes e depois da verificação. Aliás, esta é a diferença entre conferir e verificar.
Então a ação em si está além do que costumamos valorizar: as conferências ("emos 50.000 testes automatizados") ou as verificações. Meras conferências não são importantes; mas as verificações—as atividades necessárias para criar, manter e analisar as conferências—são. Parafraseando Eisenhower, com respeito a verificação, as conferências não são nada; a verificação é tudo. Ainda que a verificação (nem o teste) não seja tudo.
Johanna Rothman expressou sua opinião em termos semelhantes quando ela menciona as habilidades necessárias para se criar uma abordagem para testes que promovam a inteligência,
Projetos ágeis necessitam de verdadeiros generalistas como testadores: pessoas que tenham conhecimentos de requisitos, de projeto e de código. Sem estas habilidades, eles não são pensarão de maneira suficientemente crítica sobre o produto em desenvolvimento e eles podem não ser capazes de criar uma variedade suficiente de testes. Se eles compreendem os requisitos, o projeto e o código, eles podem usar esta compreensão para criar testes que sejam efetivos. Alguns destes testes podem ser exploratórios. Mesmo alguns dos testes exploratórios precisarão ser automatizados para que possam ser repetidos. E eu já vi grandes testadores em projetos ágeis capazes de criar teste automatizados rapidamente para fazer alguma exploração.
Cem Kaner, entretanto discorda da ideia de testadores ágeis sendo generalistas. De acordo com ele, uma vez que testes exploratórios precisam tanto da essência de testes quando da exploração para serem válidos, é necessário que habilidades específicas sejam usadas. Nas palavras de Cem,
Programadores entendem muitos dos riscos de um projeto. Eles são provavelmente melhor equipados para criar testes bem pensados para explorar tais riscos do que os não programadores. Outras pessoas têm mais foco na integração do software com seu ambiente. De maneira semelhante, nós conhecemos especialistas em avaliação de desempenho e de segurança. Alguns são programadores e alguns não. Quando se trata de validação de software em nível de sistema, todas estas pessoas podem conduzir testes guiados por scripts ou testes exploratórios.
Segundo George existem pontos fortes e fracos em ambos os modelos. Tanto a verificação quanto os testes podem ser tratados como testes segundo a definição de Cem Kaner. O xis da questão aqui não está no script mas no processo de como você está conduzindo suas atividades.
Ambos são testes, em termos de se encontrar novas informações e em termos de necessitarem de inteligência. Se você não estiver pensando sobre isso, você está fazendo errado.
Recentemente a InfoQ também publicou um artigo sobre as Razões para se Amar o Teste Ágil.