La plupart d’entre vous savent probablement ou ont au moins entendu dire que le Model Based Testing (MBT) est une nouvelle technologie innovante dans laquelle les outils vous aident à créer de meilleurs tests avec une génération automatisée, et avec Conformiq la génération est automatique et fournit un chemin direct vers l’exécution automatisée des tests, mais ce n’est pas le sujet de ce blog. Ce dont je veux parler, c’est que dans de nombreux engagements avec des clients, on me pose la question suivante : « Comment les tests basés sur des modèles peuvent-ils générer des tests que je ne peux pas utiliser ? [the tester] ne peut pas penser » ?

En général, lorsque les testeurs commencent à modéliser, ils esquissent d’abord des scénarios de test. Dans un deuxième temps, ils affinent ces scénarios en ajoutant des données à leur modèle et effectuent des tests. Je trouve cela très compréhensible. En tant que testeurs, nous avons déjà spécifié tellement de tests au cours de notre carrière qu’il nous semble naturel, lorsque nous modélisons, de modéliser les tests.

D’une manière générale, cette approche ne me pose aucun problème. Il n’y a pas une seule bonne façon de créer un modèle de test – il y en a plusieurs. Mais dans ce cas, il est également évident que cette approche ne générera que des cas de test que vous connaissez déjà – parce que c’est exactement ce que nous avons modélisé en premier lieu. Au final, vous obtenez un certain nombre de cas de test similaires mais avec des données différentes. Si ce résultat est acceptable pour vous, alors il me convient – mais vous devez alors accepter que le test basé sur un modèle dans ce cas ne génère pas de tests auxquels vous n’avez pas pensé. En suivant cette approche, vous pouvez également obtenir la traçabilité des exigences, un chemin direct vers l’automatisation des tests et beaucoup plus de cas de test. Vous obtenez une couverture à 100 % de votre « modèle de cas de test ». Mais que signifie une couverture à 100 % lorsqu’il s’agit de la fonctionnalité réelle à tester en premier lieu ? 100% de notre modèle de test représente exactement quel pourcentage de votre fonctionnalité ? Peut-être qu’en passant suffisamment de temps à réfléchir, à analyser et à modéliser de plus en plus de tests, vous pourriez atteindre cet objectif de couverture à 100 % – mais combien de temps cela prendrait-il et à quoi ressemblerait un tel modèle ? D’après mon expérience, ils ont été importants, désordonnés et difficiles à comprendre et à réutiliser pour les autres. En outre, comment pouvez-vous être sûr d’avoir couvert l’intégralité de la fonctionnalité à tester ? Êtes-vous sûr que, même dans vos mauvais jours, vous penserez à tous les cas de figure ? Savez-vous quels sont les cas que vous avez manqués? Probablement pas, car les tests que vous avez manqués sont des tests auxquels vous n’avez pas pensé.

Ensuite, parlons plutôt de la modélisation de la fonctionnalité réelle décrite par les exigences de l’application. Parlons de la conception automatique des tests. À première vue, cette approche semble plus compliquée que les tests de modélisation, car elle nous oblige à changer notre façon de penser. Après tout, nous sommes des testeurs et nous concevons et écrivons des tests depuis des années. Grâce à cette expérience, nous connaissons mieux que quiconque les aspects critiques et difficiles du fonctionnement d’une application. Cela change dans la conception des tests automatiques, car l’expérience n’est pas aussi critique parce que les testeurs modélisent simplement l’opération à tester, par exemple, comme spécifié dans les spécifications des exigences, du point de vue « Je suis l’application à tester et voici comment j’interagis avec mon environnement » au lieu de « Je suis le testeur et voici comment j’interagis avec l’application à tester ». Dans cette approche, nous ne pensons pas en termes de tests mais en termes d’interactions et de prises de décisions attendues au sein de l’application testée elle-même : « Comment dois-je [the application] réagir lorsque j’obtiens ce type de données à partir de cette interface ? » Ce type de question révèle souvent une documentation insuffisante ou imprécise des exigences avant que nous n’ayons un modèle ou exécuté un test. Une fois que toutes nos exigences sont reflétées dans la fonctionnalité modélisée, l’outil de conception de test automatique analyse la fonctionnalité modélisée sur la base des données modélisées afin de couvrir tous les aspects du modèle de fonctionnement du système. [the tester] spécifié. Ensuite, pour la première fois, vous pouvez trouver des parties de la fonctionnalité ou des données qui n’étaient pas couvertes par des cas de test – qui sont exactement ces « tests auxquels nous ne pouvions pas penser auparavant », qui sont maintenant couverts et documentés. Un ordinateur ne connaîtra pas de mauvaise journée. Un ordinateur se « souviendra » toujours d’essayer tous les cas de figure possibles sur une partie donnée de la fonctionnalité. Un ordinateur couvrira les opérations vraiment compliquées, en particulier les chemins négatifs, qui peuvent être trop difficiles pour prendre le temps de concevoir manuellement des tests avec des scénarios. En fin de compte, un ordinateur sera capable de retracer dans quel test, à quelle étape, une exigence ou un cas de figure a été couvert. La traçabilité est générée automatiquement – un clic de souris – et ne nécessite plus une analyse supplémentaire de chaque test dans un ensemble de tests. De la même manière, une documentation toujours à jour est automatiquement générée.

Pour conclure, toutes les approches de tests basés sur des modèles ne vous donneront pas des cas de test auxquels vous n’auriez pas pensé, car beaucoup de ces outils sont basés sur l’automatisation des tests à partir de scénarios développés par l’utilisateur. Seule la conception automatique de tests basée sur des modèles de systèmes permet d’atteindre cet objectif. En même temps, il est clair que la conception automatique des tests exige des testeurs qu’ils modélisent la fonctionnalité à tester. Les testeurs doivent identifier et diriger l’ordinateur vers les parties critiques de cette fonctionnalité. C’est dans la modélisation du système que le testeur intervient, car un ordinateur ne peut pas penser ou lire dans vos pensées (du moins aujourd’hui). Cette approche n’élimine pas les testeurs ; elle les rend simplement meilleurs et plus rapides. Plus vous ajoutez de données et de fonctionnalités à votre modèle, plus vous tirerez parti des avantages de la conception automatique des tests.

Lire la suite sur : www.conformiq.com/blog/

Nous vous remercions.