7 Conseils de rédaction de cas de test pour améliorer votre processus de test de logiciel ERP

Les cas de test sont très importants pour assurer la qualité de votre processus de test de logiciel ERP. Ce sont les premières étapes d’un cycle de test et si les cas de test ne sont pas de qualité suffisante, l’ensemble du projet sera “chargé”. Écrire de “bons” cas de test est une compétence qui prend forme simplement en le faisant. Mais il est très pratique d’avoir des idées qui pourraient vous aider. Avec cet article, je veux vous contacter et vous donner des suggestions pour le rendre plus facile, plus amusant et meilleur. Les conseils qui seront donnés concerneront en particulier les cas de test lors des tests d’acceptation des systèmes ERP.

Que sont les cas de test ?

Dans le monde des tests logiciels, il existe de nombreuses définitions de cas de test. Pour cette raison, il est important de nommer notre définition. Dans notre philosophie, les cas de test sont (basés sur la norme IEEE610): “Un ensemble d’entrées de test, de conditions d’exécution et de résultats attendus développés pour un objectif particulier.”Savoir écrire de bons cas de test est extrêmement utile pour tous ceux qui veulent tester. Qu’il s’agisse d’un test fonctionnel, d’un test d’acceptation par l’utilisateur, de tester une application web ou un module d’un système ERP. Dans toutes les situations décrites ci-dessus, les cas de test déterminent dans quelle mesure les résultats donnent un verdict sur les objectifs prédéfinis.

Pourquoi l’écriture de cas de test est-elle si difficile ?

Comme décrit dans la définition, les cas de test aident à guider les testeurs à travers une séquence d’instructions de test pour déterminer si le logiciel répond ou non aux exigences prédéfinies. L’exécution de cas de test nous aide à collecter et à découvrir des informations pour atteindre cet objectif ou cible spécifique. Le premier problème que nous rencontrons directement est la diversité des cibles possibles. Et comme il existe différents types de tests et d’objectifs, il existe différents types de cas de test correspondants.

Un deuxième problème est lié au contenu de l’instruction ou des étapes de test proprement dites. Le niveau de ces instructions dépend du type de testeur qui doit interpréter ces informations et donner un avis. Un testeur professionnel aura besoin d’instructions différentes par opposition à un utilisateur final impliqué dans les tests d’acceptation d’un système ERP

Astuce 1: Déterminez votre objectif et ce que vous souhaitez signaler

Réfléchissez à ce que vous souhaitez signaler, afin de pouvoir déterminer votre objectif dérivé. En l’utilisant comme base, vous avez le contour du scénario de test en vue. Il y a beaucoup d’objectifs différents, où nous devons toujours nous demander ce que nous essayons d’apprendre ou d’atteindre lorsque nous allons exécuter le test. Voici quelques exemples:

• Trouver des défauts: C’est le but classique des tests. Un test est effectué pour exposer les défauts.
• Maximiser le nombre de bugs: La distinction entre “maximiser le nombre de bugs” et “trouver des défauts” est que le nombre total de bugs est plus important que la couverture.
• Bloquer les rejets prématurés de produits : Le but de ce test est de détecter prématurément autant de défauts graves (coups de théâtre) afin que personne ne mette le produit en production.
• Soutenir les gestionnaires dans leurs décisions go / no-go: Les gestionnaires prennent des décisions en fonction des risques. Indications de risque telles que la couverture des tests, l’impact des problèmes détectés, etc. Donnez-leur un meilleur contexte sur lequel fonder leurs décisions.
• Évaluer la conformité selon les spécifications: les spécifications alléguées sont vérifiées pour leur fonctionnement. Toutes les questions qui ne sont pas associées aux spécifications sont ignorées.
• Évaluer la qualité: c’est un objectif difficile, car la qualité est multidimensionnelle. La nature de la qualité dépend de la nature du produit. Pour évaluer la qualité, il convient d’établir des critères clairs, qui sont définis de manière à pouvoir être réellement mesurables.

Les résultats du test tels que dérivés des cas de test fournissent des informations pertinentes directes sur l’objectif.

Astuce 2: réservez suffisamment de temps de conception

Réservez suffisamment de temps pour concevoir vos scénarios de test, afin qu’ils correspondent à vos objectifs. Des cas de test médiocres vous hanteront tout au long du processus de test. Comparaison des résultats des tests, rapports sur plusieurs tours de test, etc. Sont essentiellement déterminés par la qualité de vos cas de test.

Si vous manquez déjà de temps pour concevoir, mais que vous souhaitez tout de même commencer les tests, assurez-vous d’avoir au moins défini les principaux risques. Si 10 testeurs doivent examiner 5 cas de test avec 1 étape de test, cela donnera 50 résultats de test. Peu importe ce que ces 50 résultats donnent plus d’informations sur la qualité que de ne rien faire. Ce ne sera probablement pas exhaustif, mais c’est une première étape. À partir de là, le niveau de détail de certaines parties peut être déterminé.

Nous préférons que vous réfléchissiez bien à l’avance sur la façon dont le test doit être conçu, et que les résultats du test donnent une vraie réponse à l’objectif. Mais en réalité, cela est parfois indiscipliné.

