Cinq erreurs de débutants dans la conception de tests automatisés. Vous lisez probablement ceci parce que vous êtes intéressé par la conception de tests automatisés ou simplement parce que vous travaillez avec cette technologie. Mais avant de passer en revue ces cinq erreurs de débutant, permettez-moi d’abord de vous recommander de toujours vérifier le fournisseur de technologie. Les « tests » en général ont beaucoup évolué au cours des deux dernières années. À partir d’un modèle, vous pouvez bien sûr générer une suite de tests complète, mais vous pouvez également générer directement des scripts de test exécutables de manière entièrement automatique. Je ne suis pas là pour en parler, mais c’est vraiment une recommandation : Vérifiez la technologie de votre fournisseur 🙂
Commençons par nos cinq erreurs de débutants.
1. PARTIR DE RIEN
Je sais qu’une nouvelle technologie est toujours amusante et que certains d’entre vous veulent se lancer dans cette nouvelle façon de travailler. Après avoir été frustré par la rédaction de tonnes de documents Word pour les tests manuels, vous souhaitez consacrer du temps à la modélisation à partir de zéro.
Mais posez-vous toujours la question :
Que puis-je réutiliser pour être plus rapidement sur la bonne voie ?
Parce que oui, nous pouvons réutiliser les actifs des tests et des exigences !
Par exemple : diagrammes Visio, enregistrements, cas de test manuels existants, plans de test, fichiers WSDL, diagrammes BPMN, etc.
Ne perdez donc pas votre temps à retravailler quelque chose que vous avez déjà fait. Au lieu de cela, importez-la !
2. MODÉLISATION TROP DÉTAILLÉE DES INTERFACES
La modélisation en général est fascinante. Dans un langage simple, vous pouvez exprimer toutes les interfaces que votre application fournit pour les tests. Mais réfléchissez bien : Voulez-vous vraiment modéliser tous les détails possibles et imaginables ? Mon deuxième conseil est donc le suivant :
Penser AGILE
Ne ciblez que les interfaces les plus importantes de votre application : qu’est-ce qui apporte le plus de valeur ? Dites-vous que si vous avez le temps, vous améliorerez votre diagramme et entrerez dans les détails plus tard. Ne pas tout cibler. N’oubliez pas que 20 % de votre travail apportera 80 % de la valeur. Et les 80 % sont encore bien meilleurs que l’ancienne méthode de travail !
3. L’UTILISATION EXCESSIVE DE DONNÉES COMBINATOIRES
Ce point est une chose que je vois souvent. Vous disposez d’un grand nombre de données possibles que vous souhaitez tester. Souhaitez-vous vraiment tester vos 500 identifiants et mots de passe dans le cadre de tests fonctionnels ? Êtes-vous vraiment intéressé par l’exécution de tests qui testent toutes les combinaisons de vos 4 champs de formulaire qui peuvent chacun avoir l’une des 10 valeurs possibles ? En d’autres termes :
Voulez-vous vraiment exécuter 10 000 tests possibles ?
Oui, cela peut sembler drôle quand vous lisez ceci, mais beaucoup de nouveaux utilisateurs font cela. Essayez donc toujours de prendre une valeur qui a du sens et de ne pas tester toutes les valeurs que vous pouvez tester. Il faut toujours se poser des questions à ce sujet. Que dois-je inclure pour tester la fonctionnalité du SUT ? – Probablement pas toutes les combinaisons de données.
4. MODÉLISER LES SEULS CHEMINS HEUREUX
La plupart des utilisateurs, lorsqu’ils commencent à modéliser, ne modélisent que des chemins heureux. C’est une bonne chose, mais pourquoi ne pas modéliser des comportements alternatifs et non valides ?
En modélisant les alternatives et les comportements non valides, c’est là que l’outil génère des cas de test auxquels vous ne pouvez pas penser ! Alors, interrogez-vous sur [what would happen if ….]? L’outil générera pour vous le cas de test correspondant.
5. L’UTILISATION EXCESSIVE D’EXTENSIONS DE MODÉLISATION PERSONNALISÉES
Permettez-moi d’expliquer ce qu’est une extension de modèle personnalisée : il s’agit d’un moyen d’étendre votre langage de modélisation, par exemple avec une action personnalisée, lorsque vous êtes bloqué dans une situation où aucune action prédéfinie fournie par votre langage de modélisation ne « semble » appropriée.
Ici, le mot important est « se sent » dans cette phrase. Lorsque vous décidez de créer une extension de modélisation personnalisée, vous devez être sûr à 100 % qu’il n’y a pas d’autre moyen d’y parvenir. L’introduction d’une telle extension dans le cadre d’une bibliothèque qui peut être réutilisée non seulement dans un but précis, mais aussi dans différents diagrammes, voire dans différents projets, résout ce problème de manière beaucoup plus élégante, car elle apporte lisibilité et cohérence et permet une transition directe entre les tests générés et l’exécution automatique.
J’espère que ces 5 points vous permettront de vous libérer l’esprit et vous apporteront une valeur ajoutée lors de votre modélisation. En conclusion, la modélisation change beaucoup de choses dans notre façon de travailler. Il est toujours bon de s’interroger et de discuter de la façon dont vous travaillez et de la manière d’améliorer la modélisation au sein de votre équipe. Tout cela vous mettra sur la voie pour devenir un JEDI TEST DESIGN MASTER !
Que la Force de modélisation soit avec vous et j’espère que vous ne commettrez plus jamais les cinq erreurs de débutant !
Merci de votre lecture ! N’hésitez pas à nous faire part de vos commentaires !
