# Teste de aceite de software: como validar a entrega

> Como fazer o teste de aceite de software na prática: critérios combinados antes, cenários reais, usuários-chave e pendências registradas para aprovar a entrega.

Fonte: https://pervian.tech/blog/teste-de-aceite-de-software · Pervian Tech · publicado em 2026-10-01

O fornecedor avisa na sexta à tarde que a versão está pronta para validação. Na segunda, o gerente abre o sistema, cadastra um cliente de teste, emite um pedido, acha tudo bonito e responde "aprovado". Três semanas depois de entrar em produção, o faturamento descobre que pedido com frete por conta do cliente não calcula o imposto certo, e o comercial reclama que o desconto por volume não aparece no app do vendedor.

Nada disso era impossível de pegar antes. O problema é que o **teste de aceite** foi feito como uma visita guiada, e não como uma verificação. Ninguém combinou o que precisava funcionar, ninguém testou os casos que realmente acontecem na empresa e quem usa o sistema todo dia não participou.

Em resumo: teste de aceite de software é a etapa em que a empresa contratante confere, com casos reais da própria operação, se o sistema entregue cumpre o que foi combinado, antes de aprová-lo e colocá-lo em produção. Este texto mostra como conduzir esse aceite do lado do cliente: o que definir antes do desenvolvimento, como montar cenários reais, quem chamar, como registrar problemas de forma útil e como decidir entre aprovar, aprovar com pendências ou devolver.

## O que é teste de aceite, em uma frase

Teste de aceite é a verificação, feita pelo cliente, de que o sistema entregue cumpre o que foi combinado, usando situações reais do negócio e critérios definidos antes do desenvolvimento. Também é chamado de homologação ou UAT (do inglês *user acceptance testing*).

