MAYAK monta pipeline de QA com 58 blocos e pega 9 de 10 armadilhas na especificação técnica

O autor do projeto MAYAK montou um pipeline que leva a especificação técnica até a execução dos testes por meio de 58 blocos especializados. Em uma especificação sintética com dez defeitos plantados, a automação pegou nove. O décimo foi encontrado por uma pessoa, mas com ajuda do questionário elaborado pela máquina. Em 90 segundos, o sistema gerou 26 perguntas para stakeholders e apontou 20 zonas cinzentas. Em 26 minutos, escreveu 37 cenários BDD.

Documentação antes dos cliques

O nome do projeto define a ordem de trabalho: primeiro se resolvem os requisitos, depois se escrevem e executam os testes. A cadeia é esta: «especificação técnica → canonização → design de testes → execução». Pelo nome da etapa, a canonização converte o texto disperso dos requisitos em uma forma única e estruturada. Sobre essa base se constrói o design de testes. A lógica é clara: testes derivados de uma especificação vaga herdam a vagueza dela e apenas a disfarçam com um formato organizado.

O projeto faz parte de uma classe crescente de sistemas em que o LLM trabalha não com um único prompt, mas com um longo pipeline de etapas estreitas. Aqui, são 58 etapas.

Gates de confiança em vez de adivinhação

O principal problema dos modelos de linguagem no design de testes é a tendência de completar o que falta com detalhes concretos e plausíveis. A especificação diz «a página deve abrir rápido». O modelo logo entrega «no máximo 2 segundos» e registra isso como critério de aceitação. O autor do MAYAK fecha essa brecha com duas regras:

• cada critério de aceitação é ancorado em uma citação do documento original: sem citação, não há critério;
• uma zona cinzenta vira pergunta ao stakeholder, e não um valor chutado.

Há ainda um terceiro ponto, de ordem econômica. Novas execuções saem de graça graças ao cache. Com 58 blocos, isso pesa: a especificação é corrigida conforme as perguntas são respondidas, e sem cache cada iteração seria paga de novo.

O que a execução mostrou

O teste foi feito em uma especificação sintética, na qual o autor plantou antecipadamente dez «doenças». Resultados do anúncio:

• 9 das 10 armadilhas foram pegas pela automação;
• a décima foi encontrada por uma pessoa, com base no questionário da máquina;
• 26 perguntas para stakeholders foram geradas em 90 segundos;
• foram identificadas 20 zonas cinzentas;
• 37 cenários BDD ficaram prontos em 26 minutos.

Os números exigem ressalvas. As armadilhas foram inventadas pelo próprio autor, o documento é sintético e houve uma única execução. Isso é uma demonstração de que a ideia funciona, não um benchmark. Especificações reais costumam ser mais longas, mais contraditórias e, em alguns trechos, escritas por pessoas que nem sabem direito o que querem. O próprio autor promete contar onde a plataforma erra e o que ainda está inacabado. Essas seções estão no texto completo no Habr; o anúncio não traz detalhes, então ainda não dá para avaliar a dimensão dos erros.

O caso da décima armadilha merece atenção à parte. O sistema não a resolveu sozinho, mas o questionário ajudou a pessoa a encontrá-la. Na prática, isso não é fraqueza, e sim um esquema normal: a máquina estreita o campo de busca, e o humano decide.

O que levar para a prática

Dá para aproveitar alguns procedimentos do projeto sem copiá-lo por inteiro:

• Rode seu pipeline em um documento com defeitos plantados de antemão e calcule a proporção dos encontrados. Sem esse padrão de referência, qualquer conversa sobre qualidade vira opinião.
• Exija do modelo uma citação-fonte para cada critério de aceitação e descarte automaticamente tudo o que vier sem ela.
• Meça não só o número de cenários gerados, mas também a proporção de perguntas que os stakeholders realmente responderam. Um bom questionário é inútil se ninguém o responde.
• Faça cache dos resultados intermediários dos blocos, para que a correção de um parágrafo da especificação não reinicie o pipeline inteiro.
• Mantenha uma pessoa na revisão final. Nove de dez em um documento sintético ainda não é garantia em um documento de produção.

Se você tem um arquivo de especificações cujos problemas só foram descobertos depois, ele já é um conjunto de testes pronto para essa abordagem.