Automação de regressão de billing (Oracle BRM)

Papel: SDET / engenheiro de automação de testes
Contexto: sistemas de billing e revenue management da Globo, via NTConsult
Período: set/2021 – out/2023

O problema

A plataforma de billing processa assinaturas, faturamento e eventos contábeis. O ciclo de regressão era o gargalo do processo de release: qualquer mudança numa regra de cobrança exigia revalidar os cenários de negócio que atravessam o catálogo de ofertas, as formas de pagamento, os ciclos de cobrança recorrente e a contabilidade.

Testar um sistema assim não é testar uma tela. É afirmar que, dada uma combinação de oferta, forma de pagamento e momento do ciclo de vida da assinatura, os lançamentos contábeis gerados são exatamente os esperados — nem um a mais, nem um a menos.

Como conduzi

Atuei na camada de automação de regressão da plataforma, em duas frentes.

Biblioteca de planos de teste

Planos declarativos descrevendo cenários de negócio ponta a ponta: contratação nova, upgrade e downgrade de oferta, troca de forma de pagamento, cancelamento, reativação, cobrança recorrente e provisionamento entre produtos. Cada plano é uma sequência de passos com asserções sobre o estado resultante — o cenário é descrito como dado, não escrito como script.

Biblioteca de funções de validação

As funções reutilizáveis que os planos consomem: validação de eventos contábeis, situação de fatura, histórico de assinatura, provisão para devedores duvidosos e parcelamento. É onde a regra de negócio de fato mora, e onde concentrei a maior parte do esforço de consolidação.

Como apoio: consultas SQL que sustentam a validação, massas de teste, templates de configuração multiambiente, testes unitários das próprias funções de validação e servidores de mock para simular integrações externas em cenários de erro.

Decisões técnicas

Regra de negócio centralizada num único arquivo. Variáveis de situação e regras que estavam espalhadas por planos individuais passaram para um arquivo central de regras de negócio. O ganho não é cosmético: quando uma situação muda no sistema, a correção acontece num lugar só, em vez de ser repetida plano a plano.

Constantes nomeadas no lugar de números mágicos. Códigos de evento contábil e de tipo de pagamento apareciam como literais soltos dentro das validações. Nomeá-los transformou diffs ilegíveis em diffs revisáveis.

Testei a própria ferramenta de teste. Escrevi testes unitários para as funções de validação. Uma suíte de regressão que ninguém valida é fonte de falsa confiança — um falso negativo numa função de validação esconde um defeito de produção por tempo indeterminado.

Tratei a mensagem de erro como interface. Quando a suíte roda de madrugada e falha, a mensagem é a única coisa que o time tem na manhã seguinte. Uma mensagem ruim transfere para a pessoa o trabalho de descobrir o que a suíte já sabia.

O que isso demonstra

• Domínio de um sistema corporativo de billing complexo, incluindo seu modelo contábil
• Automação em escala real e sustentada — contribuição contínua a um sistema vivo ao longo de todo o período, não um projeto de vitrine
• Refatoração incremental de base legada sem interromper a operação
• Preocupação com a manutenibilidade da própria automação, que é o problema que derruba a maioria das suítes de teste

Stack

• Shell Script — orquestração e automação sobre o BRM
• Oracle BRM — a plataforma de billing e revenue management sob teste
• SQL — consultas de validação contra o modelo de dados contábil e de assinaturas
• DSL proprietária de planos de teste — linguagem interna usada para escrever os planos declarativos
• Mocks HTTP — servidores simulando integrações externas em cenários de erro