# Testes automatizados: importância e como cobrar do fornecedor

> Por que testes automatizados importam para quem paga o software: bugs que não voltam, entregas sem susto e perguntas para saber se o fornecedor testa.

Fonte: https://pervian.tech/blog/testes-automatizados-para-gestores · Pervian Tech · publicado em 2026-10-01

O fornecedor avisa que corrigiu o desconto progressivo no pedido. Duas semanas depois, numa entrega que mexia só no cadastro de clientes, o desconto volta a sair errado. O comercial descobre pela reclamação de um cliente, o financeiro refaz a conta à mão e alguém pergunta, com razão: "isso não tinha sido resolvido?".

Tinha. Mas nada impedia que voltasse. A correção foi conferida uma vez, por uma pessoa, clicando na tela. Na entrega seguinte ninguém conferiu de novo, porque ninguém imaginou que mexer no cadastro afetaria o desconto.

É exatamente esse buraco que **testes automatizados** fecham, e essa é a principal importância deles: cada regra verificada uma vez passa a ser verificada de novo, sozinha, em todas as alterações seguintes. Este texto explica, sem código, o que eles são, quais tipos importam para uma empresa, por que o número de cobertura engana e como um gestor verifica se o fornecedor testa de verdade ou só diz que testa.

## O que são testes automatizados, em uma frase

Teste automatizado é **um pequeno programa que verifica se outro programa faz o que deveria**, e que roda sozinho, sempre que alguém altera o sistema.

Em vez de uma pessoa abrir a tela, criar um pedido de dez caixas e conferir se o desconto saiu certo, existe um teste que monta esse pedido, calcula o desconto e compara com o resultado esperado. Ele roda em segundos, não se cansa, não esquece e não pula etapa na sexta-feira à tarde.

A importância está no efeito acumulado. Cada regra de negócio que ganha um teste passa a ser conferida em **todas as entregas futuras**, não só na entrega em que foi criada. O bug do desconto que volta é o sintoma clássico de um sistema sem essa rede de proteção.

Para o gestor, a resposta curta à pergunta "por que pedir testes automatizados?" é:

- **Bugs corrigidos não voltam**, porque cada correção vem acompanhada de um teste que reprova o erro antigo.
- **Mudanças ficam mais baratas**, porque a equipe sabe na hora se quebrou algo em outro canto.
- **Entregas ficam mais frequentes e menos tensas**, sem precisar de janela especial e plantão.
- **O conhecimento sobre as regras fica registrado** em algo que é executado, não em uma pessoa que pode sair da empresa.
- **[Trocar de fornecedor](https://pervian.tech/blog/trocar-de-fornecedor-de-software) fica menos arriscado**, porque quem assume tem como confirmar que não quebrou o que já funcionava.

## Teste manual x teste automatizado

Teste manual não é ruim, e não vai deixar de existir. O problema é usá-lo para tudo.

| Aspecto | Teste manual | Teste automatizado |
|---|---|---|
| Quem executa | Uma pessoa, seguindo um roteiro ou de memória | O próprio sistema, a cada alteração |
| Tempo para rodar | Minutos a horas, conforme o tamanho do roteiro | Segundos a poucos minutos, na maioria dos casos |
| Repetição | Cansa, e por isso é pulado | Roda igual todas as vezes |
| Melhor uso | Avaliar usabilidade, explorar cenários novos, [validar com o usuário](https://pervian.tech/blog/teste-de-aceite-de-software) | Garantir que regras já conhecidas continuam funcionando |
| Custo ao longo do tempo | Cresce a cada funcionalidade nova | Escrito uma vez, mantido junto com o código |

A regra prática: **o que precisa ser verificado sempre deve ser automatizado; o que exige julgamento humano fica com pessoas.** Saber se uma tela está confusa é trabalho para gente. Saber se o imposto continua sendo calculado do mesmo jeito depois de uma alteração é trabalho para máquina.

## Testes de unidade, integração e ponta a ponta

Existem muitos nomes no mercado, mas três tipos cobrem quase tudo o que um gestor precisa entender.

### Testes de unidade

Verificam **uma regra isolada**. Por exemplo: dado um pedido de determinado valor, para um cliente de determinada categoria, o desconto é tal. Não abrem tela, não acessam banco de dados, não chamam outro sistema. Por isso são muito rápidos e dá para ter centenas deles.

São o lugar certo para cálculos: frete, comissão, juros de atraso, rateio de custo, prazo de entrega, regras de aprovação.

### Testes de integração

Verificam **se as partes conversam direito**: o sistema grava e lê do banco de dados corretamente, o módulo de pedidos chama o de estoque do jeito certo, a resposta de uma API externa é interpretada como deveria.

São mais lentos que os de unidade, e é aqui que aparecem problemas que só existem na junção: um campo que mudou de nome, uma data em formato diferente, um valor que chega como texto em vez de número.

### Testes de ponta a ponta

Simulam **um usuário de verdade** usando o sistema: abrem o navegador, fazem login, montam um pedido, finalizam e conferem o resultado. São os mais próximos da realidade e também os mais lentos e frágeis, porque qualquer mudança visual pode exigir ajuste.

Por isso são reservados para os fluxos que não podem falhar de jeito nenhum: fechar pedido, emitir cobrança, fazer login, gerar o arquivo que vai para o banco.

### A proporção saudável

A imagem usada por engenheiros é uma pirâmide: **muitos testes de unidade na base, uma quantidade média de testes de integração no meio e poucos testes de ponta a ponta no topo.** Quando a pirâmide está invertida, com quase tudo testado pela tela, a suíte fica lenta, quebra por motivos bobos e a equipe para de confiar nela.

## Onde testar primeiro: regras que mexem com dinheiro

Ninguém precisa testar tudo de uma vez, e um sistema existente sem testes não vai ganhar cobertura completa em um ciclo. A pergunta certa é: **onde um erro custa mais caro?**

Uma ordem de prioridade que funciona para a maioria das empresas:

1. **Cálculos financeiros.** Preço, desconto, imposto, juros, multa, comissão, parcelamento, rateio. Erro aqui vira prejuízo, cobrança indevida ou problema fiscal.
2. **Integrações com bancos, ERP, gateways de pagamento e órgãos públicos.** Um arquivo de remessa malformado ou uma nota rejeitada param a operação.
3. **Regras de permissão e acesso.** Quem pode aprovar, quem vê o dado de quem. Erro aqui é risco de segurança e de LGPD.
4. **Fluxos de maior volume.** O que é executado centenas de vezes por dia amplifica qualquer erro.
5. **Áreas que mais quebram.** O histórico de chamados mostra onde estão os bugs recorrentes. Cada um deles deve ganhar um teste quando for corrigido.

O resto, como telas administrativas pouco usadas e relatórios de consulta, entra depois, ou só quando for alterado.

## Cobertura de testes: o número engana

**Cobertura** é a proporção do código que é executada quando os testes rodam. As ferramentas calculam esse número automaticamente, e por isso ele vira meta em contrato com facilidade. É aí que começa o problema.

O número mede se o código **passou** pelo teste, não se o teste **verificou** alguma coisa. É possível escrever testes que executam o sistema inteiro sem conferir nenhum resultado, e a cobertura sai altíssima. Também é possível ter cobertura modesta concentrada exatamente nas regras que importam, o que vale muito mais.

Como usar a cobertura sem ser enganado:

- **Olhe a cobertura por área, não a média geral.** O módulo de cálculo financeiro deve estar bem coberto; uma tela de configuração rara pode estar pouco coberta sem drama.
- **Acompanhe a tendência.** Cobertura caindo a cada entrega indica que código novo está entrando sem teste.
- **Não transforme em meta rígida.** Quando o número vira meta, a equipe otimiza o número, não a qualidade. Um percentual fixo exigido em contrato tende a gerar testes de enfeite.
- **Pergunte pelos testes das regras críticas pelo nome.** "Mostre o teste que garante o cálculo da comissão" diz mais do que qualquer porcentagem.

Uma cobertura razoável, portanto, não é um número. É **ter as regras que mexem com dinheiro, acesso e integrações protegidas, e o restante crescendo à medida que o sistema é alterado.**

## Como verificar se o fornecedor testa

Quase todo fornecedor diz que testa. A diferença está entre "alguém clica antes de publicar" e "existe uma suíte automatizada que roda a cada alteração e bloqueia a publicação se falhar". O gestor consegue distinguir uma coisa da outra sem ler código.

### Perguntas para fazer

- **"Os testes rodam sozinhos a cada alteração?"** A resposta certa envolve uma [esteira de integração contínua](https://pervian.tech/blog/ci-cd-para-gestores) (o chamado pipeline de CI), que executa os testes automaticamente quando alguém envia código.
- **"Se um teste falhar, o que acontece?"** A resposta certa é: a alteração não segue para produção até ser corrigida. Se a resposta for "a gente avalia", o teste é decorativo.
- **"Quando vocês corrigem um bug, criam um teste para ele?"** Deve ser regra, não exceção.
- **"Quais são as regras críticas do meu sistema e onde estão os testes delas?"** O fornecedor deve saber responder sem precisar procurar.
- **"Quanto tempo a suíte leva para rodar?"** Se leva horas, ninguém roda. O ideal é que a parte principal rode em poucos minutos.

### Evidências para pedir

- **Acesso de leitura ao repositório de código**, algo que convém garantir em contrato (veja [propriedade do código-fonte no contrato](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato)). Lá dá para ver se existe uma pasta de testes e se ela cresce junto com o resto.
- **O histórico do pipeline**: uma tela que mostra cada execução, com aprovado ou reprovado. Um histórico só de aprovações, sem nenhuma falha em meses, merece uma pergunta: ou os testes são fracos, ou não estão rodando.
- **O relatório de cobertura por módulo**, lido com os cuidados da seção anterior.
- **Testes descritos em linguagem de negócio.** Nomes como "calcula desconto progressivo para cliente atacado" mostram que a equipe testa regras, não apenas código.

### Sinais de alerta

- Bugs já corrigidos que voltam.
- Publicações que só acontecem à noite, com alguém de plantão "para garantir".
- Medo de atualizar bibliotecas e frameworks.
- Estimativas que incluem uma fase longa de "teste manual" no final de cada entrega.
- Respostas vagas como "a gente testa bastante" sem nada para mostrar.

Esses critérios valem tanto para o fornecedor atual quanto para a escolha de um novo. Eles complementam a lista de [como escolher uma software house](https://pervian.tech/blog/como-escolher-uma-software-house), e vale fazer as perguntas ainda na fase de proposta.

## Testes e velocidade de entrega

A objeção mais comum é: "escrever teste atrasa a entrega". Na funcionalidade em que o teste é escrito, há um tempo a mais de trabalho. Nas alterações seguintes, esse tempo tende a voltar, porque a conferência deixa de ser manual.

Sem testes, cada alteração exige que alguém confira manualmente o que pode ter sido afetado. Como o sistema cresce, essa conferência cresce junto, até que a equipe passa mais tempo verificando do que construindo. Ou, pior, deixa de verificar e os bugs chegam ao cliente.

Com testes, a conferência é automática e cabe em minutos. A equipe pode publicar com mais frequência, em lotes menores, e cada publicação carrega menos risco. É essa combinação que permite entregar toda semana sem susto.

Sistemas sem testes acumulam o que se chama de [dívida técnica](https://pervian.tech/blog/divida-tecnica-explicada-para-gestores): cada atalho torna a próxima mudança mais lenta e mais arriscada. Teste automatizado é uma das formas mais diretas de pagar essa dívida, e é também o que torna viável a [manutenção evolutiva](https://pervian.tech/blog/manutencao-evolutiva-de-software) de um sistema por anos, sem que cada ajuste vire uma aposta.

## Checklist para a próxima reunião com o fornecedor

- Existe suíte de testes automatizados, e ela roda a cada alteração?
- Uma falha nos testes bloqueia a publicação?
- As regras de preço, imposto, comissão e cobrança têm testes próprios?
- As integrações com banco, ERP e pagamento têm testes?
- Todo bug corrigido ganha um teste que impede a volta?
- Temos acesso ao repositório e ao histórico do pipeline?
- A cobertura das áreas críticas está estável ou crescendo?
- A suíte principal roda em poucos minutos?

Se a maioria das respostas for "não" ou "não sei", o próximo passo não é exigir uma porcentagem em contrato. É mapear as regras críticas e começar a protegê-las uma a uma, a partir da próxima alteração em cada uma delas.

## Perguntas frequentes

### Testes automatizados encarecem o projeto de software?

Na funcionalidade em que o teste é escrito, há um tempo a mais de trabalho. Nas alterações seguintes, esse tempo tende a voltar, porque a conferência deixa de ser manual e os bugs corrigidos não retornam. Em sistemas que vão ser mantidos e evoluídos por anos, testes automatizados costumam tornar cada mudança mais barata e menos arriscada.

### Qual a cobertura de testes ideal para um sistema?

Não existe um percentual ideal de cobertura de testes. O que importa é ter as regras que mexem com dinheiro, acesso e integrações bem protegidas, e o restante do sistema ganhando testes à medida que é alterado. Exigir um número fixo em contrato tende a gerar testes de enfeite, que executam o código sem verificar nenhum resultado.

### Testes automatizados substituem o teste manual?

Não. Testes automatizados garantem que regras já conhecidas continuam funcionando a cada alteração, algo que uma pessoa não consegue repetir com a mesma constância. O teste manual continua necessário para avaliar usabilidade, explorar cenários novos e validar o sistema com o usuário no teste de aceite, tarefas que dependem de julgamento humano.

### Dá para colocar testes automatizados num sistema antigo?

Sim, de forma incremental. Em vez de tentar cobrir o sistema antigo inteiro de uma vez, o caminho é começar pelas regras críticas, como cálculos financeiros, integrações e permissões, e criar um teste para cada bug corrigido. As demais partes ganham testes automatizados quando forem alteradas, sem parar a evolução do sistema.

## Como a Pervian Tech trabalha qualidade

Na Pervian Tech, testes automatizados fazem parte do trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software) desde o primeiro módulo: começamos mapeando com o cliente quais regras mexem com dinheiro, acesso e integrações, escrevemos os testes dessas regras junto com o código e configuramos o pipeline para que nenhuma alteração chegue à produção com teste falhando. O cliente tem acesso ao repositório e ao histórico de execuções.

Em sistemas existentes, o caminho é o mesmo, só que incremental: diagnóstico das áreas de maior risco, testes nas regras críticas primeiro e o restante ganhando proteção à medida que é alterado. Cada plano é sob medida, porque cada sistema tem as suas regras que não podem quebrar.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se os bugs do seu sistema insistem em voltar, [fale com a gente](https://pervian.tech/#contato). Para outros temas de engenharia, veja a [categoria de arquitetura e engenharia](https://pervian.tech/blog/categoria/engenharia).