Astuce 3: Nommez le cas de test

Il est important de nommer les cas de test. Dans un test ERP moyen, vous avez facilement plus de 500 cas de test. Vous comprendrez qu’une structure de nom logique améliore la trouvabilité. Dans la littérature est souvent désigné comme un nom complet possible, dans lequel le processus à tester, le module, l’objet, etc. Sont tous inclus dans le nom. Vous pouvez imaginer que fournir 500 cas de test avec un titre aussi complet donne une administration chaotique. Avec une simple feuille Excel, vous perdez facilement un aperçu. Les outils de gestion des tests fournissent une structure à laquelle vous pouvez associer des cas de test à des objets réutilisables, sans qu’ils “polluent” le nom. Vous disposez également d’outils d’enregistrement de test qui organisent ces relations d’une manière différente.

Dans TestMonitor par exemple, nous avons inventé une solution différente. Dans l’outil, vous pouvez définir des étiquettes ou des balises que vous pouvez ensuite lier à des cas de test. Dans TestMonitor, les cas de test sont liés à une ou plusieurs étiquettes de processus métier, de risque, d’exigence ou d’application. Cela permet de regrouper les cas de test et de les récupérer sous différentes perspectives.

Pour le nom d’un cas de test dans TestMonitor, il suffit d’une description claire de l’objectif du cas de test. Pour faire simple, vous décrivez une activité avec une attente implicite.

Exemple de cas de test:
“Résiliation du bail – maison indépendante”
“Créer un client” “Reçu de réservation provisoire”
etc.

Exemple de cas de test “Reçu de réservation provisoire” qui est lié à plusieurs étiquettes:

• processus métier ‘Réception des marchandises’
• exigence ‘Exigence contractuelle’
• risque ‘Risque opérationnel’
• application ‘ERP’

Il est important de décrire le résultat attendu par cas de test. Le testeur sait alors dans quelle direction la “réponse” doit être et obtient directement un cadre de test explicite.

Astuce 4: Description de l’étape du test

Comme décrit dans la définition, les cas de test sont un ensemble d’instructions de test qui nous aident à découvrir des informations pour atteindre un objectif particulier.

Un scénario de test doit avoir un début et une fin clairs pour déterminer si le scénario de test a réussi ou échoué. De plus, un cas de test est composé d’une ou plusieurs instructions ou étapes de test, dans lesquelles plusieurs chemins sont possibles pour obtenir le résultat souhaité. Seul le test de la voie du succès est souvent insuffisant. Dans certaines situations, suivre des chemins sans succès peut simplement faire la différence.

Il est important de définir les étapes de test aussi clairement que possible afin que l’utilisateur final d’un test d’acceptation de l’utilisateur sache exactement ce qu’il doit faire. Bien sûr, il y a des conditions préalables à trouver, comme le testeur de niveau fonctionnel, la connaissance du nouveau système, la connaissance des processus métier ajustés possibles, etc. Mais en substance, tout le monde devrait comprendre toutes les étapes du test.

Supposons que nous décrivions plus en détail le cas de test “Maison indépendante de résiliation de bail” pour un chemin de réussite simple:

1. Sélectionnez une unité et commencez à résilier le bail. Contrôlez s’il existe des conditions préalables parmi lesquelles la résiliation du bail peut / ne peut pas être acceptée et créez un enregistrement de cela.
2. Prenez rendez-vous pour l’inspection finale.
3. Remplissez les données dans l’écran Résiliation du bail. Vérifiez les données du locataire dans la carte de résiliation du bail.
4. Enregistrez la résiliation du bail et envoyez une lettre de conformité. Vérifiez si la lettre de confirmation est arrivée dans les archives numériques.
5. Vérifiez dans le registre des contrats de l’unité que le contrat en cours est résilié, que le contrat résilié est lié à la résiliation du bail et qu’il existe un contrat de vacance nouvellement créé.
6. Vérifiez le nouveau contrat (vacance) en fonction des modèles de politique de location et d’éléments.

Que remarquez-vous?

• Chaque étape de test commence par un verbe
• Suivi d’un sujet
• Concluant par des questions détaillées et éventuellement de contrôle. Vous pouvez choisir de placer les questions de contrôle dans des étapes de test distinctes, mais la pratique montre que la question de contrôle est un raffinement de l’action et que, logiquement, elle sera écrite en tant qu’étape de test.

Dans l’exemple mentionné ci-dessus, on suppose qu’un spécialiste d’un domaine particulier évaluera l’étape de test. Et parce qu’il est un spécialiste, aucune condition d’entrée n’est donnée ni aucune attente explicite esquissée, car le spécialiste a toujours ses propres études de cas dans sa manche et ses attentes sont limpides.

Si vous n’avez actuellement pas de spécialiste, vous pouvez étendre les étapes de test avec des conditions d’entrée et des attentes explicites.

Par exemple, testez l’étape 1 au cas de test “Résiliation du bail – maison indépendante” avec plus de détails.

