Pourquoi les testeurs métier ont besoin d'autres cas de test
Un test système est fait par des personnes qui ont construit le système ou le connaissent bien. Un test d'acceptation utilisateur est fait par des personnes qui l'utilisent : elles connaissent le travail, pas le paramétrage. Elles ne savent pas quel champ est nouveau, quel flux tourne en arrière-plan, ni ce que le développeur voulait dire.
Un cas de test UAT doit donc fonctionner pour quelqu'un qui :
- connaît le processus métier par cœur, mais pas les nouveaux écrans ;
- a quelques heures entre deux autres tâches, pas une semaine ;
- ne devrait jamais avoir à deviner si une étape a réussi ou échoué ;
- s'arrêtera et attendra quand une étape n'est pas claire, et perdra du temps.
Chaque heure passée sur des cas de test clairs en fait gagner beaucoup pendant les journées de test : moins de questions, moins d'anomalies qui s'avèrent être des malentendus, et des résultats fiables au go/no-go.
À partir des user stories et des processus
Les cas de test viennent de deux sources, et il vous faut les deux.
Les user stories et leurs critères d'acceptation
Une user story dit ce que quelqu'un veut faire et pourquoi : En tant que commercial, je veux convertir un lead qualifié, afin d'obtenir un compte, un contact et une opportunité. Ses critères d'acceptation disent quand elle est terminée. Chaque critère d'acceptation est candidat à devenir une étape ou un cas de test.
Vérifiez la couverture : chaque user story du périmètre a besoin d'au moins un cas de test. Une story sans cas de test est un trou, et les trous se découvrent en production.
Les processus métier, de bout en bout
Les user stories sont découpées finement pour les développeurs. Le métier, lui, travaille en processus qui traversent de nombreuses stories : lead-to-cash, du devis à la commande, gestion des requêtes de l'email à la résolution. Une story peut réussir seule alors que le processus casse au passage de relais entre deux équipes.
Ajoutez donc des cas de test de bout en bout qui suivent un processus du début à la fin, à travers les rôles : le commercial fait le devis, le manager l'approuve, la commande part à la finance. Ce sont souvent les cas de test qui comptent le plus pour le métier.
Dans UAT StudioLisez les user stories depuis Jira ou Azure DevOps dans la carte User stories, et cochez Only stories without test cases pour voir les trous. Avec le module AI test design, l'IA propose des cas de test à partir de vos stories ou d'une description de processus, y compris sur le propre modèle de votre entreprise. Rien ne devient un cas de test tant que vous ne l'avez pas validé. Sans le module, Prepare with your own AI fournit un prompt à coller dans l'IA de votre entreprise ; les étapes marquées [CHECK] sont des hypothèses à vérifier.
Un objectif par cas de test
Un cas de test teste un scénario métier, avec un seul objectif. Son titre dit ce que le testeur accomplit, avec les mots du métier :
- Convertir un lead avec un compte existant
- Approuver un devis avec une remise supérieure à 20 %
- Router un email d'un client connu vers la bonne file d'attente
Pas Tester l'objet Lead, ni Leads, opportunités et devis. Quand un cas de test a plusieurs objectifs, un échec les bloque tous, et le résultat en dit peu : qu'est-ce qui a échoué, et qu'est-ce qui fonctionne encore ?
Quelle taille pour un cas de test ?
En règle générale, un cas de test compte entre trois et quinze étapes, et prend à un testeur de cinq à vingt minutes. Beaucoup plus long, il a probablement plus d'un objectif : découpez-le. Beaucoup plus court, il a peut-être sa place avec un cas voisin.
Les cas de test de bout en bout sont l'exception. Ils suivent tout un processus et peuvent être plus longs. Gardez-les, mais veillez à ce que chaque partie du processus ait aussi son propre cas de test plus court, pour qu'un échec soit facile à situer.
Des étapes avec un résultat attendu
Chaque étape a deux parties : une action (ce que fait le testeur) et un résultat attendu (ce qui doit se passer). C'est le résultat attendu qui rend une étape testable. Sans lui, le testeur décide de ce qui est suffisant, et deux testeurs décident différemment.
Rédiger l'action
- Une action par étape. Ouvrez le lead et cliquez sur Convertir, c'est bien ; cinq clics dans une étape, non.
- Commencez par un verbe : ouvrez, cliquez, renseignez, choisissez, enregistrez.
- Utilisez les libellés tels qu'ils apparaissent à l'écran, en gras ou entre guillemets.
- Dites quoi faire, pas comment le système fonctionne à l'intérieur. Enregistrez le devis, et non déclenchez le flux d'approbation.
Rédiger le résultat attendu
- Dites ce que voit le testeur : un message, une valeur dans un champ, un nouvel enregistrement, un statut.
- Soyez précis. L'opportunité est à l'étape Qualification, et non ça marche.
- Indiquez ce qui ne doit pas se produire quand c'est important : Aucun deuxième compte n'est créé.
- Pour ce que le système fait tout seul, dites où regarder : La requête apparaît dans la file d'attente Benelux Support en moins d'une minute.
Données de test et rôles
Données de test
Les testeurs perdent plus de temps à chercher des données que sur toute autre partie d'une UAT. Mettez les données dans le cas de test partout où elles comptent : quel client, quel produit, quelle liste de prix ou quel catalogue de prix, quel montant. Préparez ces données dans l'environnement de test avant la première journée de test.
- Utilisez des noms qui sont clairement des données de test, comme Jansen Logistics (test).
- Donnez à chaque testeur ses propres enregistrements quand il modifie des données, pour que deux personnes ne modifient pas la même opportunité.
- Ajoutez des valeurs limites : une remise juste en dessous et juste au-dessus du seuil, un champ obligatoire vide.
- N'utilisez pas de vraies données personnelles de clients quand vous pouvez l'éviter.
Rôles
Dans un CRM, ce qu'un utilisateur peut voir et faire dépend de son rôle : un profil et des ensembles d'autorisations dans Salesforce, des rôles de sécurité et une division dans Dynamics 365. Une UAT prouve que chaque rôle peut faire son travail, et uniquement son travail. Chaque cas de test indique donc quel rôle le teste, et le testeur se connecte avec un utilisateur de test qui a exactement ce rôle.
Ne testez jamais avec un administrateur. Un administrateur voit tout et peut tout faire, si bien que les problèmes qu'une UAT doit trouver restent cachés.
Dans UAT StudioChaque étape a une action, un résultat attendu et éventuellement des données de test. Chaque testeur reçoit un Test role et un Test account, affichés en haut de ses tests sous la forme Log in as …, et le rôle apparaît à côté de son nom sur chaque anomalie qu'il enregistre.
Priorité et risque
Il n'y a jamais assez de temps pour tout tester aussi bien. Marquez chaque cas de test pour que les plus importants soient testés en premier, et terminés même quand le temps manque.
| Priorité | Ce que cela signifie | Exemple |
|---|---|---|
| Must | Doit fonctionner dès le premier jour. S'il échoue, la mise en production est menacée. | Créer et envoyer un devis ; router une requête vers la bonne file d'attente. |
| Should | Important, mais le métier peut vivre avec un contournement pendant une courte période. | Un tableau de bord pour le directeur commercial. |
| Could | Souhaitable. Testé quand il reste du temps. | Une vue de liste triée par région. |
Ajoutez le risque à côté : ce que cela coûte si cela tourne mal après la mise en production. Un prix faux sur une facture est un risque élevé ; un libellé faux sur un rapport, un risque faible. À priorité égale, les testeurs commencent par le risque élevé.
Soyez strict avec Must. Quand la moitié des cas de test sont Must, l'étiquette ne veut plus rien dire : réservez-la à ce dont le métier ne peut pas se passer. Convenez des priorités avec les responsables des processus : ce sont eux aussi qui décident au go/no-go, où les cas de test Must qui n'ont pas réussi pèsent le plus.
Dans UAT StudioDéfinissez Priority (Must, Should, Could) et Risk (High, Medium, Low) dans l'éditeur ou dans une colonne lors de l'import. Les valeurs d'autres outils sont aussi lues : Critical et High deviennent Must, Medium et Normal Should, Low Could. Les testeurs voient d'abord leurs cas de test Must, avec le risque élevé en premier dans chaque priorité.
Un exemple
Cas de test 12 : Approuver un devis avec une remise supérieure à 20 %
Priorité Must, risque High. User story CRM-118. Rôle : commercial (étapes 1 à 3) et directeur commercial (étapes 4 et 5).
| Étape | Action | Résultat attendu | Données de test |
|---|---|---|---|
| 1 | Ouvrez l'opportunité et créez un nouveau devis. | Un devis s'ouvre, lié à l'opportunité, avec ses produits. | Opportunité Jansen Logistics – Support |
| 2 | Fixez la remise à 25 % et enregistrez. | Le devis est enregistré. Il affiche le statut Approbation requise. | Remise 25 % |
| 3 | Essayez d'envoyer le devis au client. | L'envoi n'est pas possible. Un message indique que le devis doit être approuvé. | |
| 4 | Connectez-vous en tant que directeur commercial et ouvrez la demande d'approbation. | La demande affiche le devis, la remise et le commercial. | Utilisateur de test Directeur commercial Benelux |
| 5 | Approuvez la demande. | Le devis affiche Approuvé, et le commercial reçoit un email. |
Notez ce qui fait que cela fonctionne : un seul objectif dans le titre, une action par étape, un résultat attendu que le testeur peut vérifier, les données et le rôle nommés, et un cas d'échec à l'étape 3. Ajoutez un deuxième cas de test pour une remise sous le seuil, qui ne devrait pas nécessiter d'approbation.
Erreurs courantes
- Pas de résultat attendu, ou fonctionne comme prévu. Le testeur doit deviner ce qui était attendu.
- Un langage technique. Des noms de champs de la base de données, des noms d'objets, ou vérifiez que le trigger se déclenche. Utilisez les mots de l'écran.
- Trop d'objectifs dans un cas de test. Un échec bloque le reste, et le résultat vous apprend peu.
- Uniquement le cas nominal. Ajoutez un champ obligatoire laissé vide, une valeur au-dessus d'un seuil, un utilisateur qui ne devrait pas voir un enregistrement.
- Des données de test manquantes. Ouvrez une opportunité : laquelle ? À quelle étape, avec quels produits ?
- Pas de rôle. Le testeur utilise le compte qu'il a, souvent un compte avec trop de droits.
- Copié du test système. Écrit pour des développeurs, avec des étapes que les testeurs métier ne peuvent pas suivre.
- Tout est Must. Alors plus rien ne l'est, et les tests importants ne sont pas faits en premier.
- Écrit une fois, jamais relu. Les scripts que personne n'a vérifiés avant les journées de test sont pleins d'anciens libellés et de menus erronés.
Faites-les relire par un utilisateur clé
Avant les journées de test, demandez à un utilisateur clé du métier de lire les cas de test et d'en essayer deux ou trois dans l'environnement de test. Il trouve ce que le rédacteur ne voit pas : une étape qui suppose des connaissances, un libellé qui a changé, un processus qui se déroule autrement dans un autre pays.
Vérifiez en même temps que chaque user story du périmètre a un cas de test, que chaque rôle du périmètre teste quelque chose, et que les données de test existent. Puis conservez les cas de test après la mise en production : ce sont vos tests de non-régression pour la prochaine release CRM.
Dans UAT StudioImportez des cas de test depuis Excel, Azure DevOps, Jira avec Xray ou Zephyr Scale, ou TestRail, ou rédigez-les dans l'éditeur. La bibliothèque de modèles, une option de chaque formule payante, contient des scripts prêts à l'emploi pour Salesforce et Dynamics 365, à adapter à votre propre configuration.
Libre d'utilisation
Pour tout le reste à organiser avant, pendant et après l'UAT, voir la checklist UAT pour une mise en production CRM, également en fichier Excel gratuit.