Testes automatizados: importância e como cobrar do fornecedor

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 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.

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 (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). 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, 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: 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 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 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. Para outros temas de engenharia, veja a categoria de arquitetura e engenharia.