A Apollo pode ser seu departamento de QA? Sim, porque QA sempre foi um eval loop

Uma suíte de testes fica verde. O build é enviado. Dois dias depois um cliente não consegue passar da segunda tela da coisa que a suíte jurou estar bem. Ninguém mentiu. Cada assertion que a equipe escreveu passou, só que nenhuma delas era a coisa que o cliente de fato fez. Os testes checaram que o código fazia o que o código faz. Eles nunca checaram que o produto faz o que o usuário precisa.

Essa lacuna, entre “os testes passam” e “o fluxo funciona”, é a razão inteira pela qual QA existe. E é a lacuna que a maioria do QA nunca fecha, porque QA é tratado como uma fase que você sobrevive em vez de um loop que você roda.

Aqui está a afirmação que este post defende: QA não é uma fase, é um loop, defina o fluxo, rode o produto real, avalie o resultado com um juiz que nunca escreveu o código, registre a lacuna como uma task. Diga essa frase em voz alta e você descreveu algo que um sistema operacional pode rodar continuamente, não uma coisa que uma equipe faz em pânico na semana antes do lançamento.

Então a Apollo pode ser seu departamento de QA? Sim, mas só porque QA nunca foi de fato um departamento. Era um loop vestido com a roupa de um departamento.

O QA ingênuo: uma fase no fim, avaliada pelas pessoas que enviaram

O jeito que a maioria das equipes faz QA é o jeito que você esperaria se nunca tivesse pensado direito sobre isso. Você constrói a feature. Quando parece pronta, você a entrega ao QA, ou, numa empresa pequena, você é o QA, clicando pelo seu próprio trabalho às 23h antes de um release. Você roda o caminho feliz, parece certo, você envia.

Isso falha de dois jeitos específicos e previsíveis, e nomeá-los é o ponto todo.

A primeira falha é o problema da fase. QA-no-fim significa que QA roda exatamente uma vez por release, na linha do tempo mais esgotada, contra a versão à qual você já está emocionalmente comprometido a enviar. Quando o loop fecha, a lacuna que ele encontrou é do tipo mais caro, a que um cliente teria batido primeiro. Você não rodou o loop devagar demais. Você o rodou tarde demais, e apenas uma vez.

A segunda falha é pior, e mais quieta. A mesma mente que construiu a coisa está avaliando se ela funciona. O engenheiro que escreveu o fluxo clica pelo fluxo, e claro que funciona, ele toma o caminho que projetou, preenche o campo com o valor que esperava, e nunca tenta o input que não imaginou, porque se tivesse imaginado teria tratado. Um check verde do autor é o autor e o autor concordando. Não é evidência.

Essas duas falhas se compõem. Uma fase que roda uma vez, auto-avaliada pelo construtor, é como um produto passa em toda checagem interna e desaba no momento em que um estranho o toca. O bug não escapou do QA. O QA foi estruturalmente construído para perdê-lo.

O loop que QA de fato é: fluxo, rode, julgue, registre

Então tire o QA de volta ao que ele está fazendo por baixo do organograma. Esqueça o departamento. Quais são os passos?

Passo um, você define o fluxo, não um caminho de código, uma jornada em formato de usuário. “Um novo cliente se cadastra, conecta seu calendário, e recebe seu primeiro briefing matinal.” Isso é um fluxo. Tem um começo no qual uma pessoa real começa e um fim que uma pessoa real consegue ver.

Passo dois, você roda o produto real, a coisa deployada, o runtime de fato, não um mock dela. Um teste que stuba a parte que quebra é um teste que passa pela razão errada. O fluxo tem que tocar as mesmas superfícies que um cliente toca.

Passo três, você avalia o resultado com um juiz que nunca escreveu o código. Este é o passo que sustenta tudo, e o que todo mundo pula. O avaliador tem que ser independente, estruturalmente incapaz de dar ao construtor o benefício da dúvida, e tem que avaliar o resultado que o usuário queria, não a linha de código que rodou.

