O agent de QA que pega o que humanos perdem

A Lacuna Entre Testes Passando e Produto Funcionando

Todo time de engenharia já viveu esse momento: CI está verde. Todos os testes passam. Code review aprovado por dois engenheiros seniores. PR mergeado. Deploy em staging. Aí alguém abre o app no celular e a navegação está quebrada.

Testes passaram. O produto não funcionou.

Essa é a lacuna que agents de QA preenchem. Não a lacuna entre “código compila” e “código roda.” A lacuna entre “código roda” e “a experiência do usuário está correta.”

O agent de QA da Apollo Space opera com uma premissa simples: a cada commit que toca código frontend, lógica de negócio ou contratos de API, suba a aplicação e verifique contra um conjunto de regras de negócio. Não testes unitários. Não testes de integração. Regras de negócio, as coisas que importam para os usuários.

Um agent de QA apontado para um fluxo real de engenharia vai rotineiramente flaggar problemas que passaram por revisão humana de código e todos os testes automatizados, e alguns deles teriam sido incidentes sérios em produção. Os cinco abaixo são representativos das classes de bug que ele pega, cada um do tipo que escapa do CI justamente porque o CI nunca verifica aquilo. São exemplos ilustrativos, não um registro de um incidente específico, mas cada padrão aqui é um que um agent de QA revela na prática.

Bug 1: O Loop de Redirect no Login

A mudança: Um refactor do middleware de autenticação para adicionar suporte a SSO baseado em SAML. O contexto: Limpo, bem estruturado, bem documentado, com novos testes unitários cobrindo o fluxo de SSO. Aprovado por revisores humanos. Todos os testes existentes continuam verdes.

O padrão: Um agent de QA revisando esse tipo de mudança tipicamente pega algo que os revisores não pegam — usuários autenticando com email/senha (o método original de auth) presos num loop infinito de redirect. A página de login redireciona para /auth/callback, que verifica um token SSO, não encontra um, e redireciona de volta para /login. Loop.

Por que humanos perdem: A revisão de código foca nos novos caminhos de SSO porque é disso que o PR trata. O fluxo existente de email/senha não é modificado diretamente — o loop de redirect é causado por uma mudança na ordenação do middleware que afeta todos os caminhos de auth, não apenas SSO. Os testes existentes de auth continuam passando porque mockam a camada de middleware. Testam “a função de auth retorna o token correto?” mas não “o browser acaba na página certa?”

O que o agent de QA faz: A regra de negócio do agent para autenticação é direta: “Após submeter credenciais válidas na página de login, o usuário deve chegar ao dashboard em poucos segundos.” Ele submete credenciais válidas de email/senha, observa que o browser ainda está na página de login (preso no loop de redirect), e flagga o PR.

Impacto no negócio: Suba isso e cada usuário não-SSO — para a maioria dos produtos, a esmagadora maioria da base ativa — fica bloqueado. A correção costuma ser uma pequena mudança na ordenação do middleware, entregue em minutos. Bugs de autenticação estão entre as falhas de maior impacto justamente porque bloqueiam toda atividade do usuário: um único caminho de login quebrado pode derrubar todo mundo. Isso é a definição de um P0.

Bug 2: O Edge Case de Formatação de Moeda

A mudança: Suporte multi-moeda, adicionando exibição em EUR, GBP e BRL junto com a formatação existente de USD. O contexto: Uma implementação sólida, bem testada para os casos comuns, com novos testes unitários cobrindo formatação de moeda. Aprovado.

O padrão: O tipo de coisa que um agent de QA flagga aqui é uma inconsistência de renderização que nenhum teste unitário procura — preços exibidos como “EUR 1.000,50” na página de preços quando o locale está configurado como pt-BR. Isso é tecnicamente correto para formatação de português brasileiro: a vírgula é o separador decimal, o ponto é o separador de milhares. Mas se a mesma página também mostra “USD 1,000.50” ao lado (formatação americana), os dois formatos numéricos lado a lado na mesma página são genuinamente confusos — “1.000,50” e “1,000.50” parecem contradições.

