A IA disse “pronto”. O que você confere antes de entregar?

PARTE 01 / 10

O build passou. A página abriu. A ferramenta encerrou dizendo que está tudo funcionando. Esses são sinais úteis, mas ainda podem deixar de fora o que o cliente vai tentar fazer.

A revisão precisa comparar a entrega com uma situação de uso. Este protocolo ajuda a organizar essa conferência e a registrar uma decisão que outra pessoa consiga entender: seguir, corrigir ou confirmar uma dependência.

Ele não substitui avaliações especializadas de segurança, acessibilidade ou outras exigências do trabalho. Serve para evitar que uma confirmação genérica encerre uma entrega que você ainda não examinou.

PARTE 02 / 10

Escolha a versão e o percurso

Anote endereço, ambiente e uma identificação da versão. Um teste num preview antigo não responde pelo que está no link que você vai enviar.

Depois, descreva uma ação completa. “Testar a landing page” é amplo. “Entrar pelo link, entender as três linhas, selecionar uma e abrir o contato com essa escolha” é um percurso.

Para um sistema, a situação pode ser uma gestora atribuir uma carteira e uma vendedora acessá-la. Para um documento, pode ser alguém localizar uma orientação e conseguir aplicá-la. A forma de verificar acompanha o que você está entregando.

Não tente cobrir todas as possibilidades antes de identificar a jornada principal. Também não trate o primeiro caminho feliz como prova de tudo.

PARTE 03 / 10

Diferencie quatro tipos de evidência

Código ou configuração: mostra o que está implementado ou previsto. Não prova sozinho o comportamento no navegador.

Teste automatizado: verifica as condições cobertas por aquele teste. Um teste com dados sintéticos não confirma produção real.

Captura de tela: registra um estado visual. Não demonstra, sozinha, que seleção, envio, retorno ou permissão funcionam.

Percurso observado: mostra o que aconteceu ao executar passos numa versão e ambiente identificados. Sua força depende de descrever o alcance, não de usar a palavra “validado”.

A revisão fica mais confiável quando essas evidências se complementam. Não precisa desvalorizar testes técnicos para reconhecer que eles têm escopo.

PARTE 04 / 10

Use um exemplo que possa reprovar a entrega

Vamos imaginar uma página fictícia de três linhas de embalagem. O requisito é: selecionar uma linha deve preparar uma mensagem editável com a mesma escolha.

Execute esta sequência:

• Abra a página sem estado salvo e selecione Envelopes.
• Confira o retorno visual e o texto preparado.
• Troque para Saco Zip.
• Confira se a mensagem mudou para Saco Zip.
• Volte, repita com Sacolas e navegue por teclado.
• Abra o destino de contato sem enviar uma mensagem real.

O passo de trocar a seleção é importante. Uma demonstração que só testa a primeira opção pode não revelar que o rascunho ficou preso ao valor inicial.

Agora escolha um erro intencional para o exercício: a opção visível muda, mas a mensagem continua com Envelopes. A entrega deve ser reprovada naquele requisito, mesmo que a página esteja bonita e o link do WhatsApp abra.

Esse erro é uma situação didática, não um defeito observado num projeto real.

PARTE 05 / 10

Registre o problema sem adivinhar a causa

Uma boa anotação separa esperado e observado:

Na versão de revisão, selecionei Saco Zip depois de Envelopes. A seleção visual mudou, mas o rascunho continuou indicando Envelopes. Esperado: a mensagem acompanhar a última opção. Ainda não foi investigada a causa.

Isso permite ao executor reproduzir o comportamento. Você pode ter uma hipótese sobre o estado da aplicação, mas não precisa escrevê-la como diagnóstico confirmado.

A correção deve preservar o que já está aprovado e repetir o percurso depois. Também deve conferir estados próximos: entrada direta, retorno, troca de opção e ausência de seleção.

PARTE 06 / 10

Confirme a informação que acompanha a interação

Um botão pode funcionar tecnicamente e levar a uma condição comercial incorreta. Confira nomes, produtos, preços, prazos, imagens e promessas relevantes.

Se faltar confirmação de uma condição, identifique a pessoa ou fonte que resolve a dependência. Não atribua ao frontend um problema que é de informação. Também não mantenha uma afirmação inventada só porque removê-la exige ajustar o layout.

O mesmo vale para uma prova: um screenshot de demonstração com dados fictícios deve ser identificado. Não o apresente como operação real de um cliente.

PARTE 07 / 10

Em telas pequenas, revise a continuidade

Não olhe apenas a largura da página. Confira se o visitante percebe onde o conteúdo continua e se a ação permanece alcançável ao rolar. Se há leitor interno, veja se o foco e o histórico acompanham a região correta.

Teste a abertura direta de uma página interna. A pessoa que chega por um link de WhatsApp não deveria depender de assistir à apresentação da home para conseguir ler.

Experimente o retorno depois de abrir uma evidência ou outro conteúdo. Você volta ao ponto esperado ou perde o caminho? O que parece detalhe de navegação pode decidir se a leitura será concluída.

Um teste emulado deve ser descrito como emulado. Quando uma condição importante depender de aparelho físico, preserve a pendência em vez de chamá-la de aprovada por semelhança.

PARTE 08 / 10

Organize pendências pelo efeito, não pelo volume

Use três categorias no registro:

Precisa corrigir antes do uso previsto: o problema bloqueia uma ação necessária, apresenta informação enganosa ou viola uma regra relevante.

Precisa confirmar antes de liberar: falta autorização, fonte ou decisão que muda o que será publicado ou executado.

Pode evoluir depois: melhoria que não impede o uso delimitado, desde que esse limite seja aceito.

Uma pendência pequena pode bloquear a entrega inteira se o número do contato estiver errado. Uma lista longa de refinamentos pode não impedir a revisão de um percurso já funcional. A classificação deve explicar a consequência.

PARTE 09 / 10

Termine com uma decisão útil

Evite “99% pronto”. Essa porcentagem raramente diz o que alguém pode fazer com a entrega.

Um registro mais útil seria:

Decisão: corrigir antes de enviar ao cliente. O percurso principal abre, mas a mensagem mantém a primeira linha selecionada. A correção deve atualizar o rascunho e repetir o teste das três opções. O restante da composição aprovada deve permanecer.

Ou, depois da correção e de testes efetivos:

Decisão: disponível para revisão do cliente. O percurso de seleção e abertura do contato foi conferido na versão identificada, em desktop e mobile emulado. O envio real não foi executado. A condição de prazo ainda depende de confirmação antes da publicação final.

Esses textos são modelos. Use somente as condições que você realmente verificou.

PARTE 10 / 10

Entregue também o contexto para continuar

O registro final deve permitir localizar a versão, repetir o percurso e reconhecer a próxima ação. Um link sem essas informações pode obrigar outra pessoa a reconstruir o trabalho.

Na Roldra, revisão e continuidade fazem parte da coordenação do trabalho. O Orchestrator reúne a execução e os registros, enquanto a pessoa responsável dirige prioridades e aceite.

Use o Registro de entrega e correção e o Roteiro de revisão de um percurso desta leitura. Eles foram preparados para um uso simples: localizar, testar, registrar e decidir.

Seu próximo passo: escolha uma entrega e escreva um teste que possa realmente reprová-la. Se qualquer resultado terminaria em “PASS”, você ainda não definiu uma conferência útil.