08 Teste e revisão
O esperado.
O que aconteceu.
Um teste aproxima essas duas descrições. A revisão começa na diferença que você consegue observar.
Testar, corrigir e compreender o resultado
A diferença indica o que investigar.
01 / Teste e revisão
Antes de testar, diga o que espera.
Testar é realizar uma ação em condições descritas e comparar o que aconteceu com o que deveria acontecer. Para que a comparação seja útil, o resultado esperado precisa estar definido antes. Caso contrário, qualquer comportamento pode acabar sendo explicado como aceitável depois que aparece.
Na atividade de 14/09, a orientação era melhorar uma parte do projeto já existente, testar novamente e pedir a tentativa de um colega. Esse recorte evita que uma revisão ampla apague decisões ou introduza funções que ainda não foram examinadas.
No jogo fictício, podemos escrever o caso principal: “Com a rodada aberta, digitar a resposta correta. Esperado: a rodada termina e a explicação aparece”. Um caso de limite examina uma fronteira da regra: “Depois de duas respostas incorretas, enviar a terceira resposta incorreta. Esperado: nenhuma tentativa permanece, a palavra é revelada e a rodada termina”.
O resultado observado descreve o que você realmente viu. Se o jogo permitir uma quarta tentativa, registre esse comportamento sem inventar sua causa. “O contador ficou em zero e o campo continuou aceitando respostas” é uma descrição mais útil do que “o sistema está todo quebrado”.
Para pedir correção, reúna os passos, a entrada utilizada, o resultado observado e a regra esperada. Peça uma mudança pequena e indique o que deve permanecer. Depois, repita o caso que falhou e teste uma ação relacionada que já funcionava. Esse segundo exame é chamado de teste de regressão: procura verificar se a correção introduziu um problema em outra parte.
A mensagem “corrigido” da IA não substitui essa execução. Da mesma forma, uma lista de testes escrita pela IA é um plano, não um relatório do que aconteceu. Se a ferramenta não executou um caso, o resultado deve continuar marcado como pendente.
O teste precisa mostrar uma diferença.
Este pequeno programa simula duas versões de uma rodada fictícia. Os resultados se referem somente à demonstração abaixo.
Encerrar após o terceiro erro e apresentar a palavra com sua explicação.
Ainda não executado.
Trocar a versão ou o caso limpa o resultado observado. Testar o acerto e o reinício ajuda a conferir o que deveria ter sido preservado.
02 / Teste e revisão
Quando a prévia não abre.
Quando a prévia não abre
Uma falha pode impedir que você chegue ao projeto. Nesse caso, copie a mensagem de erro, registre a última ação e chame o professor. O problema pode envolver acesso, serviço ou código; não escolha uma causa sem evidência.
O modelo M15 inclui um pedido específico para investigar essa situação antes de alterar o projeto. Se o acesso continuar indisponível, desenhe as telas ou estados e peça a um colega que simule a sequência. Esse registro ajuda a revisar o plano. Identifique o que foi simulado e o que ainda precisa ser executado na aplicação.
03 / Teste e revisão
Uma pessoa encontra o caminho?
Observar outra pessoa usando
O teste com um colega acrescenta algo que o teste do código não revela: ele permite observar se a pessoa encontra o que precisa, entende o comando e sabe continuar. Dê uma tarefa concreta, como “Comece uma rodada e tente responder”, e observe antes de explicar o caminho.
Se houver dificuldade, registre em que ponto ela apareceu e a ajuda oferecida. Pergunte o que a pessoa entendeu. Um clique correto pode ocorrer por tentativa e erro; para investigar compreensão, é necessário ouvir uma explicação ou observar uma aplicação do que foi estudado.
No exemplo do jogo, terminar uma rodada demonstra que foi possível chegar ao fim naquela condição. Para investigar se a diferença entre modelo e prompt foi compreendida, peça que a pessoa explique a diferença com um exemplo próprio. Essa pergunta é distinta de “você gostou do jogo?”.
04 / Teste e revisão
Testar também os casos difíceis.
Aprofundamento: procurar falhas nos agentes
Red team é o nome usado no guia de agosto para uma busca deliberada de falhas com situações difíceis. Além do pedido esperado, um agente pode receber uma pergunta ambígua, uma premissa falsa, uma referência inexistente ou um pedido para ignorar suas regras.
O objetivo é observar o comportamento e revisar o projeto. Use casos fictícios para informações pessoais ou situações sensíveis; não é necessário expor dados reais para descobrir que um agente os pede indevidamente. Instruções escritas dentro de uma fonte também devem ser tratadas como conteúdo a examinar, não como autorização para mudar a tarefa.
O modelo M14 conserva as duas frentes do guia: casos que procuram falhas e observação de uma pessoa usando o projeto. Elas respondem a perguntas diferentes e não devem ser reunidas em uma aprovação automática.
Prática: guardar um teste que possa ser repetido
Escolha uma ação, anote o esperado e execute. Registre os passos e o observado. Se pedir uma correção, repita o caso e uma ação relacionada; depois, convide um colega a tentar.
Guarde a versão testada, uma captura ou outro registro, o que mudou e o que continua pendente. Na entrega de 14/09, cada estudante deveria escrever sua contribuição e entregar sua cópia do registro, mesmo quando o projeto era compartilhado. Essa condição pertence à atividade original; esta prática de retomada não cria um novo prazo de entrega.