Passo quatro, você registra a lacuna como uma task. Um fluxo que falhou não é uma sensação vaga de que “o produto parece tosco”. É uma lacuna localizada com um endereço: este fluxo, este passo, isto era o que deveria ter acontecido e não aconteceu. Esse endereço é uma task que alguém, ou algo, pode pegar e consertar.

Então o loop fecha e roda de novo. E de novo. Esse é o truque que o modelo de fase perde inteiramente: um loop não tem “uma vez”. Ele roda toda vez que o código muda, para sempre.

QA não é uma fase, é um loop, defina o fluxo, rode o produto real, avalie o resultado com um juiz que nunca escreveu o código, registre a lacuna como uma task. Note que nada nesses quatro passos requer que o loop seja rodado por um humano no fim de um release. Cada passo é algo que um sistema pode fazer, em toda mudança, enquanto o escritório está escuro.

O problema do juiz: por que “adicione um revisor” não é suficiente

Há um atalho tentador no passo três, e vale matá-lo na página porque é o que a maioria das equipes alcança primeiro.

O atalho é: tenha um segundo agent, ou um segundo engenheiro, para dar uma checada dupla no trabalho. Soa como independência. Não é. Um revisor sem mandato adversarial, perguntado “isto parece certo?”, está fortemente inclinado a dizer sim. A mudança é plausível, a tela renderiza, o caminho de demo funciona. Claro, parece certo. Agora duas mentes assinaram embaixo do mesmo ponto cego, e você confundiu uma segunda assinatura com um segundo julgamento.

O fix ingênuo dobra os avaliadores. Ele não muda a pergunta.

O fix de verdade muda a pergunta. Um juiz de QA honesto não é perguntado “isto está certo?” É perguntado “o que o usuário de fato queria aqui, e ele conseguiu?”, e ele avalia contra o resultado declarado do fluxo, não contra o que quer que o código por acaso tenha produzido. Se o fluxo disse “o cliente alcança seu primeiro briefing” e o cliente alcançou uma tela de erro, nenhuma quantidade de testes verdes a montante muda a avaliação. O juiz lê o resultado do jeito que um cliente leria, sem orgulho no trabalho e sem memória de quão difícil foi construir.

Duas regras tornam esse juiz confiável, e ambas são regras que você pode impor num sistema de forma mais confiável que num humano cansado.

Uma afirmação não é um resultado. “Funciona” é uma sensação; “este fluxo exato rodou de ponta a ponta e produziu o que o usuário precisava” é um resultado.

E a segunda regra, a que mantém o loop honesto:

Nunca deixe a mente que fez o trabalho ser a mente que o avalia.

Isso não é um slogan sobre agents. É o princípio mais antigo no controle de qualidade, da manufatura à code review à ciência revisada por pares: o autor é o pior certificador possível do próprio output. A razão inteira de QA existir é mover a avaliação para longe do construtor. Um sistema operacional pode impor essa separação por construção, o juiz é um processo diferente, com um prompt diferente, que literalmente nunca viu o código ser escrito.

Por que isso é trabalho de um OS, não de uma ferramenta

Agora coloque o loop em algum lugar. Aqui é onde “a Apollo pode ser seu departamento de QA” deixa de ser uma metáfora.

Uma ferramenta de QA roda quando você a abre. Você a aponta para um fluxo, você clica em vai, você lê o relatório, você fecha a aba. É uma caixa que você consulta, o que significa que o loop só roda quando um humano lembra de rodar, o que significa que ele roda com menos frequência exatamente quando a equipe está mais ocupada, que é exatamente quando bugs são enviados. A ferramenta herda o problema de fase que deveria resolver. O gargalo nunca desaparece, só se move para a pessoa que tem que lembrar de abrir a ferramenta.

Um OS não espera para ser aberto. Ele tem um scheduler. O mesmo loop, defina, rode, julgue, registre, roda porque o código mudou, não porque alguém lembrou. Um fluxo que importou ontem é re-rodado hoje, automaticamente, contra o produto deployado, e a lacuna que ele encontra aparece como uma task no mesmo lugar onde todo o resto do trabalho vive. A avaliação acontece com um juiz independente por padrão, porque o sistema foi construído para que o escritor e o avaliador nunca sejam o mesmo processo.

