O amontoado estava lá
Eu estava testando uma rota de voo em um jogo espacial em desenvolvimento. No caminho havia asteroides, estruturas maiores ao fundo e um efeito que interferia nos sensores da nave. Os testes automáticos diziam que a distribuição dos objetos estava dentro do limite; a sequência renderizada também tinha passado. Mas, durante o voo, eu ainda via aquele amontoado à frente. Algumas partículas pareciam quadradinhos translúcidos, e mal dava para notar o efeito que deveria aparecer ali.
Os testes tinham verificado coisas reais: densidade, alguns enquadramentos, tempo de renderização. Só que nenhuma dessas medidas respondia à pergunta que eu fazia olhando pela cabine: consigo entender o que está à minha frente enquanto jogo?
Quando um teste passa e uma pessoa ainda aponta o mesmo defeito, a pergunta útil não é quem está certo. É o que cada um está vendo.
Contar centros não é ver silhuetas
A checagem de densidade contava posições de objetos no espaço. Vista da cabine, porém, duas formas afastadas podem se sobrepor na projeção da câmera. E não basta comparar uma rocha com outra: uma delas pode ficar bem em cima de um corpo maior ao fundo. Os centros passam na regra de espaçamento; as bordas fazem uma coisa bem diferente na tela.
A investigação passou a medir a distância entre as bordas vistas pela câmera e incluiu as formas grandes do cenário nessa checagem. Também deixou de usar uma captura feita pouco antes ou depois do ponto que eu havia indicado. Bastava a nave avançar um pouco para o alinhamento mudar e esconder justamente o que eu tinha visto.
O teste antigo continuava útil para limitar quantidade. Ele só não podia responder sozinho pela composição visual.
O mesmo percentual, duas cenas
Havia outra diferença escondida em um número. A rotina de captura identificava as imagens pelo valor bruto do efeito. O painel da cabine mostrava esse valor depois de uma atenuação. Por isso, a imagem marcada como o ponto que eu havia indicado mostrava ao jogador um percentual menor. Estávamos comparando duas cenas diferentes como se fossem a mesma.
A revisão passou a escolher as capturas pelo valor mostrado ao jogador. Só então fez sentido guardar uma imagem daquele ponto exato e conferir se as formas ainda se encostavam. O número interno podia estar certo e, mesmo assim, ser a referência errada para reproduzir o que eu tinha visto.
Isso explica por que uma sequência de imagens aparentemente completa podia pular justo o trecho importante. O script escolhia os momentos pelo valor interno, enquanto o número no painel avançava em outro ritmo.
O que ficou medido, e o que ainda precisava de olhos
O registro da revisão relata novas capturas no ponto indicado pelo painel, uma checagem da distância entre as silhuetas e outra para evitar sobreposição com as formas grandes ao fundo. As verificações automáticas voltaram a passar. Se o amontoado reaparecer no mesmo trecho, agora há uma chance maior de o teste perceber.
Ainda faltava jogar de novo. Mesmo depois das correções, o registro pedia outro voo para confirmar se o amontoado tinha desaparecido de verdade. Faz sentido: o teste pode impedir que um defeito medido volte, mas não decide sozinho se a cena ficou clara e agradável de atravessar.
A lição que ficou para mim é que a câmera, o painel e o movimento também fazem parte da especificação do teste. Se eu descrevo um defeito a partir dali, é dali que a verificação precisa começar.