Como a verificação não inclui testes reais?

Depois de ler muito sobre esse tópico - como neste site Fundamentos de teste de software sobre verificação e validação e Testes de software e garantia de qualidade: teoria e prática de Naik e Tripathy - ainda não entendi. A verificação deve provar que você está construindo o produto certo, enquanto a validação prova que você construiu o produto certo. Mas apenas técnicas estáticas (revisões de código, verificações de requisitos ...) são mencionadas como métodos de verificação. Como você pode dizer se está implementado corretamente, se você não testá-lo? Diz-se que a verificação garante que o produto atenda aos requisitos especificados. Novamente, se a função for especificada para funcionar de alguma forma, somente testando posso dizer que funciona.

Alguém poderia me explicar isso, por favor?

Como essa pergunta criou alguma controvérsia, permita-me começar esta resposta com meu histórico: além de ser exposto à V&V no trabalho diário do projeto, trabalhei por vários anos no departamento de engenharia de software da minha alma mater e sou professor de engenharia de software. Embora isso não garanta que tudo o que digo esteja correto, espero que pelo menos me dê o benefício da dúvida de que possa haver alguma verdade nessa resposta.

Deixe-me assegurar-lhe que você não está tão confuso quanto pode acreditar. O que você declarou em sua pergunta é tão verdadeiro quanto enganoso. Deixe-me primeiro salientar o que você afirmou corretamente:

• Verificação = construir o produto certo vs validação = construir o produto certo
• As técnicas estáticas fazem parte da verificação - principalmente porque elas pegam seu programa e algumas informações formais derivadas dos requisitos e as avaliam umas contra as outras.
• A verificação garante a implementação correta dos requisitos (ou seja, você a criou da maneira correta)

Agora, deixe-me limpar a confusão sobre os testes . Primeiro, como muitos comentários afirmaram antes, o teste dinâmico de código por meio de testes automatizados (unidade, integração, ...) faz parte da verificação. O que causa a maior parte da confusão, no entanto, é que as pessoas na validação também falarão sobre testes , mas significam algo diferente: na validação, o teste geralmente envolve uma pessoa que usa o aplicativo para a finalidade a que se destina. No caso ideal, este é o próprio cliente.

No entanto, os "erros" [1] encontrados nos testes de verificação e validação diferem fundamentalmente:

• erros de teste de verificação: são erros que violam seus requisitos de uma maneira ou de outra.
• erros de teste de validação: são erros com o próprio produto que você construiu, não com a funcionalidade, portanto, eles revelam erros dentro dos requisitos.

Para a maioria das pessoas, é útil examinar exemplos concretos de diferentes casos de V&V. A seguir, exemplos extremos de erros:

• Você tem um requisito de baixo nível de que os estados "f (x) devem retornar x + 1" e sua implementação de "f" sempre retorna a constante 2. Você pode encontrar esse erro em várias abordagens de verificação diferentes, mas seu cliente provavelmente ganhou ' não o encontre durante a validação, porque você está criando um site de compras eletrônicas e ele não sabe nem se importa com "f".

• Você tem um requisito que declara "O sistema deve ser capaz de lidar com 1000 solicitações por segundo com uma carga de CPU máxima de 80%". Novamente, a validação terá dificuldades, tanto quanto a maioria das técnicas estáticas. De fato, a maneira mais simples de verificar isso é testar dinamicamente seu aplicativo, martelando-o com solicitações e monitorando a carga da CPU durante esse período.

• Considere o requisito acima para "f" mais uma vez, desta vez com uma implementação "correta". Todas as suas análises, análises estáticas e testes dinâmicos reportarão um sucesso, mas seu cliente testará seu software e informará que ele sente falta do ícone do carrinho de compras na página da web. Nenhuma quantidade de verificação poderá encontrar esse erro, como você o fez durante a fase de requisitos.

Como você pode ver, "testar" - se não for definido com mais precisão - faz parte da verificação e validação e, de fato, "testar" deve ser realizado para ambos.

[1] "erro" é usado coloquialmente aqui, para evitar a distinção entre erro, falha, erro, falha, ...

De fato: a verificação prova que você está criando o produto certo, enquanto a validação cria o produto certo.

Portanto

• A verificação está provando o processo ... de que você seguiu os padrões e procedimentos exigidos, geralmente verificados por análise estática e revisão de código.
• a validação está provando o produto resultante ... que o código faz o que é necessário, geralmente verificado por análise e teste dinâmicos, para mostrar que entradas especificadas resultam em saídas especificadas

Normalmente não cito a Wikipedia , mas, neste caso, é útil ...

Uma explicação mais detalhada dos dois processos pode ser encontrada nos Processos do Ciclo de Vida do Software ISO 12207 (uma das outras respostas publica um link para uma cópia não controlada):

7.2.4.3.2 Tarefas de verificação

• Verificação de Requisitos
• Verificação de projeto
• Verificação de código
• Verificação de integração
• Verificação da documentação

7.2.5.3.2 Tarefas de validação

• Preparar Requisitos, Casos e Especificações de Teste
• Realizar os testes

Agora, a pergunta inicial perguntou por que a verificação não inclui testes. E, apesar de algumas das outras respostas, dos membros da P.SE de alta reputação, afirmo que esse não é o objetivo da atividade de verificação , mas da atividade de validação .

Algumas respostas sugerem que você precisa testar para verificar o código ou a integração. Não - essa atividade é provar a modularidade e as interfaces, etc., não a execução.

Em última análise, o que essa discussão mostra é que há muita confusão sobre o que é verificação e o que é validação , e isso não é ajudado pelo fato de o limite ser uma área cinzenta e definido de maneira ligeiramente diferente em diferentes padrões.

O importante é que ambas as partes de V&V sejam cobertas e, desde que seja esse o caso, semanticamente, não importa realmente se é V ou V ... apenas V e V.