Por que humanos perdem: O revisor testa a mudança num locale só, geralmente en-US. Os testes unitários cobrem funções de formatação com strings de locale hardcoded. Ninguém carrega a página renderizada real com locale do browser configurado como pt-BR visualizando moedas misturadas.

O que o agent de QA faz: O agent tem uma regra de negócio: “Todos os valores monetários numa única página devem usar convenções de formatação consistentes.” Ele carrega a página de preços em várias configurações de locale (en-US, pt-BR, de-DE, ja-JP) e compara os padrões de formatação entre moedas na mesma página, flaggando os locales onde duas moedas renderizam com convenções de separadores conflitantes.

Impacto no negócio: Sem crash, sem perda de dados — apenas confusão em exatamente os mercados internacionais que a feature foi construída para servir. O tipo de bug que não gera relatórios de erro mas gera churn silenciosamente. Telas de cobrança e preços confusas são uma razão bem documentada pela qual clientes contatam o suporte e perdem confiança.

Bug 3: A Navegação Mobile Quebrada

A mudança: Um redesign importante de navegação — nova sidebar, nova hierarquia, novos breakpoints responsivos. O contexto: Várias rodadas de revisão, uma dúzia de screenshots em diferentes tamanhos de tela anexados, testes de regressão visual passando (eles não encontraram mudanças inesperadas, porque toda mudança era esperada — era um redesign).

O padrão: Um agent de QA pega o que screenshots não pegam — que numa faixa estreita de viewport (digamos, 768px a 820px, cobrindo iPad Mini e alguns tablets Android) o menu hambúrguer abre mas os itens de navegação não são clicáveis. Estão visualmente presentes mas ficam sob um div overlay invisível que intercepta eventos de toque.

Por que humanos perdem: Os engenheiros testam as larguras que sempre testam — desktop (1440px), mobile (375px), tablet padrão (1024px). Uma faixa estreita entre esses breakpoints fica sem verificação. A regressão visual confirma que a nav parece correta, porque ela parece correta. Os itens estão visíveis. Só não são interativos.

O que o agent de QA faz: A regra de negócio do agent para navegação: “Todo link de navegação deve ser clicável e navegar para a página correta em todas as larguras de viewport de 320px a 1920px, testadas em pequenos incrementos.” Varrendo a faixa, ele descobre que em 768px e 800px, clicar no link “Dashboard” não navega para /dashboard, e flagga a faixa específica de viewport e o elemento bloqueando a interação.

Impacto no negócio: Viewports de tamanho tablet representam uma fatia significativa do tráfego real — muitas vezes perto de um décimo dele — e são exatamente as larguras que caem entre os breakpoints que times verificam à mão. Uma nav quebrada para essa fatia de usuários gera tickets de suporte imediatos e deploy de hotfix. O agent de QA pega antes de sair do PR.

Bug 4: A Race Condition no Checkout

A mudança: Processamento paralelo de pagamento para upgrades de assinatura — cobrando o pagamento e atualizando o plano em paralelo em vez de sequencialmente, cortando o tempo do fluxo de upgrade quase pela metade. O contexto: Uma otimização limpa, aprovada por dois revisores incluindo o tech lead, todos os testes passando incluindo testes de carga.

O padrão: Um agent de QA flagga uma race condition: quando o processamento de pagamento é lento (digamos, 2+ segundos), a atualização do plano completa primeiro. O dashboard do usuário mostra brevemente as features do novo plano antes da confirmação do pagamento chegar. Se o pagamento então falha, o usuário tem acesso a features premium por alguns segundos antes do rollback entrar em ação — e, mais criticamente, se o usuário disparar uma ação exclusiva premium nessa janela (como exportar dados num formato premium), a ação tem sucesso e não é revertida mesmo após a falha do pagamento.

Por que humanos perdem: A revisão de código corretamente nota que ambas as operações podem falhar independentemente e verifica que tratamento de falha existe para os dois caminhos. Os testes verificam que um pagamento falho reverte o upgrade do plano. Mas os testes executam em milissegundos — a race condition só se manifesta quando o processamento de pagamento leva significativamente mais tempo que a atualização do plano, o que requer latência do mundo real.