1. Sélectionnez l’unité “Fleet street 677” et commencez la résiliation du bail. Les conditions garantissent que cette unité ne peut pas être résiliée avant le paiement des arriérés.
2. Etc.

Astuce 5: Pas plus de 10 instructions de test dans 1 cas de test

Nous rencontrons régulièrement des projets de test où > 50 étapes de test sont assignées à un cas de test. C’est trop pour plusieurs raisons:

• Toutes les étapes de test doivent être prises séparément (ou explicitement passées) avant qu’un cas de test n’obtienne un verdict.
• L’évaluation finale d’un cas de test est déterminée par le “pire” score. Il se peut donc que 49 étapes de test soient évaluées comme “bonnes” et une comme “fausse”, ce qui aboutit à un “mauvais” cas de test. La mesure des étapes d’essai doit être similaire. Je veux dire par là que pratiquement chaque étape de test doit être égale à l’effet de l’évaluation. Si vous avez 10 étapes de test que vous devez suivre, y compris 2 petites étapes de test qui sont disproportionnées par rapport aux 8 autres étapes de test, vous devez les reformuler. La même chose s’applique dans l’autre sens avec une étape de test difficile.
• Le testeur se perd rapidement avec trop d’étapes de test dans un scénario de test. Nous n’avons pas fait d’étude scientifique à ce sujet, mais la pratique montre qu’un cas de test ne devrait pas inclure plus de 10 étapes de test. On peut penser à de nombreuses exceptions (contrôles de conversion, etc.), mais en pratique, pour un test d’acceptation utilisateur d’un système ERP, cela fonctionne mieux.
• Il est difficile pour les développeurs de reproduire l’erreur trouvée. Avec de nombreuses étapes de test, le développeur perdra beaucoup de temps à essayer de reconstituer la situation.
• Les rediffusions ou les retestages de cas de test volumineux prennent trop de temps. Lorsqu’un défaut est détecté par un testeur, le cas de test correspondant devra être testé à nouveau. Un nouveau test nécessite que cette étape soit réévaluée, vous voulez éviter les erreurs de régression évidemment. En prenant trop d’étapes de test, vous testez probablement trop. De cette façon, le processus de test prend plus de temps et peut éventuellement surcharger vos testeurs.

À côté de cela, vous avez également des outils d’enregistrement de test qui peuvent présenter les cas de test sous différentes formes au testeur. TestMonitor par exemple a deux vues différentes. TestMonitor dispose d’un écran qui affiche toutes les étapes de test séparément par page et d’un écran dans lequel les cas de test sont présentés par page, y compris toutes les étapes de test.L’avantage du premier affichage est que chaque testeur peut obtenir plus d’informations pour chaque étape de test. L’inconvénient dans le cas où le testeur est plus expérimenté, il doit cliquer sur “suivant” chaque fois qu’il veut passer à l’étape de test suivante. Dans l’autre vue pour chaque cas de test, les avantages et les inconvénients sont l’inverse.

Astuce 6: Revue par un non-concepteur / fournisseur

En pratique, nous voyons régulièrement des scripts de test préparés par les programmeurs du fournisseur de logiciels. Lors de l’examen de ces scripts de test par les éventuels testeurs, il y a généralement plus de questions que de réponses. Inversement, cela fonctionne de la même manière pour les scripts de test préparés par leurs propres employés. Cela donne une réelle valeur ajoutée de les revoir par le fournisseur de logiciels. Ils regardent les scripts de test terminés avec des yeux différents et proposent toujours des ajouts ou des modifications significatifs.

Avec un peu de brainstorming avec les spécialistes des fournisseurs de logiciels et l’organisation cliente, vous vous concentrez rapidement sur l’essence de ce qui doit être testé. Ensuite, prenez le temps d’examiner les cas de test, les scénarios de non-succès et vous verrez que votre modèle de test devient rapidement plus étendu et détaillé. En plus de cela, vous obtenez plus d’informations sur la qualité que vous avez jugée possible.

Astuce 7: TestMonitor

À côté de cela, utilisez une plate-forme de test professionnelle et rendez la qualité vraiment pertinente. Demandez un essai gratuit de TestMonitor dès aujourd’hui et constatez et expérimentez la différence par vous-même.

Si vous êtes un nouveau venu dans le monde des tests, vous êtes facilement submergé par toute la terminologie des tests. Dans cet article, nous allons essayer d’expliquer une partie du jargon que vous pourriez rencontrer dans votre vie de test quotidienne, juste pour rendre tout cela un peu plus compréhensible.

Commencez à tester avec TestMonitor

Vous n’êtes pas encore un utilisateur de TestMonitor ? Un bon test facile est une priorité clé pour les responsables de l’assurance qualité, les gestionnaires de test, les responsables informatiques, les responsables de test et le responsable de la version. TestMonitor rend également les tests faciles et amusants pour les utilisateurs de test.

Alors commençons. Vous voudrez peut-être regarder notre vidéo ou télécharger la notice du produit. Mais bien sûr, avec un essai gratuit, vous pouvez vraiment profiter de la facilité d’utilisation de TestMonitor vous-même.

Restez en contact? Suivez TestMonitor sur Twitter et LinkedIn.