Vous avez enfin installé Tricentis Tosca Commander et vous êtes prêt à automatiser vos tests ? Évitez les cinq pièges suivants, fréquents chez les débutants avec Tosca. Vous réduirez ainsi vos coûts de maintenance à long terme.
Alors commençons tout de suite !
1. Création de cas de test sans structure
Bien qu'il soit possible de scanner rapidement les modules et de les glisser-déposer dans votre nouveau cas de test, essayez de conserver une structure qui le rende lisible. Il y a fort à parier que vous ne serez pas la seule personne à gérer votre cas de test.
Il est recommandé de définir au moins trois dossiers dans le cas de test : Préconditions, Processus et Postconditions.
Les préconditions doivent contenir toutes les étapes de test préparatoires, telles que le chargement des données de test ou l'initialisation des tampons. Le dossier Process doit contenir uniquement le flux de travail à tester. Enfin, les postconditions peuvent contenir les étapes de test nécessaires au nettoyage après l'exécution du flux de travail ou à la mise à jour de l'état des données de test.
2. Création de grands modules
Dans Tosca, un module représente techniquement un ensemble de contrôles d'un écran. Lors de l'analyse du système testé (SUT), vous ajoutez des contrôles au module sous forme d'attributs. Cependant, un site web ou un formulaire peut contenir de nombreux contrôles. Si vous les ajoutez tous au module, vous risquez d'avoir des difficultés à retrouver le contrôle souhaité ultérieurement.
Essayez de répartir logiquement les commandes existantes en différentes sections de l'écran. Par exemple, vous pouvez conserver la barre de menu supérieure dans un module séparé.
La plupart du temps, vous pouvez réutiliser des modules avec des éléments de menu pour plusieurs écrans ; les conserver dans un module central facilite la maintenance.
3. Ne pas considérer vos étapes de test comme maintenables
Créer des étapes de test est simple : il suffit de glisser-déposer des modules dans le cas de test. Ensuite, vous renseignez les valeurs des étapes et le tour est joué ! Pas tout à fait. Il est très utile de renommer les étapes de test créées avec un nom descriptif, comme « Cliquer sur le bouton xy ». Cela contribue grandement à la lisibilité du cas de test et, à terme, à sa maintenance.
Conseil supplémentaire : Bien qu’il soit possible d’assigner plusieurs actions à une même étape de test, il est conseillé de créer une étape de test distincte pour chaque action. Le cas de test reste ainsi plus lisible et le fait d’avoir des actions par étape facilite les futures modifications du flux de travail.
4. Création de cas de test sans vérification
Vous avez donc terminé l'intégralité du flux de travail du cas de test et tout fonctionne correctement. Tout semble correct, puisque vous souhaitiez simplement que le flux de travail s'exécute sans problème. Par conséquent, aucune vérification supplémentaire n'est nécessaire, n'est-ce pas ?
Non, même si votre flux de travail s'exécute correctement, il vise généralement un objectif précis. Imaginez que vous ayez une boutique en ligne et que vous souhaitiez tester le processus de paiement. Si la sélection et l'ajout d'articles au panier fonctionnent correctement, comment être sûr que l'ajout des articles au panier a bien fonctionné ? Il vous faudra vérifier le contenu final du panier.
Chaque cas de test doit viser un objectif précis, et cet objectif doit être vérifié. Par conséquent, intégrez des étapes de vérification dans votre cas de test.
5. Sur-vérification des éléments dans un cas de test
C'est l'inverse de l'erreur précédente. Normalement, il est important de vérifier de nombreux éléments au sein de votre application. Prenons à nouveau l'exemple du processus de paiement de notre boutique en ligne. Vous devez vérifier que tous les articles sélectionnés figurent bien dans le panier. De plus, le total des articles doit être correct et certaines réductions doivent être vérifiées et correctement calculées dans le panier.
Bien qu'il soit pratique et rapide de tout vérifier dans un seul cas de test, l'interprétation des résultats après une exécution de test de régression s'avérera complexe. Un échec de vérification indiquera simplement qu'un élément ne fonctionne pas. Or, comme votre cas de test couvre de nombreux points de vérification, il est impossible de localiser précisément le problème. Par exemple : que signifie le fait que certaines vérifications échouent et d'autres réussissent ? Peut-on encore se fier aux vérifications réussies ? Qu'est-ce que cela révèle sur la couverture de test de votre application ?
Créer un cas de test axé sur une vérification spécifique vous permettra d'identifier directement l'origine du problème, sans avoir à analyser en profondeur l'exécution du test. C'est possible grâce à la conception de cas de test dans Tosca.
Cependant, il ne s'agit que d'une règle générale. Multiplier les cas de test impacte la vitesse d'exécution globale, ce qui peut s'avérer crucial. Il est donc souvent nécessaire de trouver un juste milieu.
Conclusion
Dans cet article, nous avons abordé l'importance de la structure et de la dénomination dans vos cas de test, examiné la création de modules et ce qui doit figurer dans un cas de test
Les 5 erreurs courantes commises par les débutants en Tosca, décrites ici, peuvent être facilement évitées et vous permettront de créer des cas de test beaucoup plus faciles à maintenir.
N'hésitez pas à laisser un commentaire si vous êtes d'accord ou non. Avez-vous des conseils à partager ?
Vous avez peut-être besoin de plus de personnel pour créer votre ensemble de tests de régression ? N'hésitez pas à nous contacter ou à me contacter directement. Vous souhaitez approfondir vos connaissances ? Découvrez alors notre offre de formation.
