Uma feature de busca que retorna resultados em 3 segundos passa na verificação: atende ao requisito. Falha na validação: os usuários a comparam com os 0,3 segundos do Google e acham inaceitavelmente lenta, mesmo que a spec nunca tenha dito o contrário.

As definições diretas

Verificação checa se o produto está em conformidade com suas especificações. Ele corresponde ao que foi documentado, projetado e acordado? Validação checa se o produto atende às necessidades reais do usuário. Ele resolve o problema real para o qual foi construído?

Um produto pode passar na verificação mas falhar na validação: funciona exatamente conforme especificado, mas a especificação estava errada e não faz o que os usuários realmente precisam.

O inverso também existe: um produto pode passar na validação mas falhar na verificação. Os usuários adoram e funciona bem, mas tem funcionalidades não documentadas, brechas de segurança ou comportamentos que diferem da spec.

Verificação: corresponde à spec

As atividades de verificação geralmente são feitas sem executar o software. A pergunta é: o que construímos corresponde ao que foi acordado?

Como a verificação se parece

Revisão de documentos
  • O documento de requisitos cobre todas as features acordadas?
  • A spec de design é consistente com os requisitos?
  • Os casos de teste cobrem todos os requisitos?
Revisão de código
  • O código implementa o que o documento de design diz?
  • Os padrões de segurança dos coding standards estão presentes?
Inspeção
  • Percorra os requisitos, o design e a implementação juntos. Tudo está alinhado?
Revisão de protótipo/wireframe
  • O wireframe da UI corresponde às user stories acordadas?

O objetivo

Encontrar defeitos em documentos e designs antes de o software ser construído ou testado. É mais barato corrigir um requisito errado no papel do que corrigi-lo após 3 sprints de desenvolvimento.

Validação: resolve o problema real

A validação é feita executando o software, geralmente por meio de testes reais. A pergunta é: este produto funciona para as pessoas para quem foi construído?

Como a validação se parece

Teste de aceitação do usuário (UAT)
  • Usuários reais ou stakeholders testam o software contra seus fluxos de trabalho reais
  • "Isso faz o que eu precisava que fizesse?"
Testes de sistema
  • Testa o sistema completo e integrado contra os requisitos, mas também contra os objetivos dos usuários
  • O produto todo funciona de ponta a ponta para casos de uso realistas?
Teste beta
  • Um subconjunto de usuários reais usa o produto em seu ambiente real
  • Descobre lacunas que o teste baseado em spec perdeu porque a spec não capturou o uso real
Teste de usabilidade
  • Os usuários conseguem realmente atingir seus objetivos com essa interface?
  • Mesmo que tecnicamente correto, é usável?

O objetivo

Confirmar que o software entrega valor real. Uma feature pode ser tecnicamente correta e completamente inútil.

Um exemplo concreto

Imagine um requisito:

"O campo de busca deve retornar resultados em até 3 segundos."
Pergunta de verificação: a implementação corresponde a esse requisito? Testamos: executamos uma busca, medimos o tempo, confirmamos que é menos de 3 segundos. Passou. Pergunta de validação: isso resolve o problema real do usuário? Descobrimos: os usuários estão buscando em catálogos enormes de produtos e 3 segundos parece inaceitavelmente lento quando o Google retorna resultados em 0,3 segundos. Mesmo que a spec dissesse 3 segundos e o código atenda a isso, a validação falha.

A especificação estava errada. A verificação não detectou nada. A validação detectou tudo.

Por isso você não pode confiar apenas na verificação: a spec é tão boa quanto as pessoas que a escreveram.

Outro exemplo: validação de formulário

Requisito: "O campo de senha não deve aceitar menos de 8 caracteres."

Verificação: teste que uma senha de 7 caracteres é rejeitada. É. Validação: um usuário real tenta usar sua senha habitual de 6 caracteres e é rejeitado. Tenta criar uma nova de 8 caracteres, mas a mensagem de erro diz apenas "Entrada inválida" sem nenhuma explicação. Ele desiste e não se cadastra. A validação falha: o produto não ajuda os usuários a atingir o objetivo de se registrar.

O código estava correto. O requisito era estreito demais. Não levou em conta a experiência do usuário com a mensagem de erro.

Como aparecem no ciclo de desenvolvimento

| Fase | Atividade | Verificação ou validação? |

|------|-----------|--------------------------|

| Requisitos | Revisão de requisitos: verificação de completude e consistência | Verificação |

| Design | Walkthrough de design: verificação se o design corresponde aos requisitos | Verificação |

| Desenvolvimento | Revisão de código: verificação se o código corresponde ao design | Verificação |

| Testes | Testes unitários: verificação se os componentes funcionam conforme especificado | Verificação |

| Testes | Testes de integração: verificação se os módulos funcionam juntos | Verificação |

| Testes | Testes de sistema: verificação se o sistema completo atende aos requisitos | Ambos |

| Testes | UAT: verificação se usuários reais conseguem atingir objetivos reais | Validação |

| Release | Teste beta: uso no mundo real | Validação |

A maior parte do que engenheiros de QA fazem no dia a dia é uma mistura dos dois. Você executa testes contra requisitos (verificação) enquanto também pensa se a feature realmente funciona para usuários reais (validação).

Por que essa distinção importa

Bugs de falhas de verificação: a implementação não corresponde à spec. Um botão não faz o que o requisito diz que deveria. Um cálculo está errado. Um campo aceita valores que não deveria. Bugs de falhas de validação: a spec estava incompleta ou incorreta. A feature funciona conforme projetada mas falha em cenários reais de uso. Mensagens de erro faltando, fluxos confusos, desempenho tecnicamente aceitável mas praticamente terrível.

Um bom QA detecta os dois. Execução pura de testes baseados em spec detecta falhas de verificação. Testes exploratórios, revisões de usabilidade e UAT detectam falhas de validação.

A versão para entrevista

Se cair em uma entrevista:

Verificação = "Estamos construindo o produto corretamente?" Conformidade com especificações, tipicamente estática (revisões, walkthroughs) ou testes de fase inicial contra requisitos documentados. Validação = "Estamos construindo o produto certo?" Confirmação de que o software atende às necessidades dos usuários, tipicamente executando o software em condições realistas (UAT, teste beta, teste de usabilidade).

A analogia clássica: um mapa pode ser preciso (verificação: ele retrata corretamente o terreno) mas inútil (validação: ele mostra o destino errado). Você precisa de um mapa correto e do destino certo.

Os dois conceitos são relevantes para o trabalho de todo engenheiro de QA, mesmo que você nunca use os termos explicitamente. Sempre que você verifica "isso corresponde ao requisito", está fazendo verificação. Sempre que pergunta "isso realmente funciona para um usuário real", está fazendo validação. Os melhores testers mantêm as duas perguntas rodando simultaneamente.

→ Veja também: Testes Caixa-Preta vs Caixa-Branca: Um Guia Claro para Engenheiros QA | Testes de Aceitação: O que São, Quem os Faz e Como | O que é Teste Manual? O Guia Completo para 2026