O que o agent de QA faz: A regra de negócio do agent para pagamentos: “Nenhuma feature premium deveria ser acessível até o pagamento ser confirmado. Nenhum estado parcial deveria ser visível ao usuário.” Ele roda o fluxo de upgrade com uma faixa de latências de pagamento simuladas (500ms, 1000ms, 2000ms, 5000ms). A partir de cerca de 2000ms, detecta a race verificando acessibilidade de features durante a janela entre atualização do plano e confirmação do pagamento.

Impacto no negócio: Vazamento de receita por usuários explorando (intencionalmente ou não) a janela de race. Pior, uma falha de pagamento após uma ação premium cria uma situação constrangedora de atendimento ao cliente: você revoga os dados exportados? Cobra retroativamente? Processamento de pagamento real regularmente leva múltiplos segundos para uma fração não-trivial das transações, então isso não é um edge case raro — é uma janela de timing que se abre rotineiramente.

Bug 5: Cache Desatualizado Servindo Preços Antigos

A mudança: Edge caching (CloudFront) na página de preços para melhorar tempos de carregamento, cortando o time-to-first-byte drasticamente. O contexto: Todos os testes passando, aprovado.

O padrão: Um agent de QA flagga que após uma mudança de preço no painel admin, a página de preços continua mostrando os preços antigos pela duração total do TTL do cache (digamos, 24 horas). A lógica de invalidação de cache existe — mas só é acionada em deploys completos, não em atualizações de preço pelo painel admin.

Por que humanos perdem: O engenheiro que implementa o caching testa mudando o conteúdo da página no código e redepployando, o que aciona invalidação de cache corretamente. O cenário de mudar preços pelo painel admin sem deploy não é testado porque não faz parte do escopo do PR. O revisor foca na implementação de caching, não em todas as formas pelas quais conteúdo em cache poderia ficar desatualizado.

O que o agent de QA faz: O agent tem uma regra de negócio: “A página de preços deve refletir os preços atuais em até um minuto de qualquer mudança de preço.” Ele atualiza um preço via API admin, espera, e recarrega a página de preços. O preço antigo ainda é exibido. Flagga a desatualização, com a informação do header de cache mostrando que o CDN está servindo uma resposta em cache.

Impacto no negócio: Imagine atualizar seus preços na segunda e descobrir na terça que todos os seus prospects viram os números de ontem. Ou pior: oferecer um desconto promocional e ter a página em cache mostrando o preço antigo, mais alto. Bugs de cache desatualizado com impacto real na receita são comuns o suficiente para serem um modo de falha reconhecido em trabalho de performance web.

O Padrão Nos Cinco Bugs

Olhe os cinco bugs juntos e um padrão emerge:

1. Loop de redirect no login: Correto no nível de código, quebrado no nível de usuário
2. Formatação de moeda: Tecnicamente preciso, experiencialmente confuso
3. Nav mobile: Visualmente correto, funcionalmente quebrado
4. Race condition: Lógica correta, timing errado
5. Cache desatualizado: Feature correta, integração quebrada

Nenhum desses seria pego por testes unitários, porque testes unitários verificam comportamento de código isoladamente. Nenhum seria pego por testes de integração padrão, porque testes de integração verificam que componentes se comunicam corretamente. Todos os cinco são pegos porque o agent de QA valida a experiência real do usuário, o que um usuário real veria, tocaria e encontraria.

Essa é a distinção entre testar código e testar produto. Pipelines de CI tradicionais são excelentes no primeiro. Eles verificam que funções retornam valores esperados, APIs respondem com status codes corretos e componentes renderizam sem erros. Mas não verificam que o usuário pode realmente cumprir seu objetivo.

Como o Agent de QA Funciona

O agent de QA da Apollo Space não é um runner de testes. É um agent que entende regras de negócio e as valida contra a aplicação rodando.

