A maioria das pessoas que usa aplicativos bancários nunca pensa no que acontece nos bastidores quando uma transação é realizada. Eles tocam em um botão, o dinheiro se transfer e pronto. Mas para os engenheiros responsáveis por garantir que essas transações funcionem de forma confiável, a realidade é consideravelmente mais complicada, especialmente quando os bugs só se revelam sob condições muito específicas que nenhum ambiente de teste jamais previu.
Tanvi Mittal, um profissional de engenharia de qualidade de software program com 15 anos de experiência em sistemas financeiros empresariais, conhece esse problema intimamente. Ela passou grande parte de sua carreira construindo e liderando estruturas de automação de testes para aplicações bancárias de grande escala e, ao longo desse tempo, percebeu um padrão que se repetia continuamente. Bugs que passavam por todas as camadas de teste, desenvolvimento, preparação e controle de qualidade apareciam na produção, muitas vezes de maneiras difíceis de rastrear e caras para corrigir.
Um incidente em specific moldou seu pensamento. Um bug de transação passou despercebido durante todo o ciclo de testes e acabou sendo detectado não por um alerta automatizado ou por uma ferramenta de monitoramento, mas por um caixa de banco durante uma interação actual com o cliente. As duas primeiras transações consecutivas funcionaram bem. O terceiro falhou. Demorou dias para diagnosticar. O bug só foi acionado naquela sequência específica de eventos, naquele quantity, e nenhum ambiente inferior jamais chegou perto de replicá-lo.
“Os dados continuaram mostrando o mesmo padrão”, diz Mittal. “Bugs estavam sendo enviados para a produção e simplesmente não conseguíamos encontrá-los em ambientes inferiores. Não porque a equipe não estivesse fazendo seu trabalho, mas porque os ambientes inferiores não se comportam como produção.”
Essa experiência, e outras semelhantes, levaram-na a começar a pensar de forma diferente sobre a origem da cobertura dos testes. Documentos de requisitos e planos de teste escritos manualmente refletem o que os engenheiros esperam que os usuários façam. Os logs de produção refletem o que os usuários realmente fazem em cada caso extremo, cada sequência incomum, cada modo de falha que ninguém pensou em testar. A questão à qual Mittal sempre voltava period por que esses logs não estavam sendo usados para conduzir a geração de testes.
Essa questão acabou se tornando LogMiner-QA.
Construindo algo que não existia
LogMiner-QA ingere logs de aplicativos brutos e usa IA e aprendizado de máquina para gerar automaticamente cenários de teste Gherkin, o formato estruturado e legível usado por estruturas de teste como Cucumber e Pytest-BDD que podem ser alimentados diretamente em pipelines de CI/CD. A ideia é pegar a inteligência comportamental já incorporada nos logs de produção e torná-la acionável para as equipes de controle de qualidade antes do próximo lançamento, em vez de depois que algo quebrar.
Chegar lá demorou mais do que Mittal esperava e os desafios foram menos glamorosos do que o conceito. A principal dificuldade period que os registros de produção não são padronizados. Cada organização os estrutura de maneira diferente. Os nomes dos campos variam; um sistema chama isso de “mensagem”, outro chama de “mensagem”. Os formatos de carimbo de knowledge/hora são diferentes. Algumas equipes registram no nível da transação, outras no nível da sessão. Construir uma ferramenta que pudesse interpretar logs de maneira confiável nesse tipo de variabilidade significava testar uma ampla variedade de amostras de log reais e iterar constantemente.
“Cada vez que testei uma nova estrutura de toras, algo quebrou”, diz ela. “Essa foi a parte nada glamorosa da construção disso, não a IA, mas a realidade confusa e inconsistente de como as toras realmente aparecem na natureza.”
A ferramenta lida com isso por meio de mapeamento de campo flexível e ingestão configurável, suportando arquivos JSON e CSV locais, bem como conectores para Elasticsearch e Datadog. Nos bastidores, ele usa enriquecimento de PNL com incorporações de transformadores, clustering e um mecanismo de pontuação de anomalias da Isolation Forest para identificar padrões de comportamento incomuns. Um componente de análise de jornada baseado em LSTM reconstrói fluxos reais de clientes entre sessões, trazendo à tona sequências como aquela falha de três transações que o design de teste handbook constantemente ignora.
O problema de privacidade sobre o qual ninguém queria falar
Quando Mittal começou a conversar com as pessoas sobre a ferramenta, ela teve uma reação que havia previsto, mas que ainda precisava ser trabalhada com cuidado. No momento em que ela mencionou os registros de produção, as pessoas ficaram cautelosas. Num contexto bancário, os registos de produção contêm dados reais de números de contas de clientes, IDs de transações, IBANs e padrões de comportamento que podem ser associados a indivíduos. A ideia de executar esses registros por meio de qualquer ferramenta externa levantou preocupações imediatas de conformidade.
“Convencer as pessoas de que é seguro colocar registros de produção na ferramenta foi um desafio tanto cultural quanto técnico”, diz ela.
Sua resposta foi fazer da privacidade a base arquitetônica, em vez de um recurso adicionado ao topo. O LogMiner-QA limpa os logs antes de qualquer análise, usando correspondência de padrões e reconhecimento de entidade nomeada baseado em spaCy para detectar PII, redigir campos confidenciais e substituí-los por tokens estáveis que preservam a integridade referencial sem expor dados subjacentes. Uma camada de privacidade diferencial adiciona ruído calibrado às métricas agregadas, tornando computacionalmente inviável reconstruir o comportamento particular person do cliente a partir de resultados anonimizados. A ferramenta é executada no native, em ambientes isolados em contêineres, o que significa que os logs nunca saem da infraestrutura da própria organização.
Para equipes de compliance em setores regulamentados, esse último ponto tende a encerrar a conversa rapidamente e no bom sentido.
Fechando o ponto cego da cobertura
Mittal inicialmente definiu o LogMiner-QA para serviços bancários, o domínio que ela conhecia melhor e onde os riscos em torno de falhas de produção são maiores. Mas à medida que a ferramenta se desenvolveu, ela começou a ver o mesmo problema subjacente em outros setores regulamentados de saúde, seguros e serviços financeiros em geral. A lacuna entre o que os conjuntos de testes cobrem e o que a produção faz não é exclusiva do setor bancário. É estrutural e existe onde quer que o design do teste seja orientado principalmente por documentos de requisitos, e não pelo comportamento observado do usuário.
A ferramenta reflete esse escopo mais amplo. Seu módulo de conformidade gera cenários de teste alinhados com PCI e GDPR. Seu módulo de detecção de fraude visa especificamente anomalias de velocidade, fluxos de transações de alto valor e comportamentos de sequência de login com falha que são quase impossíveis de replicar em ambientes inferiores sem dados reais de produção como ponto de referência. Um modo CI emite resumos JSON compactos para portas de pipeline, permitindo que as equipes falhem nas construções automaticamente quando descobertas de alta gravidade ou limites de anomalia são excedidos.
LogMiner-QA é open supply sob a licença MIT e está disponível em github.com/77QAlab/LogMiner-QA. A Mittal está procurando pioneiros nas equipes de controle de qualidade de bancos e empresas, dispostos a testá-lo em relação à diversidade actual de registros, a mesma variabilidade que tornou sua construção genuinamente difícil. As adições planejadas incluem conectores Splunk e CloudWatch, um painel de visualização de risco e modelos de detecção de fraude mais sofisticados.
Para Mittal, a motivação por trás de tudo isso permanece a mesma de quando um caixa de banco detectou um bug que um ciclo de teste inteiro não percebeu. A produção já sabe o que seu conjunto de testes não sabe. A questão é se você está prestando atenção.