portfólio

Qualidade em plataforma fiscal: cobertura que encontrou defeito real

Java Gradle JUnit MySQL

Papel: SDET / engenheiro de qualidade
Contexto: plataforma de emissão de documentos fiscais integrada ao billing, na Globo, via NTConsult
Período: jul – ago/2026

O problema

Emitir documento fiscal é um domínio em que defeito não é bug de tela: é obrigação legal descumprida. O fluxo atravessa billing, plataforma fiscal e um retorno assíncrono por callback — e o callback é justamente onde a complexidade se concentra, porque combina forma de pagamento, tipo de agente e resultado da emissão numa matriz de casos.

É esse o argumento do esforço de teste: aqui, um caso não coberto aparece como uma obrigação legal que a empresa deixou de cumprir.

Como conduzi

1. Casos de teste em dois braços deliberados

Construí uma série de casos de teste cobrindo a matriz de callbacks de emissão — forma de pagamento, tipo de agente e resultado da emissão — junto com a infraestrutura que os sustenta: camada de acesso a dados, DTOs, endpoints de consulta e escrita, e resolução da credencial do banco.

Cada caso foi construído em dois braços deliberados: um observacional, que registra o comportamento sem falhar a suíte, e um ativo, que exerce o fluxo real e afirma o resultado esperado. Essa separação permite introduzir cobertura em terreno desconhecido sem travar o pipeline no primeiro dia, e depois promover cada caso para ativo conforme o comportamento é confirmado. Somado à infraestrutura de apoio, o trabalho cobre testes de integração e testes de contrato.

2. Os defeitos que a suíte encontrou

Esta é a parte que justifica o investimento.

Uma falha de ponteiro nulo no fluxo de callback, disparada quando o agente voltava ausente em combinação com um tipo específico de pagamento. O caso de teste que a encontrou não foi escrito para caçar essa falha — foi escrito para cobrir a combinação. O defeito apareceu porque aquela combinação nunca tinha sido exercitada.

Uma combinação válida de forma de pagamento e emissor que a plataforma não mapeava. Do ponto de vista do negócio, uma forma de pagamento legítima que o sistema não sabia tratar.

Não determinismo na consulta de resultado. A busca pelo documento fiscal não tinha ordenação estável, o que fazia a suíte passar ou falhar conforme o retorno do banco. Corrigi impondo ordenação determinística e selecionando o registro correto em caso de retentativa. Teste intermitente é pior que teste nenhum: ensina o time a ignorar falha.

Um erro de conversão de tipo em colunas numéricas de largura maior, mapeadas com o tipo errado.

3. Decisões técnicas que defendo

Resolver a credencial do banco pelo ambiente, com sobrescrita explícita. A conexão de banco passou a ser resolvida a partir da plataforma de execução, aceitando uma variável de ambiente como sobrescrita para uso local. Ninguém precisa de segredo parado num arquivo para rodar a suíte.

Escopo de dependência correto. Restringi o driver de banco ao escopo de teste — detalhe de build que impede uma dependência só de teste de vazar para o artefato de produção.

Ignorar no versionamento o arquivo de token local. Configuração de ferramenta que carrega token pessoal não entra no repositório.

Documentar a suíte para quem vem depois — humano ou agente. Escrevi o guia de setup e execução, mais uma camada de contexto estruturada sobre o domínio fiscal, pensada para que outra pessoa, ou um assistente de código, consiga trabalhar ali sem reconstruir o entendimento do zero.

O que isso demonstra

  • Engenharia de teste em domínio regulatório, com defeitos reais encontrados e reportados
  • Estratégia para introduzir cobertura em terreno desconhecido sem travar o pipeline
  • Diagnóstico de não determinismo — a classe de falha que mais destrói a confiança numa suíte automatizada
  • Cuidado com segredo, escopo de dependência e reprodutibilidade de ambiente
  • Documentação tratada como parte da entrega, não como sobra

Stack

  • Java — linguagem de implementação dos casos de teste e da infraestrutura de apoio: camada de acesso a dados, DTOs e endpoints de consulta e escrita
  • MySQL — o banco por trás da consulta de resultado da emissão; origem dos defeitos de não determinismo e de conversão de tipo que a suíte encontrou, e alvo do driver restrito ao escopo de teste e da resolução de credencial por ambiente