O loop principal:

1. Trigger: Um PR é aberto ou atualizado que toca código frontend, lógica de negócio ou contratos de API (detectado via padrões de caminho de arquivo e análise de mudanças)
2. Ambiente: O agent sobe um deploy de preview do branch do PR
3. Avaliação de regras: O agent carrega seu conjunto de regras de negócio — uma coleção curada de regras cobrindo autenticação, navegação, exibição de dados, fluxos de pagamento, permissões e compatibilidade cross-browser
4. Execução: O agent roda cada regra aplicável usando automação de browser, verificando output real renderizado contra comportamento esperado
5. Relatório: Falhas são postadas como comentários no PR com a regra específica violada, o comportamento esperado, o comportamento real, e um screenshot ou gravação

As regras de negócio são o diferenciador-chave. Não são assertions geradas de código. São regras definidas por humanos sobre como o produto deveria se comportar. “Após login, o usuário vê o dashboard.” “Todos os preços são exibidos na moeda selecionada pelo usuário.” “Navegação funciona em todas as larguras de viewport.” Essas regras não mudam quando o código muda, e é exatamente por isso que pegam bugs que testes no nível de código perdem.

A Questão do QA Humano

O agent de QA substitui engenheiros de QA humanos? Parcialmente.

Ele substitui as partes repetitivas: teste de regressão, verificação de edge cases entre browsers e viewports, validação de regras de negócio em cada PR. Um engenheiro de QA humano rodando essas mesmas verificações manualmente levaria horas por PR. O agent faz em minutos.

Mas engenheiros de QA humanos trazem algo que o agent não traz: intuição sobre usabilidade, julgamento sobre qualidade da experiência do usuário, e a habilidade de testar features novas onde o comportamento esperado ainda não foi definido. O agent pode dizer “o botão funciona.” Não pode dizer “o botão está no lugar errado.”

O modelo a usar: o agent de QA lida com testes de regressão e baseados em regras em cada PR. Engenheiros de QA humanos focam em testes exploratórios de novas features, revisões de usabilidade e manutenção do conjunto de regras de negócio que o agent aplica.

Essa divisão empurra a cobertura de QA em direção a cada PR em vez do subconjunto que os humanos têm tempo de cobrir, e tira o trabalho repetitivo dos engenheiros de QA humanos para que gastem seu tempo em atividades de maior valor. Os humanos fazem o julgamento; o agent faz o trabalho pesado.

O Custo de Bugs Pegos Tarde

Bugs como os cinco acima, pegos durante revisão de código antes do merge, levam de minutos a horas para corrigir.

Se chegam à produção, o cálculo muda inteiramente. É uma regra prática há muito observada em engenharia de software — remontando ao Systems Sciences Institute da IBM e ecoada por estudos de custo-de-qualidade desde então — que bugs encontrados em produção custam muitas vezes mais para corrigir que bugs encontrados durante desenvolvimento, quando você considera resposta a incidentes, deploy de hotfix, comunicação com clientes e danos à reputação.

Pegue o bug de autenticação: um incidente em produção bloqueando a maior parte da base de usuários significaria um P0 all-hands — rollback de emergência, comunicação com usuários afetados, um post-mortem e horas de tempo de engenheiros seniores. Facilmente um custo de cinco dígitos só em mão de obra e custo de oportunidade. O agent de QA pega em minutos, e a correção leva minutos a mais. A matemática não é sutil.

O Que Isso Significa para Times de Engenharia

O agent de QA não é mágica. É a aplicação sistemática de regras de negócio contra cada mudança, sem atalhos, sem cansaço, sem a tendência humana de focar o esforço de revisão nas partes do código que mudaram em vez das partes do produto que essas mudanças afetam.

Humanos revisam código. O agent de QA revisa produto. Ambos são necessários. Nenhum é suficiente sozinho. Bugs como os cinco neste texto escapam dos humanos não porque humanos são ruins em QA, mas porque humanos são ruins em testes repetitivos, exaustivos e cross-dimensionais em cada PR. É para isso que agents existem.