Concepts de simulation d'appels

Les approches traditionnelles de test et de simulation des centres de contact reposent sur des étapes techniques IDs et des transitions incompatibles avec les modèles naturels d'interaction humaine, ce qui crée un décalage dans les processus de validation. Les fonctionnalités de simulation d'appels de Connect utilisent un modèle de réponse au déclencheur piloté par les événements qui reflète les modèles de cause-and-effect raisonnement naturels utilisés par les ingénieurs d'assurance qualité et les testeurs commerciaux. Cette approche élimine le besoin de connaître chaque interaction programmée afin de tester et de valider l'expérience. Chaque cas de test est construit sous la forme d'une séquence d'observations associée à des actions. Les dépendances entre les observations sont traitées comme des transitions, ce qui crée un flux logique qui correspond au raisonnement humain tout en préservant la précision technique. Les termes suivants sont utilisés dans la configuration du scénario de test :

Observations

Les observations représentent chaque interaction complète qui inclut un événement observé attendu du système et de nombreuses actions visant à valider ou à simuler les comportements du système.

Événements

Les événements représentent les comportements attendus du système, tels qu'une invite, un message de bot ou un appel Lambda.

Actions

Les actions représentent ce que le framework de test doit faire en réponse à un événement, par exemple envoyer du DTMF, répondre par du texte, affirmer des valeurs d'attribut ou terminer le test.

Acteurs

Les acteurs représentent les rôles à jouer dans le cadre de test. Lors de l'observation d'événements, les acteurs peuvent être le système ou l'agent, comme une invite de jeu provenant du système ou un agent acceptant l'appel. Lors de la simulation d'actions, les acteurs peuvent être le client, le système ou l'agent, par exemple en simulant un DTMF ou un énoncé saisi par le client, ou en simulant une réponse du système à partir d'une fonction Lambda.

Groupes d'interaction

Utilisez des groupes d'interaction pour créer des interactions simulées avec le centre d'appels. Chaque groupe d'interaction comporte trois étapes définies, décrites dans les blocs suivants :

Observez

Pour chaque groupe d'interaction, vous devez configurer un bloc d'observation afin de valider l'interaction attendue du système. Vous pouvez observer quatre types d'événements : le test lancé, le message reçu, l'action déclenchée et le test terminé.

Note

Observe ne prend actuellement en charge que les messages reçus en anglais. Les messages reçus dans d'autres langues ne sont pas pris en charge pour le moment et provoqueront l'échec du bloc d'observation lors de l'exécution du test.

Vérifiez

Ce bloc est facultatif et est utilisé pour valider les métadonnées telles que les attributs définis par l'utilisateur, les attributs système et les attributs de segment. Vous pouvez valider plusieurs attributs dans le bloc à cocher.

Actions

Ce bloc est facultatif et permet de remplacer des actions, de remplacer des ressources, d'envoyer des instructions ou de tester des actions de contrôle. Vous pouvez utiliser des ressources de remplacement telles que Lambda, Lex, Queue ou Hours of Operation par des ressources alternatives ou remplacer des actions par des valeurs de réponse issues d'actions associées. Vous pouvez valider l'expérience de contact sans faire appel à des ressources externes pour accélérer l'exécution des tests et empêcher toute manipulation réelle des données, par exemple en empêchant la réexécution d'un bloc Lambda débité par carte de crédit dans un environnement de production. Vous pouvez utiliser les instructions d'envoi pour simuler une entrée à envoyer à l'expérience du centre d'appels, telle qu'un texte/un énoncé, une tonalité DTMF ou un fichier .wav pour un son préenregistré. En outre, vous pouvez utiliser des types d'actions de contrôle de test pour enregistrer les données et mettre fin à l'exécution du scénario de test à tout moment.