Les tests basés sur des modèles permettent d’économiser beaucoup de temps et d’argent. C’est vrai, et croyez-moi, j’en suis profondément convaincu. Les tests basés sur des modèles vous permettent de générer de meilleurs tests plus rapidement, avec une meilleure qualité. Une autre chose que le gestionnaire de test doit savoir : il est amusant de créer des modèles ! Qui ne préférerait pas créer des modèles plutôt que de créer des tests manuellement ? Une personne qui s’amuse au travail sera toujours plus productive. J’en ai moi-même fait l’expérience lorsque mon patron m’a dit, au début de ma carrière : « Vous devriez jeter un coup d’œil aux tests basés sur des modèles ! « Vous devriez jeter un coup d’œil aux tests basés sur des modèles » au début de ma carrière. Aujourd’hui, je ne peux pas imaginer revenir en arrière et créer des tests manuellement.

Dans le cadre de mon travail, j’examine des modèles provenant d’un grand nombre d’entreprises et de domaines d’application différents. Je constate parfois un problème, en particulier avec les personnes très motivées : les modèles commencent à devenir vraiment compliqués. Je pense que c’est parce qu’ils passent trop de temps à modéliser des détails qu’il n’est finalement pas nécessaire de modéliser. Quand faut-il arrêter le mannequinat ?

Je pense qu’il s’agit d’une question de tests de la boîte noire par rapport à la boîte blanche. La littérature en parle beaucoup, mais la réalité est la suivante : il est parfois facile de passer de la boîte noire à la boîte blanche. En particulier, cela devient tentant lorsque vous disposez d’un moteur de génération de tests et d’un langage puissants. Il se peut que vous fassiez des tests en boîte blanche sans même en être conscient.

Permettez-moi de vous raconter l’histoire d’un cas que j’ai récemment rencontré dans le domaine de l’informatique d’entreprise. Quelqu’un avait spécifié un très bon modèle de test d’un menu particulier pour une application web. Dans une partie de ce modèle, il souhaitait modéliser un menu contextuel. En d’autres termes : « lorsque ma souris se déplace sur le menu, le menu doit apparaître, et lorsque ma souris sort du menu, le menu doit disparaître ». Pour des raisons qui nous sont inconnues, l’utilisateur n’a pas utilisé de menu contextuel dans le modèle (bien qu’il soit disponible), mais l’a modélisé littéralement dans ce détail : « lorsque ma souris se déplace sur le menu, le menu doit apparaître, lorsque ma souris se déplace vers le bas, la gauche et la droite, le menu doit disparaître » (et il a oublié de préciser que le menu doit également disparaître lorsque la souris se déplace vers le haut). À partir d’un tel modèle, un moteur de génération de tests créera des tests spéciaux pour tous les cas particuliers. Il a donc obtenu quatre cas de test pour tester le menu, dont un amusant : « Lorsque ma souris quitte le haut de l’écran, le menu doit rester ouvert. Imaginez que vous êtes un testeur qui vient de recevoir ces tests pour exécution manuelle. En fait, le testeur ne pourra pas dire que les tests ont été générés automatiquement. Ces quatre tests ne sont pas vraiment « intéressants » ou efficaces – et l’un d’entre eux semble même erroné ! N’oubliez jamais qu’un outil de test basé sur un modèle est une machine, et que si vous modélisez à ce niveau de détail, il générera vos tests et exploitera ce niveau de détail,
il générera vos tests et exploitera ce niveau de détail
. Un moteur de génération de tests supposera toujours que tout ce qui se trouve dans un modèle est le comportement prévu et générera des tests pour tout cela. Il ne peut pas juger ce qui est correct, ou plus ou moins important, à moins que vous (l’utilisateur humain) ne le spécifiiez.

Mais combien de temps a-t-il passé à modéliser le comportement de ce menu, qui n’incluait pas le comportement adéquat pour les tests fonctionnels ? Combien de temps supplémentaire a-t-il passé à comprendre pourquoi il a obtenu ce drôle de test, et où et comment y remédier ? Qu’a-t-il gagné à passer ce temps ? Quelle est la probabilité que l’application testée échoue à ces tests détaillés ? Quelle est la valeur ? Lorsque vous modélisez la fonctionnalité de votre menu à ce niveau de détail, vous effectuez des tests « boîte blanche » plutôt que « boîte noire ». Il y a une grande différence entre ce que l’on peut modéliser et ce que l’on doit modéliser. N’oubliez pas que les tests basés sur des modèles sont plus efficaces lorsqu’ils sont utilisés pour les tests de la boîte noire. Si vous modélisez des détails de ce type, ils doivent être indiqués à ce niveau dans votre cahier des charges.

Pour conclure, ce n’est qu’un exemple, il y en a beaucoup d’autres. Lorsque vous entrez les détails de la fonctionnalité,
posez-vous toujours la question suivante
: Est-ce vraiment pertinent pour ma fonctionnalité ? S’agit-il encore de tests en boîte noire ? À un moment donné, il s’agit plutôt de savoir : Combien de temps vais-je passer à créer, corriger et maintenir des modèles à ce niveau de détail et quelle est la valeur réelle que j’en retirerai ? Comme je l’ai déjà dit, ce n’est pas intentionnellement que nous modélisons de la sorte. Par conséquent, si vous remarquez que vous passez « trop de temps » à améliorer l’apparence des tests, prenez un peu de recul et posez-vous la question : Suis-je en train de rendre quelque chose plus compliqué qu’il ne l’est réellement ?

Merci de votre lecture ! N’hésitez pas à nous faire part de vos commentaires !

Lire la suite sur : https://www.conformiq.com/category/blogs/

Si vous avez un sujet spécifique, n‘hésitez pas à me le faire savoir !