QAOS: como nove agentes de IA decidem se uma versão pode ir para produção.

Uma suíte de testes verde diz pouco. Ela pode ter testes pulados, cobrir só o caminho feliz e ainda assim ser o argumento de “dá para subir” numa reunião de release. O QAOS (Quality AI Operating System) foi desenhado em torno dessa fragilidade: um sistema de agentes de IA que lê o alvo, planeja, executa e entrega uma recomendação de release com a evidência na mão.

O problema: julgamento de qualidade não escala

Escrever caso de teste, rodar e abrir bug virou trabalho que modelos de linguagem fazem em segundos. O que não virou commodity é saber o que testar, por quê e o que fazer com o resultado. Isso depende de conhecimento de domínio, arquitetura e risco, e costuma morar na cabeça de poucas pessoas.

Três sintomas aparecem em quase toda operação de QA que cresce:

• Verde que esconde buraco. Teste pulado ou ignorado não aparece no painel de “passou”.
• Cobertura como opinião. “Acho que está coberto” não é um dado.
• Critério de release pessoal. A decisão de subir depende de quem está na sala.

A ideia: QA dentro de um sistema de IA

A maior parte das ferramentas coloca IA dentro do processo de QA: um assistente ajuda a escrever o teste. O QAOS inverte a lógica. Em vez de um copiloto respondendo perguntas isoladas, há um conjunto de agentes especializados que entendem o requisito, mapeiam risco, planejam, geram, executam e analisam, enquanto uma pessoa desenha o processo em vez de executá-lo manualmente.

Três princípios sustentam o desenho:

• Cada agente faz uma coisa. Responsabilidade única, saída estruturada, comportamento previsível.
• Contexto encadeado. A saída de um agente é a entrada do próximo. Nenhum decide no vácuo.
• Rastreável. Toda execução fica registrada: o que rodou, com qual provedor de modelo e com qual resultado.

Os nove agentes e o fluxo

O orquestrador coordena nove agentes. Três deles são condicionais (Code Reader, Security e Execution); os outros seis formam o fluxo básico. O Security, por exemplo, é ligado por projeto e nasce desligado.

1. Code Reader condicionalLê o repositório, monta o inventário de rotas e funções e declara as limitações da leitura.
2. RequirementExtrai regras de negócio, ambiguidades e critérios de aceite do requisito.
3. RiskClassifica riscos por categoria e severidade.
4. Security condicionalMonta o modelo de ameaças e cenários negativos de autorização. Sem credencial ou rota para ancorar, declara a lacuna em vez de supor.
5. Test PlannerPrioriza cenários por risco, define nível e tipo de teste e registra as lacunas de cobertura.
6. AutomationGera scripts executáveis e diz o que não conseguiu automatizar.
7. Execution condicionalRoda os scripts em container, reconcilia com o relatório real e classifica falhas com evidência.
8. Bug AnalysisLê o log e os resultados reconciliados para apontar uma causa provável sustentada.
9. ReleaseConsolida tudo e recomenda go ou no-go, com justificativa e condição de reversão.

Como todo agente segue o mesmo contrato (recebe o contexto acumulado e devolve uma saída validada por schema, nunca texto livre), dá para trocar o provedor de modelo ou reescrever um agente sem quebrar os demais. O sistema roteia entre provedores por configuração.

Dois modos de entrada: repositório e URL

Execução real, em container

Gerar teste é a parte fácil. O QAOS roda os scripts contra o alvo de verdade, dentro de container, nunca no host. Testes de integração e de ponta a ponta usam Python, e a performance pode ser medida com k6 (opcional, só no modo repositório). Depois da execução, o resultado é reconciliado com o relatório real do runner, e o que o agente “achou” que aconteceu perde para o que o relatório registrou.

Evidência e cobertura por item

Dois mecanismos transformam “acho que está coberto” em algo verificável.

Cobertura por item do inventário. Cada cenário do planejador aponta o item do inventário que cobre. Cada item termina com as quatro categorias de cobertura preenchidas, ou com uma lacuna declarada por categoria faltante, com o motivo escrito. No modo URL, cada tela é um item.

Uma imagem por verificação. Todo cenário executado carrega a evidência do que foi checado: um print da tela nos testes com interface, uma imagem gerada a partir das requisições nos testes sem tela. O texto é redigido antes de virar imagem. Cenário executado sem imagem não ganha status de aprovado: sai como indeterminado.

A decisão: go ou no-go

O resultado final é a recomendação do Release Agent, apresentada junto do resumo da execução: cenários que passaram, falharam ou foram pulados, itens do inventário completos, parciais e sem cenário, custo e uso de tokens quando disponíveis, e a saída de cada agente.

As falhas não entram num saco único. O sistema separa bug_provavel_do_alvo, bug_provavel_do_teste e indeterminado, o que evita culpar o produto por um teste mal escrito, e o contrário.

Os status também são distintos. Uma execução succeeded indica que o pipeline concluiu e pode coexistir com testes falhando e um no-go. Já partial indica que uma etapa foi interrompida e que há resultados parciais, o que não prova bug no alvo.

O que o QAOS não é

• Não é um copiloto de QA. Não fica esperando uma pergunta pontual; executa o ciclo inteiro.
• Não substitui o julgamento sênior. Amplia o alcance dele e deixa a decisão auditável.
• Não promete o que não mediu. Onde não há evidência, o resultado diz que não há.

Faz mais sentido para organizações que ainda não têm uma estrutura de QA e para times grandes que querem estender o alcance do QA que já têm. Em ambos os casos, quem decide a entrega ganha uma recomendação rastreável, em vez de uma planilha e um “acho que sim”.