Camada de testes de um motor antifraude

Papel: SDET — camada de testes automatizados
Contexto: plataforma antifraude da Globo, via NTConsult
Período: out/2023 – fev/2026

O problema

O motor antifraude era um sistema maduro, com anos de evolução e o dono do sistema como principal autor. Eu não construí o motor — e essa distinção importa, porque o que eu fiz ali só faz sentido descrito no lugar certo: eu construí a camada que prova que o motor funciona.

Construí em parceria direta com quem conhecia o sistema por dentro. O dono do sistema explicava a intenção da regra, eu desenhava o cenário que a exercitava e, quando o cenário não fechava, a conversa costumava revelar uma de duas coisas: uma lacuna no meu entendimento, ou uma ambiguidade real na própria regra. Essa segunda categoria foi a parte mais valiosa da colaboração: os cenários estavam encontrando ambiguidade nas regras, não só confirmando-as.

Trabalhar assim exige uma postura específica: entrar num domínio que não é seu, aprender rápido o suficiente para fazer boas perguntas, e fazê-las sem atrapalhar quem está entregando. É uma habilidade de time, não de indivíduo.

Além do trabalho no antifraude, eu era acionado pelo meu time anterior de billing quando a fila de testes de lá acumulava, ajudando a dar vazão e automatizando alguns daqueles cenários pelo caminho.

Como conduzi

1. Cobertura das regras de decisão

Cada regra do motor ganhou cenários automatizados: restrições por faixa de emissor de cartão, restrições por país de origem do cartão, listas de restrição de documento e de e-mail, regras de velocidade por endereço de rede, grupos de controle e testes A/B seguros, e comportamento do cache de regras.

2. Cobertura da análise de decisão

A camada mais sutil: não basta a regra existir — a decisão final da análise precisa estar correta quando várias regras interagem, incluindo a distinção entre negar uma transação de imediato e retê-la para revisão manual.

3. Camada de interface administrativa

Automatizei a tela de administração de regras com Playwright e Java, incluindo autenticação, gestão de permissões e um page object model que mantém os seletores separados da lógica de teste.

4. Uma contribuição ao serviço, não só aos testes

Implementei o adaptador que ligou as listas de restrição de documento e de e-mail ao fluxo de requisição de análise. Pequeno em tamanho, relevante no que sinaliza: o trabalho de teste tinha me dado entendimento de domínio suficiente para contribuir com o produto.

5. Decisões técnicas que defendo

• Extraí para constantes as descrições de motivo de decisão. As strings que descrevem por que uma transação foi negada estavam duplicadas nas asserções; centralizá-las eliminou uma classe inteira de teste que quebrava por mudança puramente cosmética.
• Paralelizei a suíte. O tempo de feedback decide se uma suíte é usada ou ignorada — uma suíte lenta é uma suíte que alguém acaba desligando.
• Adotei o Allure e instrumentei cada teste com ele, para que o relatório fale a língua do domínio em vez de só “verde ou vermelho”. Cada validação virou um passo nomeado carregando valor esperado e obtido lado a lado, e os cenários ganharam hierarquia em três níveis — área, funcionalidade e cenário — mais um rótulo de criticidade. Quem não escreveu o teste consegue ler a falha e saber qual regra de negócio quebrou.
• Liguei a captura de trace do Playwright por padrão. Falha intermitente sem evidência não se diagnostica depois do fato; com trace ligado desde o começo — screenshots, snapshots de DOM e fonte do passo — a primeira falha já chega com o material necessário para investigá-la.
• Removi testes mortos em vez de deixá-los desabilitados. Quando a empresa deixou de usar um fornecedor externo de antifraude e, separadamente, quando um serviço interno de pontuação foi descontinuado, desativei e depois removi os cenários correspondentes, declarando o motivo na mensagem de commit. Um teste desabilitado para sempre é ruído que corrói a confiança na suíte inteira.

O que isso demonstra

• Capacidade de entrar num domínio complexo e desconhecido e produzir valor rápido
• Colaboração produtiva com o dono do sistema, sem disputar autoria
• Automação em duas camadas — API e interface — com o mesmo rigor
• Higiene de suíte: remover código morto, extrair constantes, paralelizar, capturar evidência de falha
• Atenção à legibilidade da saída dos testes, não só à cobertura
• Ser acionado por outro time, fora do escopo corrente, para desafogar uma fila de testes

Stack

• Java — linguagem de implementação da camada de testes e da contribuição no serviço
• Playwright — automação de API e de interface contra o motor antifraude e sua tela administrativa
• Maven — ferramenta de build
• Allure — relatório de teste estruturado e legível no vocabulário do domínio