Ele não substitui os [testes que o fornecedor faz internamente](https://pervian.tech/blog/testes-automatizados-para-gestores). A equipe técnica testa se o código funciona; o aceite confirma se o sistema resolve o problema da empresa. São perguntas diferentes, e só quem conhece a operação responde a segunda.

## Por que o aceite costuma ser feito às pressas

Quase sempre pelos mesmos motivos:

- **Não há tempo reservado.** O cronograma tem semanas de desenvolvimento e "validação do cliente" num único dia, encaixado entre outras reuniões.
- **Ninguém sabe o que testar.** Sem critérios escritos, a pessoa navega pelas telas e aprova o que parece certo.
- **Quem testa não é quem usa.** O diretor valida; o faturista, que conhece as exceções, fica de fora.
- **Os dados de teste são irreais.** Cliente "Teste 1", produto "Produto A", pedido com um item. Nenhum dos casos complicados aparece.
- **Existe pressão para entrar em produção.** A data foi prometida a alguém, e devolver a entrega parece atrasar tudo.

O resultado é que os problemas aparecem em produção, com cliente real, nota real e estoque real. Corrigir ali custa mais e expõe a empresa.

## Critérios de aceite definidos antes do desenvolvimento

O aceite começa muito antes da entrega. Cada funcionalidade combinada deve ter, por escrito, os **critérios que dizem quando ela está pronta**. Isso faz parte da definição de escopo, e é uma das razões pelas quais vale a pena fazer um [discovery de software](https://pervian.tech/blog/discovery-de-software) antes de começar a construir.

Critério bom é verificável. Compare:

| Critério vago | Critério verificável |
|---|---|
| O sistema deve calcular o frete corretamente | Pedido para outro estado com frete por conta do cliente mostra o valor do frete separado e não soma esse valor à base do desconto |
| O relatório de vendas deve ser rápido | O relatório do mês corrente, filtrado por vendedor, abre sem travar a tela de quem está emitindo pedido |
| O app deve funcionar offline | O vendedor registra um pedido sem sinal, e o pedido chega ao sistema central quando a conexão volta, sem duplicar |
| A aprovação de compras deve seguir a alçada | Compra acima do limite do comprador fica pendente até o gerente aprovar, e o comprador vê o motivo da pendência |

Um formato simples, que funciona bem com gestores, é o **"dado, quando, então"**:

- **Dado** um cliente com limite de crédito estourado,
- **quando** o vendedor tentar fechar um pedido a prazo,
- **então** o sistema bloqueia o fechamento e indica quem pode liberar.

Com critérios assim, a discussão na entrega deixa de ser "eu achei que ia ser diferente" e passa a ser "este critério foi atendido ou não". Isso protege os dois lados.

Se o projeto é um primeiro lançamento enxuto, os critérios também ajudam a separar o que é essencial do que pode esperar. O raciocínio é o mesmo de [definir o escopo de um MVP](https://pervian.tech/blog/como-definir-o-escopo-de-um-mvp): o que não tem critério combinado provavelmente não entrou no escopo.

## Cenários reais do dia a dia

Critério diz o que precisa funcionar. Cenário diz **como você vai provar isso**, com uma situação que acontece de verdade na empresa.

Um bom roteiro de aceite mistura três tipos de cenário:

**O caminho comum.** O pedido padrão do cliente mais frequente, com o produto mais vendido e a condição de pagamento mais usada. Se isso não funciona, nada mais importa.

**As exceções que acontecem toda semana.** Devolução parcial, pedido com item sem estoque, cliente com cadastro incompleto, venda com desconto acima da alçada, nota que precisa ser cancelada. É aqui que a maior parte dos problemas aparece.

**Os casos raros, mas caros.** Fechamento de mês, virada de ano, reajuste de tabela de preço, troca de transportadora, integração fora do ar. Acontecem pouco, mas quando dão errado param a operação.

Algumas práticas que fazem diferença:

- **Use dados parecidos com os reais.** Clientes com nomes longos, endereços com complemento, produtos com variações, pedidos com muitos itens. Se possível, uma cópia anonimizada da base, respeitando a LGPD.
- **Teste o fluxo inteiro, não a tela.** Do pedido ao faturamento, à expedição e ao financeiro. Muitos erros estão na passagem de uma etapa para outra.
- **Inclua as integrações.** Se o sistema conversa com ERP, banco, transportadora ou e-commerce, o aceite precisa passar por elas, mesmo que em ambiente de teste.
- **Teste com o perfil de cada usuário.** Vendedor, gerente, financeiro e administrador enxergam coisas diferentes. Testar tudo com o usuário administrador esconde [problemas de permissão](https://pervian.tech/blog/controle-de-acesso-e-trilha-de-auditoria).
- **Teste no dispositivo real.** Se o app é usado no celular do vendedor, na rua, teste no celular do vendedor, na rua.

## Quem participa: usuários-chave e decisores

O aceite precisa de dois papéis distintos, e confundir os dois é uma das causas mais comuns de aceite fraco.

**Usuários-chave** são as pessoas que executam o processo no dia a dia: o faturista, o conferente, a analista de contas a receber, o vendedor externo. Eles conhecem as exceções e sabem dizer, em minutos, se algo está fora do lugar. São eles que executam os cenários.

**Decisores** são quem responde pelo resultado: o diretor, o gerente da área, o dono. Eles não precisam testar cada tela, mas precisam acompanhar o resultado, arbitrar conflitos ("o comercial quer assim, o financeiro quer assado") e assinar o aceite.

Na prática, funciona bem assim:

- **Um responsável pelo aceite do lado do cliente**, com autoridade para decidir e tempo reservado para isso.
- **Um ou dois usuários-chave por área afetada**, liberados de parte da rotina durante o período de testes.
- **Um ponto de contato do lado do fornecedor**, que responde dúvidas rapidamente e não deixa o cliente travado esperando.

Se a empresa não consegue liberar ninguém para testar, o aceite vira formalidade. É melhor ajustar o cronograma do que aprovar sem testar.

## Passo a passo para conduzir o aceite

Um roteiro que serve para a maioria das entregas, de um módulo novo a um sistema completo:

1. **Revise os critérios combinados.** Antes de receber a versão, releia o que foi acordado para aquela entrega. Se algo mudou no caminho, registre agora.
2. **Monte a lista de cenários.** Para cada critério, pelo menos um cenário comum e um de exceção. Escreva o passo a passo e o resultado esperado.
3. **Prepare os dados.** Cadastros, produtos, tabelas de preço e usuários com perfis reais no [ambiente de homologação](https://pervian.tech/blog/ambientes-de-homologacao-e-producao).
4. **Reserve o tempo das pessoas.** Na agenda, com horário definido. Teste "quando der" não acontece.
5. **Execute e registre tudo.** Cada cenário fica marcado como aprovado, reprovado ou bloqueado, com evidência.
6. **Classifique os problemas.** Bug, ajuste ou mudança de escopo, e o impacto de cada um (veja abaixo).
7. **Reteste o que foi corrigido.** E repita os cenários principais, porque uma correção pode ter afetado outra parte.
8. **Decida e formalize.** Aceite total, aceite parcial com pendências listadas ou devolução, por escrito.

## Registrando problemas de forma útil

"Não funciona" não ajuda ninguém. Um registro útil permite que o fornecedor reproduza o problema sem precisar de uma reunião. Cada pendência deve ter:

- **O que você fez**, passo a passo, a partir de qual tela.
- **Com quais dados**: qual cliente, qual produto, qual pedido.
- **O que aconteceu**: a mensagem de erro, o valor que apareceu, o comportamento observado.
- **O que você esperava**, de preferência citando o critério combinado.
- **Com qual usuário e em qual dispositivo** ou navegador.
- **Uma captura de tela ou gravação curta.**
- **O impacto**: impede a operação, atrapalha mas tem contorno, ou é cosmético.

Use um lugar só para registrar tudo: uma ferramenta de chamados, um quadro de tarefas ou até uma planilha compartilhada. O que não pode é pendência espalhada entre mensagens, e-mails e conversas de corredor. Ao final, essa lista é o documento que embasa a decisão de aceite.

## Bug, ajuste ou mudança de escopo

Nem todo problema encontrado no aceite é erro do fornecedor, e nem toda melhoria pedida é obrigação dele. Separar os três tipos evita atrito e torna a negociação objetiva.

| Tipo | O que é | Exemplo | Como costuma ser tratado |
|---|---|---|---|
| **Bug** | O sistema não cumpre um critério combinado | O desconto por volume não é aplicado no app, mas funciona no painel | Correção pelo fornecedor, dentro da entrega |
| **Ajuste** | O critério foi atendido, mas um detalhe atrapalha o uso | O campo de observação é pequeno demais para o que o faturamento escreve | Negociado; costuma entrar se for pequeno e não mexer em regra |
| **Mudança de escopo** | Algo que não foi combinado | "Agora queremos que o pedido também gere a ordem de produção" | Vai para a lista de melhorias e é estimado como trabalho novo |

A linha entre os três fica clara quando os critérios de aceite estão escritos. Sem eles, tudo vira discussão de interpretação.

Mudança de escopo não é ruim. É normal que, ao usar o sistema, a equipe descubra o que realmente precisa. Isso só precisa entrar pelo caminho certo, priorizado junto com o resto, e não como "correção" sem prazo. Depois da entrada em produção, esse fluxo de melhorias contínuas é o que chamamos de [manutenção evolutiva de software](https://pervian.tech/blog/manutencao-evolutiva-de-software).

## Aceite parcial e entrada em produção

Exigir zero pendência para aprovar costuma ser irreal, e aprovar com pendências graves é arriscado. O meio-termo é o **aceite parcial**, com regras claras.

Critérios úteis para decidir:

- **Pendências que impedem a operação bloqueiam a entrada em produção.** Pedido que não fatura, nota com imposto errado, perda de dado, falha de permissão que expõe informação sensível.
- **Pendências com contorno podem ir para produção com prazo de correção definido.** O relatório que sai com a ordem errada, mas com os números certos.
- **Pendências cosméticas entram na fila normal.** Texto de botão, alinhamento, cor.

O aceite parcial precisa ser **formalizado por escrito**: o que foi aprovado, quais pendências ficam abertas, a classificação de cada uma e o prazo combinado para resolver. Isso evita que uma pendência importante seja esquecida depois que o projeto "acabou".

Para a entrada em produção, combine também:

- **Como os [dados serão migrados](https://pervian.tech/blog/migracao-de-dados-entre-sistemas)** e quem confere se chegaram certos.
- **Se haverá período com o sistema antigo e o novo em paralelo**, e por quanto tempo.
- **Como voltar atrás** se algo grave aparecer nos primeiros dias.
- **Quem dá suporte** à operação na primeira semana, com tempo de resposta acordado.

Os primeiros dias em produção são, na prática, a última etapa do aceite. É comum aparecer algo que nenhum cenário previu, e o importante é que exista um caminho rápido para tratar.

## Checklist rápido do teste de aceite

- Cada funcionalidade entregue tem critérios de aceite escritos?
- Existe uma lista de cenários com caminho comum, exceções e casos raros?
- O ambiente de homologação tem dados parecidos com os reais e usuários com perfis diferentes?
- As integrações foram testadas no fluxo completo?
- Usuários-chave de cada área têm tempo reservado na agenda?
- Há um responsável com autoridade para decidir o aceite?
- As pendências estão num único lugar, com passo a passo e evidência?
- Cada pendência está classificada como bug, ajuste ou mudança de escopo?
- A decisão de aceite, total ou parcial, está registrada por escrito?
- O plano de entrada em produção inclui migração, suporte e caminho de volta?

Se várias respostas forem "não", vale conversar com o fornecedor antes de receber a próxima versão, e não depois.

## Perguntas frequentes

### Qual a diferença entre teste de aceite e homologação?

Na prática, nenhuma: teste de aceite, homologação e UAT são nomes para a mesma etapa. Em todos os casos, a empresa contratante verifica, com situações reais do negócio e critérios combinados antes do desenvolvimento, se o sistema entregue cumpre o que foi acordado. Às vezes a palavra homologação também designa o ambiente separado onde esse teste acontece.

### Quanto tempo reservar para o teste de aceite de software?

Depende do tamanho da entrega, da quantidade de cenários e das integrações envolvidas, mas o teste de aceite nunca deve caber num único dia encaixado entre reuniões. O ideal é reservar tempo na agenda dos usuários-chave, com folga para registrar pendências, receber as correções do fornecedor e retestar os cenários principais antes de decidir.

### Quem deve assinar o aceite de um sistema?

O aceite deve ser assinado por um decisor da empresa contratante, como o diretor ou o gerente da área, com autoridade para aprovar e tempo para acompanhar os testes. Os usuários-chave executam os cenários e registram as pendências, mas a decisão de aprovar, aprovar com pendências ou devolver a entrega cabe a quem responde pelo resultado.

### Posso aprovar um sistema com bugs pendentes?

Pode, desde que seja um aceite parcial formalizado por escrito. Pendências cosméticas ou com contorno podem ir para produção com prazo de correção combinado. Pendências que impedem a operação, como nota com imposto errado, perda de dados ou falha de permissão que expõe informação sensível, devem bloquear a entrada em produção até serem corrigidas.

## Como a Pervian Tech trabalha homologação com clientes

Na Pervian Tech, o aceite começa no diagnóstico. Ao definir o escopo, escrevemos com o cliente os critérios de cada funcionalidade em linguagem de negócio, e é com base neles que planejamos as entregas. Esse cuidado faz parte do nosso trabalho em [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software).

Cada entrega vai para um ambiente de homologação separado da produção, com um roteiro de cenários montado junto com os usuários-chave e um canal único para registrar pendências. Acompanhamos os testes de perto, classificamos cada ponto com o cliente e só combinamos a entrada em produção quando os critérios essenciais estão atendidos e o plano de virada está claro.

Cada projeto é sob medida, e o investimento é definido sob consulta depois de um diagnóstico inicial gratuito. Se você está para receber um sistema e não sabe bem como validar, ou se já aprovou uma entrega e se arrependeu, [conte como foi](https://pervian.tech/#contato).