Essa é a diferença entre uma ferramenta de QA e um departamento de QA: uma roda quando convocada, o outro roda continuamente e te avisa quando algo quebrou. O departamento sempre foi a continuidade, não as pessoas.

E porque a lacuna chega como uma task, não um relatório, o loop não termina num beco sem saída. Um relatório é lido e esquecido. Uma task é pega, por um engenheiro, ou por um dos writer agents já trabalhando na codebase, consertada, e re-rodada pelo mesmo juiz. O loop que encontrou a lacuna é o loop que confirma o fix. Nada fecha a lacuna afirmando que está fechada; ela fecha quando o mesmo fluxo que falhou agora passa na frente do mesmo juiz independente.

O corpus que não te deixa trapacear

Há mais uma peça, e é a peça que transforma um loop de QA num departamento de QA em que você pode confiar por meses em vez de uma boa tarde.

Um único fluxo é um teste. Uma biblioteca crescente de fluxos é cobertura. O jeito ingênuo de construir essa biblioteca é escrever um conjunto fixo de casos de teste uma vez e dar por feito, o que significa que seu QA só checa as coisas que você já pensou em checar, e nunca a coisa que um usuário real fez que você nunca imaginou. Uma suíte congelada mede o produto de ontem contra a imaginação de ontem.

O jeito melhor: a biblioteca cresce do uso real. Toda vez que um cliente bate num caminho que ninguém antecipou, o input que você não tratou, o fluxo que você não achava que era um fluxo, isso vira uma nova entrada no corpus, e dali em diante o loop o checa para sempre. O produto não pode regredir numa dor real duas vezes, porque na primeira vez que ela apareceu, virou um fluxo que o juiz agora avalia em toda mudança. QA deixa de ser um palpite sobre o que pode quebrar e vira um registro de tudo que já quebrou.

Essa é a propriedade que um departamento de humanos nunca conseguiu segurar bem: ele esquece. Pessoas saem, a memória institucional de “ah, cuidado com esse edge case” sai com elas, e o mesmo bug é enviado de novo dois anos depois. Um loop com um corpus crescente não esquece. O fluxo é a memória.

A virada: QA nunca foi o portão. Era a consciência.

Tire os agents e o scheduler e o que resta é uma pergunta sobre para que QA serve.

Tendemos a pensar em QA como um portão, o checkpoint que um release tem que passar antes de alcançar um cliente. Mas um portão que abre uma vez por release, operado pelas pessoas que construíram a coisa, não está de fato protegendo o cliente. Está protegendo o cronograma. O trabalho mais profundo que QA sempre fez, o que os melhores testers faziam instintivamente e o pior processo enterrava, é ser a consciência da empresa sobre se a coisa de fato funciona para a pessoa que a usa. Não se compilou. Se funcionou.

Essa consciência é importante demais para rodar uma vez, e importante demais para deixar o construtor avaliar. Na maioria das empresas ela vive em uma ou duas pessoas esgotadas que carregam a confiabilidade do produto inteiro na cabeça e clicam por ele à mão na noite antes de cada lançamento. Isso não é diligência. É um ponto único de falha vestido com a fantasia de cuidado.

A promessa não é um executor de testes mais rápido. É que a consciência nunca dorme, nunca se auto-avalia, e nunca esquece um fluxo que viu quebrar. O julgamento mais confiável da empresa para de viver na cabeça de uma pessoa cansada na noite antes do lançamento, e passa a viver num loop que roda toda vez que o produto muda, avaliado por algo que não tem razão para dar ao trabalho o benefício da dúvida.

---

É isso que estamos construindo na Apollo Space: não uma ferramenta de QA que você lembra de abrir, mas um loop que roda a si mesmo, defina o fluxo, rode o produto real, avalie com um juiz que nunca escreveu o código, registre a lacuna como uma task. Se você já enviou um build verde que quebrou no segundo em que um estranho o tocou, você já sabe por que QA nunca deveria ser a mesma mente que construiu a coisa, e por que nunca deveria rodar só uma vez.