O que realmente são casos de terror
Casos de teste de terror (ou worst-case scenario testing) são situações de teste desenhadas para simular condições extremas, dados corrompidos, entradas maliciosas e cenários de falha que raramente acontecem no dia a dia mas que podem quebrar um sistema inteiro se forem ignorados. Não é sobre criar pânico, é sobre validar se sua aplicação aguenta o peso do pior cenário possível antes que ele aconteça de verdade. No dia a dia de QA, a maioria dos times foca em happy paths. O caso de terror entra quando você quer saber se o sistema quebra silenciosamente ou se quebra visivelmente, com tratamento de erro decente. Isso faz toda a diferença entre um bug que chega ao usuário final e um bug que seu monitoramento pega antes.
Por que casos de terror importam na prática
Eu já trabalhei em um projeto onde o happy path de upload de arquivo funcionava perfeitamente até que alguém tentou enviar um arquivo com extensão .exe renomeado para .pdf. O sistema aceitou, processou e tentou salvar. O banco de dados retornou erro de integridade referencial, o serviço de notificação travou e o frontend exibiu uma página em branco para o usuário. Ninguém tinha testado isso porque, bem, quem faz upload de executável disfarçado de PDF? Até que fizeram. A lição prática aqui é simples: o caso de terror não precisa ser algo plausível. Precisa ser algo que, se acontecer, cause dano real.
Como estruturar casos de teste de terror
O primeiro passo é mapear os pontos de entrada do seu sistema. Formulários, APIs, filas de eventos, integrações externas, uploads de arquivo. Cada um desses pontos tem vetores de falha específicos que você pode transformar em casos de teste. Injeção de dados problemáticos: Teste com strings vazias, caracteres nulos, emojis, caracteres Unicode de países que você não conhece, payloads JSON malformados, campos numéricos com valores além do tipo de dado (um int32 máximo em um campo que deveria aceitar long), datas no formato errado, timestamps negativos.
Sobrecarga de carga: Envie cinquenta requisições simultâneas para o mesmo endpoint, depois mil, depois observe o que acontece com o banco de dados e o cache. O sistema deve degradar de forma previsível, não simplesmente parar. Falhas de dependência: Simule timeouts em serviços externos, retorne erros 500 de APIs de terceiros, corte a conexão com o banco durante uma transação. A aplicação precisa se recuperar, não ficar travada em estado indefinido.
Regras de negócio invertidas: Se um campo é obrigatório, teste sem ele. Se um valor precisa ser único, teste duplicidade. Se um usuário precisa de permissão X para acessar Y, teste com permissão Z.
Exemplo concreto: validação de entrada em API REST
Vamos pegar um endpoint de cadastro de usuário que recebe JSON com campos nome, email, CPF e data_nascimento. O caso de terror aqui envolve testar todas as combinações possíveis de entrada inválida. O CPF é um campo crítico no Brasil. Eu já vi sistemas que aceitavam CPFs com menos de 11 dígitos, CPFs formados apenas por zeros ou apenas por noves, CPFs com dígitos verificadores errados. O validador oficial do governo brasileiro é complexo e tem regras específicas de geração dos dígitos. Um caso de terror real seria enviar um CPF válido do ponto de vista da estrutura (11 dígitos, dígitos verificadores corretos) mas que pertence a uma pessoa real, usando dados de outra pessoa para cadastrar uma conta fraudulenta. O sistema aceitou e criou a conta. Levou três meses para descobrir porque o fluxo de recuperação de senha gerava conflito entre dois usuários com o mesmo CPF.
O workaround que implementamos foi adicionar uma verificação de unicidade em camadas: no banco de dados, uma constraint única no CPF, e na camada de aplicação, um hash do CPF combinado com uma verificação de idade mínima para evitar que dados de terceiros fossem usados como input.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Armadilhas comuns que você vai encontrar
O maior problema com casos de terror é que eles tendem a ser mal documentados. Você testa 200 cenários de borda e anota no head só "testei inputs ruins". Quando o bug volta a aparecer seis meses depois, ninguém sabe exatamente qual entrada causou a falha original. Mantenha um registro estruturado: tipo de entrada, valor exato enviado, comportamento esperado vs. comportamento real, e o que foi corrigido. Outro problema é o fals positivo de cobertura. Você pode escrever cinquenta casos de teste de terror e ainda assim perder os três mais críticos porque estavam em uma parte do sistema que ninguém pensa em testar. A lógica aqui é : os casos de terror mais importantes estão onde o dano seria maior, não onde há mais código.
Um terceiro problema é a dificuldade de reproduzir. Cenários de load testing, por exemplo, dependem de infraestrutura específica. O que funciona no ambiente de staging pode não o que acontece em produção porque o banco de dados tem índices diferentes, o cache está configurado de outra forma, ou a fila de mensagens tem throughput diferente. Sempre valide casos de terror em um ambiente que seja o mais próximo possível da produção.
Ferramentas úteis
Para injeção de dados malformados, o OWASP ZAP e o Burp Suite são as opções mais maduras. Eles permitem manipular requests HTTP diretamente e observar como o sistema reage a payloads alterados. Para load testing de caso de terror, o k6 e o Gatling oferecem scripts em JavaScript ou Scala que são mais fáceis de manter do que soluções mais pesadas como o JMeter. Para validação estrutural de dados de entrada, bibliotecas como Zod (JavaScript), Pydantic (Python) e Class Validator (TypeScript) permitem definir schemas rigorosos que rejeitam automaticamente entradas problemáticas antes que elas cheguem à camada de negócio. Isso reduz drasticamente a quantidade de casos de terror que você precisa escrever manualmente.
Para cenários de falha de dependência, o WireMock e o Testcontainers permitem simular services que respondem com erros, timeouts e latência artificial. Use isso para testar o comportamento do seu sistema quando os serviços externos falham.
Limitações reais dos casos de terror
Casos de teste de terror não substituem testes funcionais normais. Eles são complementares. Um sistema pode passar em todos os casos de terror e ainda assim falhar em um fluxo de negócio que ninguém pensou em testar. A cobertura de teste nunca é perfeita, e tentar alcançar perfeição com casos de terror é umaarmadilha comum. O outro limitador é o tempo de execução. Casos de terror, especialmente os de carga e falha de rede, são lentos. Um script de load testing pode levar de 10 a 30 minutos para completar, e isso sem considerar a configuração do ambiente. Se você rodar tudo no pipeline de CI, o tempo de build vai disparar. Uma abordagem comum é separar: casos de terror pesados rodando em um pipeline dedicado, não no mesmo fluxo de aprovação de merge.
Também vale mencionar que alguns cenários de terror simplesmente não devem ser testados em ambientes compartilhados. Testar injeção SQL ativa em um banco de dados compartilhado pode corromper dados de outros times. Sempre use ambientes isolados para testes destrutivos.
Conectando casos de terror ao monitoramento em produção
O que muitos times esquecem é que o verdadeiro teste de caso de terror acontece quando o sistema já está em produção. O melhor resultado de um caso de terror é quando ele falha de forma visível e monitorável, não quando ele causa um bug silencioso que só aparece meses depois. Configure alerts para exceções não tratadas, logue todos os inputs rejeitados e monitore o comportamento do sistema sob condições adversas em tempo real. Isso cria um ciclo de melhoria contínua: os casos de terror que você descobre em produção viram novos testes no seu suite, que por sua vez geram melhores alertas, que por sua vez capturam mais casos de terror antes que causem dano. É um loop, não um evento único.
A realidade é que nenhum sistema escapa completamente de falhas inesperadas. O objetivo dos casos de terror não é eliminar o risco, é reduzir o dano quando algo der errado. E às vezes, o dano reduzido é a única coisa que separa um incidente manejável de um incidente que exige uma equipe inteira trabalhando durante o fim de semana.
