Uma equipe pode construir um software que corresponde perfeitamente à sua especificação e ainda assim entregar o produto errado. Eles também podem construir exatamente o produto certo sobre um código repleto de defeitos. Essas duas falhas têm nomes: a primeira é um problema de verificação, a segunda é um problema de validação. Confundir as duas é como os processos de qualidade acabam ocupados, mas ineficazes.
Este guia define ambos os termos, apresenta as diferenças e mostra onde cada um se encaixa em um fluxo de trabalho de teste de API com Apidog.
O que é verificação?
A verificação pergunta: estamos construindo o produto certo?
Ela verifica se uma parte do software está em conformidade com sua especificação, seu design e seus padrões. A verificação compara o trabalho com a intenção documentada. Não pergunta se essa intenção estava correta; apenas pergunta se a implementação corresponde a ela.
A verificação acontece continuamente, ao longo do desenvolvimento, não no final. As atividades típicas de verificação incluem:
- Revisões de código e walkthroughs
- Análise estática e linting
- Revisões de design e arquitetura
- Verificações de esquema e contrato
- Testes unitários que confirmam que uma função faz o que sua assinatura promete
A principal característica é que a verificação é principalmente interna. Ela compara um artefato com outro artefato: código com design, resposta com esquema, implementação com especificação. Nenhum usuário real é necessário. Se a especificação diz que o endpoint retorna um 201 com um cabeçalho `Location`, a verificação confirma que ele faz exatamente isso.
O que é validação?
A validação pergunta: estamos construindo o produto certo?
Ela verifica se o software realmente atende às necessidades do usuário e resolve o problema real, independentemente do que a especificação disse. A validação compara o trabalho com a realidade e a intenção de uso, não com um documento.
A validação tende a acontecer mais tarde, uma vez que há algo que um usuário ou stakeholder pode exercitar. As atividades típicas de validação incluem:
- Testes de aceitação do usuário
- Programas beta e testes de usabilidade
- Testes de ponta a ponta de fluxos de trabalho completos
- Demonstrações e aprovação de stakeholders
A principal característica é que a validação é voltada para o exterior. Ela pergunta se o produto final é útil e correto no contexto. Uma API pode passar em todas as verificações, estar perfeitamente em conformidade com sua especificação OpenAPI, e ainda assim falhar na validação porque a própria especificação resolveu o problema errado; o modelo de paginação é inutilizável, ou o fluxo de autenticação não se encaixa em como os clientes realmente se integram.
Validação vs verificação: as diferenças
| Dimensão | Verificação | Validação |
|---|---|---|
| Pergunta central | Estamos construindo certo? | Estamos construindo a coisa certa? |
| Compara com | Especificação, design, padrões | Necessidades do usuário, uso no mundo real |
| Momento | Contínuo, durante todo o desenvolvimento | Posterior, assim que algo é utilizável |
| Métodos típicos | Revisões, análise estática, testes unitários, verificações de esquema | Teste de aceitação, beta, ponta a ponta, demonstrações |
| Direção | Interna: artefato vs artefato | Externa: produto vs realidade |
| Detecta | Defeitos, desvios da especificação, descompasso de contrato | Requisitos errados, ajuste inadequado, lacunas de usabilidade |
| Custo de ignorar | Código com bugs que corresponde a uma boa especificação | Produto polido resolvendo o problema errado |
As duas não são intercambiáveis, e nenhuma substitui a outra. Uma verificação forte com validação fraca lhe dá um produto sem defeitos que ninguém quer. Uma validação forte com verificação fraca lhe dá a ideia certa implementada em código instável. Você precisa de ambas, aplicadas no momento certo.
Um mnemônico simples: verificação é testar contra o _documento_, validação é testar contra o _propósito_.
Como isso se manifesta nos testes de API
As APIs tornam a distinção concreta, porque uma API possui uma especificação explícita e legível por máquina: sua definição OpenAPI ou de esquema. Essa especificação é a linha de base para a verificação.
Verificação para uma API significa verificar a implementação em relação a esse contrato:
- Cada endpoint retorna os códigos de status documentados? Manter a consistência é uma disciplina por si só; veja quais códigos de status HTTP as APIs REST devem usar.
- Cada resposta corresponde ao esquema documentado, com os nomes e tipos de campo corretos?
- Os parâmetros obrigatórios são impostos exatamente como especificado?
- O formato de erro corresponde à forma de erro documentada?
É também aqui que reside o teste de contrato de API. Um teste de contrato é pura verificação: ele confirma que o produtor ainda honra o acordo do qual os consumidores dependem. As asserções de API sobre status, esquema e cabeçalhos são a unidade de trabalho de verificação.
Validação para uma API significa verificar se a API realmente atende aos seus consumidores:
- Um cliente pode completar um fluxo de trabalho real de ponta a ponta, fazer login, criar, atualizar, excluir, sem soluções alternativas complicadas?
- Os dados que a API retorna realmente respondem às perguntas que os desenvolvedores clientes fazem?
- O modelo de autenticação é prático para as integrações existentes?
- Os exemplos documentados refletem como a API é realmente usada?
Um cenário de teste de API que encadeia várias requisições em uma jornada de usuário completa está mais próximo da validação; uma verificação de esquema de um único endpoint é verificação. Ambos pertencem à suíte. Entender cenários de teste vs casos de teste ajuda você a ver em qual camada você está trabalhando.
Onde o Apidog se encaixa
Apidog suporta ambos os lados da distinção porque mantém o design, teste e documentação da API em um único espaço de trabalho.
Para verificação, o design da API _é_ a especificação. Ao construir um teste, você faz asserções de respostas contra o mesmo esquema que define a API, para que a verificação não tenha uma segunda cópia do contrato para se desviar. Asserções de esquema, asserções de status e verificações de contrato são executadas contra a fonte da verdade. Execute-as em cada commit através de CI; automatizar testes de API em CI/CD torna a verificação contínua, que é exatamente quando ela deve acontecer.
Para validação, os cenários de teste do Apidog encadeiam múltiplos endpoints em fluxos de trabalho completos. Você pode construir um cenário que registra um usuário, faz login, cria um recurso e confirma o resultado, então executá-lo da forma como um cliente real faria. Esse exercício de ponta a ponta é como você verifica se a API resolve o problema real, e não apenas se cada endpoint corresponde à sua linha na especificação.
O relatório fecha o ciclo. O Apidog gera resultados por etapa, de modo que uma verificação falha (uma incompatibilidade de esquema) e uma validação falha (um fluxo de trabalho multi-etapas quebrado) são ambas visíveis, distintas e rastreáveis.
Baixe o Apidog para configurar tanto a verificação em nível de contrato quanto a validação em nível de fluxo de trabalho contra sua própria API.
Um exemplo do mundo real
Imagine uma equipe construindo uma API de pagamentos. A especificação diz que `POST /payments` aceita um valor e uma moeda, retorna `201` com um `payment_id`, e rejeita moedas inválidas com um `400`.
A verificação nesta API ocorre sem problemas. A revisão de código confirma que o manipulador corresponde ao design. Asserções de esquema confirmam que cada resposta possui os campos e tipos documentados. Testes de contrato confirmam que a forma de erro `400` é exatamente como especificado. As verificações de código de status passam em todos os aspectos. Por toda medida de verificação, a API está construída corretamente.
Então o primeiro cliente real se integra. Eles descobrem que a API aceita um valor como um número de ponto flutuante, então `0.1 + 0.2` arredonda para um valor que não corresponde à fatura do cliente. A especificação dizia “amount: number.” A implementação a honrou perfeitamente. A especificação estava errada; dinheiro nunca deve ser um float. A verificação nunca poderia ter pego isso, porque a verificação apenas verifica a implementação contra a especificação, e ambas concordaram.
A validação captura isso. No momento em que um cliente executa um pagamento real de ponta a ponta e o reconcilia com uma fatura, o erro de arredondamento surge. A correção não é um relatório de defeito de código; é uma mudança de especificação, os valores se tornam unidades menores inteiras. Essa é a assinatura de um achado de validação: a resposta não é “corrigir o código para corresponder à especificação”, é “a própria especificação estava errada.”
É por isso que ambos importam. A verificação teria entregue uma implementação impecável de um contrato quebrado. A validação, exercitando a API da maneira que um consumidor real faria, é a única coisa que expõe o contrato como o problema.
Uma lista de verificação prática
Para qualquer lançamento de API, execute ambas as colunas:
Verificação (contra a especificação):
- Cada endpoint retorna os códigos de status documentados
- Cada resposta está em conformidade com seu esquema
- Parâmetros obrigatórios são impostos
- Respostas de erro correspondem à forma documentada
- Testes de contrato passam para todos os endpoints voltados ao consumidor
Validação (contra o propósito):
- Um novo cliente pode completar o fluxo de trabalho principal de ponta a ponta
- Os dados retornados respondem a perguntas reais do cliente
- O fluxo de autenticação funciona para padrões de integração reais
- Exemplos documentados correspondem ao uso real
- Os stakeholders confirmam que a API resolve o problema pretendido
Se apenas a primeira coluna passar, você tem uma implementação correta de um design possivelmente errado. Se apenas a segunda passar, você tem a ideia certa em código instável. Entregar com confiança significa ter ambos.
Perguntas frequentes
A verificação ou a validação é feita primeiro? A verificação começa primeiro e ocorre continuamente, já que você pode verificar o código contra uma especificação assim que o código existe. A validação vem depois que há um produto utilizável para exercitar contra as necessidades reais.
Teste é o mesmo que validação? Não. O teste abrange ambos. Testes unitários e verificações de esquema são verificação; testes de aceitação e de ponta a ponta são validação. O termo “teste” cobre toda a gama.
Um software pode passar na verificação, mas falhar na validação? Sim, e é comum. A implementação corresponde perfeitamente à especificação, mas a especificação resolveu o problema errado. Esse produto é verificado, mas não validado.
Como isso se aplica ao teste de contrato de API? O teste de contrato é verificação. Ele confirma que uma API ainda honra seu acordo documentado com os consumidores. Não confirma que esse acordo estava correto; esse é o trabalho da validação.
Qual deles encontra mais bugs? A verificação encontra mais defeitos em número, já que é executada continuamente e detecta pequenos desvios precocemente. A validação encontra menos problemas, mas mais caros, porque uma falha de validação geralmente significa que um requisito ou design estava errado, não apenas o código.
A automação pode cobrir ambos? A automação lida bem com a verificação: verificações de esquema, testes de contrato e asserções de status são executadas em cada commit. A validação é mais difícil de automatizar completamente porque depende do julgamento sobre o ajuste ao mundo real, embora testes de fluxo de trabalho de ponta a ponta automatizem uma parte significativa dela.