Transforme um teste em lote concluído numa revisão acionável. As classificações resumem a qualidade, enquanto as notas preservam por que motivo uma resposta passou ou falhou e o que deve mudar.

Um Agent combina instruções, definições de interface voltadas para o cliente, Knowledge, dados de catálogo e ferramentas opcionais. Uma configuração fiável é testada com perguntas realistas de clientes antes da implementação. Os testes devem abranger respostas esperadas, informação em falta, cenários de produto, escalamento e qualquer interação opcional que a equipa tenha ativado.

Antes de começar

Acesso: Abra uma execução de teste em lote concluída com permissão para rever testes do Agent.

• Utilize uma execução concluída com resultados estáveis.
• Mantenha disponível o resultado esperado para cada caso.
• Acordem como a equipa distingue Bom, Aceitável e Fraco.

Trabalhe na menor área responsável descrita abaixo e mantenha disponível o estado atual voltado para o cliente enquanto prepara a alteração. Antes de clicar em qualquer ação final, confirme a empresa ativa, o Agent, a loja, o idioma e o mercado apresentados no Humind. Um controlo em falta pode indicar acesso só de leitura ou uma capacidade que não está configurada para esta empresa. Nesse caso, registe a tarefa pretendida e peça a um administrador para rever a permissão ou dependência exata. Não contorne este limite partilhando uma conta, copiando dados para outra área ou prometendo uma capacidade que o espaço de trabalho não disponibiliza.

Fluxo de trabalho passo a passo

1. Rever a resposta e as evidências

   Leia a resposta completa, não apenas a frase inicial. Verifique se responde à pergunta, respeita os limites e se baseia em informação adequada do Knowledge ou em informação do produto.

   • Compare a resposta com o resultado esperado.
   • Abra o material de origem relevante quando o resultado for surpreendente.

2. Aplicar uma classificação consistente

   Utilize Bom para uma resposta pronta, Aceitável para uma resposta útil com um problema não bloqueante e Fraco para uma resposta incorreta, sem suporte, insegura ou materialmente incompleta.

   • Classifique o impacto no cliente, não apenas o estilo de escrita.
   • Use o mesmo padrão em casos semelhantes.

3. Adicionar uma nota de diagnóstico

   Registe o motivo específico e a camada provavelmente responsável, como Knowledge, catálogo, orientação, configuração de ferramenta ou âmbito não suportado. Uma nota deve tornar óbvia a ação seguinte.

   • Cite apenas a expressão mínima relevante.
   • Indique o responsável pela correção ou o teste de seguimento.

4. Resumir e exportar

   Agrupe os casos fracos e aceitáveis por causa raiz e, em seguida, exporte o relatório quando este precisar de ser partilhado fora do ecrã de revisão. Volte a testar após correções direcionadas.

   • Dê prioridade a falhas repetidas com impacto no cliente.
   • Mantenha a execução original como prova anterior à alteração.

Limites importantes e notas de operação

• Uma classificação agregada elevada pode ocultar uma falha grave.
• As classificações refletem o padrão de revisão acordado e precisam de calibração.
• Alterar uma fonte após a execução não altera a resposta registada.
• Um relatório exportado é prova, não uma configuração ativa.

Verificar o resultado

• Cada caso crítico tem uma classificação e uma nota de diagnóstico.
• Os casos fracos estão agrupados por camada responsável.
• A exportação contém a execução revista em vez de um conjunto de dados diferente.
• Está planeada uma execução de seguimento para problemas bloqueantes corrigidos.

Mantenha um registo curto do que testou, que cenário de cliente utilizou e o que mudou. Isto torna a resolução de problemas posterior mais precisa e ajuda outro membro da equipa a reproduzir o resultado sem depender da memória.

Resolução de problemas

Os revisores discordam de uma classificação

Volte ao resultado esperado para o cliente e classifique o impacto. Se a própria expectativa não for clara, corrija a definição do teste antes de utilizar a sua classificação numa decisão de lançamento.

A resposta parece plausível mas não tem suporte

Classifique explicitamente o problema de evidência e investigue a camada de origem. Não aceite uma resposta confiante apenas porque a sua formulação é polida.

Guias relacionados

• Criar e executar um teste em lote
• Resolver uma resposta incorreta ou não suportada
• Configurar uma base de Knowledge fiável
• Compreender as métricas do Analytics e a atribuição no Humind