Examiner et évaluer les résultats d’un test par lot
Transformez un test par lot terminé en un examen exploitable. Les évaluations résument la qualité, tandis que les notes conservent la raison pour laquelle une réponse a réussi ou échoué et ce qui doit changer. Un Agen...
Transformez un test par lot terminé en un examen exploitable. Les évaluations résument la qualité, tandis que les notes conservent la raison pour laquelle une réponse a réussi ou échoué et ce qui doit changer.
Un Agent combine des instructions, des paramètres d’interface destinés aux clients, Knowledge, des données de catalogue et des outils facultatifs. Une configuration fiable est testée avec des questions client réalistes avant le déploiement. Les tests doivent couvrir les réponses attendues, les informations manquantes, les scénarios produit, l’escalade et toute interaction facultative que l’équipe a activée.
Avant de commencer
Accès : Ouvrez une exécution de test par lot terminée avec l’autorisation d’examiner les tests de l’Agent.
- Utilisez une exécution terminée avec des résultats stables.
- Gardez le résultat attendu disponible pour chaque cas.
- Convenez de la manière dont l’équipe distingue Bon, Acceptable et Médiocre.
Travaillez dans la plus petite zone responsable décrite ci-dessous et gardez l’état actuel visible pour les clients disponible pendant que vous préparez la modification. Avant de cliquer sur une action finale, confirmez l’entreprise active, l’Agent, la boutique, la langue et le marché affichés dans Humind. Un contrôle manquant peut indiquer un accès en lecture seule ou une capacité qui n’est pas configurée pour cette entreprise. Dans ce cas, consignez la tâche prévue et demandez à un administrateur de vérifier l’autorisation exacte ou la dépendance. Ne contournez pas cette limite en partageant un compte, en copiant des données dans une autre zone ou en promettant une capacité que l’espace de travail n’expose pas.
Flux de travail étape par étape
Examiner la réponse et les éléments de preuve
Lisez la réponse complète, pas seulement sa phrase d’ouverture. Vérifiez si elle répond à la question, respecte les limites et s’appuie sur des informations appropriées de Knowledge ou sur des informations produit.
- Comparez la réponse au résultat attendu.
- Ouvrez les sources pertinentes lorsque le résultat est surprenant.
Appliquer une évaluation cohérente
Utilisez Bon pour une réponse prête à l’emploi, Acceptable pour une réponse utile avec un problème non bloquant, et Médiocre pour une réponse incorrecte, non étayée, dangereuse ou sensiblement incomplète.
- Évaluez l’impact sur le client, et pas uniquement le style rédactionnel.
- Utilisez le même standard pour les cas similaires.
Ajouter une note de diagnostic
Consignez la raison précise et la couche probablement responsable, comme Knowledge, le catalogue, les consignes, la configuration d’outil ou un périmètre non pris en charge. Une note doit rendre l’action suivante évidente.
- Ne citez que l’expression pertinente minimale.
- Indiquez le responsable de la correction ou le test de suivi.
Résumer et exporter
Regroupez les cas médiocres et acceptables par cause racine, puis exportez le rapport lorsqu’il doit être partagé en dehors de l’écran d’examen. Testez à nouveau après des corrections ciblées.
- Donnez la priorité aux échecs répétés qui ont un impact sur les clients.
- Conservez l’exécution d’origine comme preuve avant modification.
Limites importantes et notes de fonctionnement
- Une note agrégée élevée peut masquer un échec grave.
- Les évaluations reflètent le standard convenu des réviseurs et nécessitent un calibrage.
- Modifier une source après l’exécution ne change pas la réponse enregistrée.
- Un rapport exporté constitue une preuve, pas une configuration active.
Vérifier le résultat
- Chaque cas critique a une évaluation et une note de diagnostic.
- Les cas médiocres sont regroupés par couche responsable.
- L’export contient l’exécution examinée plutôt qu’un autre jeu de données.
- Une exécution de suivi est prévue pour les problèmes bloquants corrigés.
Conservez un court enregistrement de ce que vous avez testé, du scénario client utilisé et de ce qui a changé. Cela rend le dépannage ultérieur plus précis et aide un autre membre de l’équipe à reproduire le résultat sans se fier à la mémoire.
Dépannage
Les réviseurs ne sont pas d’accord sur une évaluation
Revenez au résultat client attendu et classez l’impact. Si l’attente elle-même n’est pas claire, corrigez la définition du test avant d’utiliser son évaluation dans une décision de mise en production.
La réponse semble plausible mais n’a aucun fondement
Évaluez explicitement le problème de preuve et examinez la couche source. N’acceptez pas une réponse assurée simplement parce que sa formulation est soignée.