Verificação vs validação: a pergunta que quase ninguém sabe responder

Uma equipe encerra o sprint, roda a suíte completa, tudo passa em verde. Fazem o deploy com confiança. Uma semana depois o cliente escreve: "isto não é o que pedimos". Ninguém mentiu. O software faz exatamente o que o código diz, e o código faz exatamente o que o ticket dizia. O problema é que o ticket estava errado desde o começo. Essa equipe verificou de forma impecável. O que nunca fez foi validar.

Verificação e validação são as duas perguntas que sustentam toda a qualidade de software, e são confundidas o tempo todo. Resumem-se numa frase que vale a pena memorizar: verificação pergunta "estamos construindo o produto do jeito certo?"; validação pergunta "estamos construindo o produto certo?". Soam quase iguais. Não são. E entender a diferença é o que explica por que o QA de verdade começa no documento de requisitos, não no editor de código.

01 · as duas perguntasConstruir bem não é o mesmo que construir o que é certo

A distinção é fácil de enunciar e difícil de viver. Verificação comprova que o produto cumpre suas especificações: que o que você construiu coincide com o que estava escrito que você devia construir. Validação comprova que essas especificações eram as adequadas: que o produto resolve a necessidade real do usuário. A primeira olha para dentro, contra o documento. A segunda olha para fora, contra a realidade.

A ISO/IEC/IEEE 29119, o padrão internacional de testes de software, separa as duas com cuidado. Verificação é a confirmação, por meio de evidência objetiva, de que os requisitos especificados foram cumpridos. Validação é a confirmação de que os requisitos para um uso pretendido concreto foram cumpridos [1]. Repare na nuance: num caso o juiz é a especificação; no outro, o uso real.

Verificação diz se você seguiu a planta. Validação diz se a planta servia para alguma coisa.

Um exemplo doméstico aterrissa a ideia. Alguém pede uma escada para alcançar o telhado. O carpinteiro a constrói com medidas perfeitas, madeira sólida, degraus uniformes: verificação aprovada, a escada cumpre a planta. Mas o telhado estava a cinco metros e a escada mede três. Validação falhou: construiu-se bem um objeto que não resolve o problema. Nenhum teste de resistência teria detectado isso, porque o defeito não está na construção e sim no que se decidiu construir.

02 · onde vive cada umaA verificação é interna; a validação olha para o usuário

Como as duas perguntas apontam para juízes distintos, são exercidas com técnicas distintas e em momentos distintos do ciclo. Confundi-las faz uma equipe acreditar que está coberta quando cobriu apenas a metade.

A verificação costuma ser estática e precoce. Revisões de requisitos, revisões de design, inspeções de código, análise estática, testes unitários e de integração: tudo isso comprova, sem precisar de um usuário final, que cada peça cumpre o que sua especificação pedia. É barata e feita de forma contínua, porque cada artefato (a spec, o design, o módulo) pode ser contrastado com o anterior assim que existe.

A validação costuma ser dinâmica e tardia. Testes de sistema contra os cenários reais, testes de aceitação com o cliente, betas, demos com usuários de verdade. Aqui já não basta ler um documento: é preciso executar o produto em condições parecidas com as de seu uso real e observar se de fato resolve a necessidade. Por isso a validação não pode ser totalmente "antecipada"; precisa de algo funcionando e de alguém real diante disso.

Daqui sai uma consequência prática incômoda. Você pode ter uma cobertura de testes de cem por cento e um produto errado. A cobertura mede verificação: quanto do código você exercita. Não diz nada sobre se esse código resolvia o problema certo. Por isso "todos os testes passam" nunca deveria ser confundido com "o produto está pronto".

03 · por que o QA começa na specO defeito mais caro nasce antes de escrever código

Se a validação pergunta se construímos o que é certo, então o momento mais rentável para fazer essa pergunta é antes de construir. E é aí que verificação e validação se dão as mãos num ponto que quase ninguém olha: o documento de requisitos.

Um requisito pode ser verificado (está bem escrito, é claro, é testável, não se contradiz com outro?) e pode ser validado (este requisito, mesmo que esteja perfeitamente redigido, é de verdade o que o usuário precisa?). Quando uma equipe revisa a spec com as duas perguntas em mãos, captura o erro mais caro de todos: o requisito errado. Porque esse erro, se sobrevive à spec, se propaga ao design, ao código e aos testes, e quando alguém o percebe numa demo já custou semanas de trabalho bem feito sobre uma base ruim.

Os dados clássicos da engenharia de software apontam sempre na mesma direção: quanto mais tarde um defeito é detectado, mais custa corrigi-lo, e um defeito introduzido nos requisitos e descoberto em produção pode custar ordens de magnitude a mais do que se tivesse sido capturado na fase de requisitos [2]. Um requisito ambíguo revisado a tempo se corrige com uma conversa. O mesmo requisito descoberto depois do lançamento se corrige com um redesenho.

Nada disso tira valor da verificação. Um produto que resolve o problema certo mas está mal construído também não serve: cai, é inseguro, é impossível de manter. A lição não é escolher uma pergunta em vez da outra, é que você precisa das duas e que elas falham de maneiras distintas. A verificação protege você de construir mal. A validação protege você de construir o que não era. Uma equipe que só verifica entrega software impecável que não serve para ninguém; uma que só valida entrega boas ideias mal feitas.

Na próxima vez que alguém disser "já passamos em todos os testes", vale a pena perguntar qual das duas coisas foi testada. Se só se comprovou que o código cumpre a spec, verificou-se. Se a spec era a certa continua sendo uma pergunta em aberto, e é quase sempre a mais importante.