Passar para o conteúdo principal

🧪 Guia de testes: o que testar antes de publicar - Cortex

Assegure a qualidade do seu agente antes de sair para o campo. Descubra o checklist definitivo do que você deve testar no simulador antes de publicar seu fluxo Cortex e aprenda a diagnosticar rapidamente qualquer falha. 🚀

É a checklist fundamental do que há que testar manualmente no simulador antes de publicar um fluxo, junto com o guia de como interpretar e consertar o que falha.

🎯 Por que não é suficiente o "caminho feliz"

O fluxo funcionar quando o cliente responde exatamente o esperado não diz muito. Os problemas reais aparecem quando o usuário sai do roteiro, muda de assunto de forma abrupta ou responde algo ambíguo (o que representa a grande maioria das conversas reais).

⚠️ Atenção: As validações automáticas do sistema cobrem apenas o estrutural. O fluxo compilar corretamente não significa que o nó se comporte bem no nível conversacional ou de negócio.


✅ Checklist antes de publicar

Certifique-se de marcar todos esses pontos no simulador antes de pressionar "Publicar".

🗣️ 1. Conversa

  • Caminho feliz: O cenário típico, de ponta a ponta, termina exatamente onde corresponde.

  • Pergunta ambígua: O nó oferece a interpretação mais provável junto com as alternativas, na mesma mensagem.

  • Mudança de assunto no meio do caminho: O nó transfere para o nó correto ou retoma o fio original sem perder o capturado previamente.

  • Resposta contraditória: O cliente se corrige a si mesmo. O nó deve atualizar o dado e confirmar a mudança.

  • Consulta fora do alcance: O nó declina a solicitação de forma amável (sem inventar informação) e encaminha se corresponde.


🚪 2. Cada saída separadamente

(Isto é o que mais se pula nos testes e o que mais caro sai em produção).

  • Ativação direta: Para cada Nó Fim, teste um caso exato que deveria ativá-lo.

  • Falso positivo: Para cada Nó Fim, teste um caso que está muito perto mas que NÃO deveria ativá-lo.

  • Escalamento para humano: Verifique que dispara apenas quando corresponde e não antes.

  • Sem resposta (Inatividade): Verifique o comportamento do fluxo quando o cliente deixa de responder repentinamente.

💡 Dica de Diagnóstico: Se uma saída se ativa quando não deveria, a condição está mal escrita (muito ampla). Se não se ativa quando deveria, falta reforço no prompt ou a condição é demasiado rigorosa.


📝 3. Dados e classificação

  • Campos obrigatórios: São pedidos no momento exato configurado e o nó não avança sem obtê-los.

  • Campos de captura posterior: Se registram silenciosamente se o cliente os menciona, sem que o nó os pergunte.

  • Mudanças de etapa: A conversa se classifica na etapa correta do funil conforme o conversado.

  • Tipificações e etiquetas: Se aplicam corretamente no sistema quando a condição se cumpre.


🔌 4. Ferramentas e Formatos

  • Invocação correta: Se invoca a ferramenta adequada no momento correto.

  • Parâmetros exatos: Revise no painel de rastreamentos que os argumentos enviados à API/Code Tool sejam os corretos.

  • Comportamento ante falha: Simule um erro de ferramenta e verifique que o nó NÃO mostre o erro de código puro ao cliente.

  • Formatos enriquecidos: Os botões, listas e carrosséis são enviados quando corresponde (não em qualquer momento) e não excedem os limites do canal.

  • Interatividade: Os botões e listas são 100% funcionais e fazem avançar o fluxo ao tocá-los.


🛠️ O que fazer com o que falha (Troubleshooting)

Sintoma no simulador

Causa provável

Onde procurar / O que fazer

A conversa se transfere para o nó errado

Condições de ramificação que se sobrepõem (ambiguidade).

Revise o aviso de similaridade (Seção 3.4).

O nó repete uma pergunta que já estava respondida

Falta a instrução de verificar os campos capturados antes de perguntar.

Adicione a verificação explícita ao prompt (Seção 3.5).

O nó fecha pela saída operativa errada

Ramificações de finalização muito ambíguas entre si.

Consolide Nós Fim ou diferencie melhor os textos (Seção 3.3).

O nó responde bem mas SEM consultar a base de conhecimento

Pode estar usando o conhecimento geral do modelo (que costuma estar desatualizado).

Revise o log de consultas do turno (Seção 4.1).

A tabela dinâmica devolve resultados inesperados

Falta um filtro chave no prompt de busca.

Revise o código SQL gerado nos rastreamentos (Seção 4.2).

O nó envia vários mensagens seguidas

Falta estabelecer o limite de mensageria no prompt.

Revise as regras de estruturação (Seções 10.4 e 10.5).

O formato enriquecido aparece em momentos estranhos

Deixou a descrição de execução padrão sem ajustar ao seu caso.

Especifique quando usá-lo desde a configuração (Seção 6.1).


📈 Quando o simulador não é suficiente

O simulador é excelente, mas testa um caso por vez, e depende inteiramente de que a você (o criador) ocorram todos os cenários possíveis.

Quando é necessário medir com critérios objetivos sobre muitas conversas —ou sobre tráfego real massivo— corresponde utilizar uma avaliação multi-turno (ver seção 7.4).

💡 Recomendação prática: Execute uma avaliação sobre o tráfego real durante as primeiras duas semanas de cada fluxo novo em produção. É exatamente nesse período quando aparecem todos os casos estranhos e usos criativos que ninguém do time antecipou.


Lance seu agente com total confiança! 🚀

O testing rigoroso separa os bots frustrantes das verdadeiras Inteligências Artificiais resolutivas. Ao seguir essa checklist, testar os casos limite e monitorar o tráfego real em suas primeiras semanas, você garante uma experiência de usuário impecável e protege as operações do seu negócio. ✅

Respondeu à sua pergunta?