Tous les responsables de tests rêvent probablement d’un monde où les scripts de test fonctionnent du premier coup, où les tests et les scripts de test sont maintenus automatiquement et où notre équipe de test passe son temps à trouver des failles et à approfondir le système plutôt qu’à refaire les mêmes tests encore et encore à cause de changements dans la spécification. Un rêve où chaque exécution de test donne lieu à un rapport de test et fournit un retour d’information immédiat sur l’application à tester. Oui, ce n’est peut-être qu’un rêve, mais une nouvelle méthode de test peut désormais contribuer à faire de ce rêve une réalité.

Voyons ce que font les concepteurs de systèmes embarqués et comment nous pourrions « peut-être » apprendre d’eux dans le domaine des tests. Tout d’abord, l’équipe de développement reçoit des exigences (les mêmes que celles que reçoit notre équipe de test). Sur cette base, ils commencent à « coder » en spécifiant des modèles de conception. Le modèle de conception peut être utilisé et/ou affiné en fonction des modifications apportées aux spécifications, et peut être utilisé pour générer « automatiquement » du code pour la plate-forme cible. Cette technique de conception est fréquemment utilisée dans l’industrie automobile et dans d’autres domaines d’application. Cette « génération automatique de code » basée sur des modèles de conception permet de gagner du temps dans un monde où
le temps de mise sur le marché est souvent la différence entre le succès et l’échec.
.

Voyons maintenant ce qu’il en est des tests aujourd’hui. La plupart des entreprises créent encore manuellement des tests (même dans le développement de systèmes embarqués – même dans l’automobile) à partir de spécifications. Mais la partie la plus difficile est de savoir comment gérer tous les tests une fois que les spécifications ont été modifiées. À quelle fréquence votre cahier des charges est-il modifié ? Pour chaque changement, les testeurs devront passer du temps à identifier les endroits des tests spécifiques impactés par ce changement, afin d’effectuer la maintenance. Mais les testeurs sont des êtres humains, et lorsque les spécifications changent fréquemment et qu’il y a beaucoup de tests à examiner, il est évident que des erreurs peuvent se produire. Lorsque toutes les modifications sont effectuées, il est temps de mettre à jour l’automatisation. Un processus long et important commence lorsque les testeurs écrivent un premier script de test, essaient de l’exécuter, le modifient encore et encore, et à la fin, ils ont quelque chose d’automatisé. Si nous appliquons ici des techniques de conception de systèmes intégrés, pourquoi n’utiliserions-nous pas également un modèle pour les tests et ne générerions-nous pas automatiquement, à partir de ce modèle, de la documentation et des scripts de test ? Cette idée existe et s’appelle Model Based Testing (test basé sur un modèle).

Pour différencier un modèle MBT d’un modèle de conception, un modèle de conception contient des détails et des interactions avec des composants internes, et prend en compte des exigences architecturales qui ne sont pas pertinentes du point de vue des tests boîte noire. Les modèles d’essai sont généralement moins complexes que les modèles de conception du même système.

Ce que je vous suggère de faire, c’est de créer un modèle indépendamment du cahier des charges, en vous basant uniquement sur les exigences fonctionnelles contrôlables et observables de l’extérieur. Les interfaces d’échange de données avec votre produit ou vos interactions (comme set, send, click, drag ou get, check et verify) peuvent être automatiquement importées dans l’outil. Il vous suffit de décrire la fonctionnalité à tester sur la base des exigences et des données dont vous disposez. Vous pouvez considérer ce modèle MBT comme une image (fonctionnalité) d’un paysage (votre produit). Lorsque votre modèle MBT est terminé, il est temps de générer votre suite de tests, sur la base des algorithmes fournis avec l’outil. Ensuite, à partir de l’image de ce paysage, l’outil décrira ce qu’il considère comme des « tests » nécessaires pour couvrir la fonctionnalité donnée.

Outre la génération de tests, l’outil génère en même temps des scripts de test pour votre outil d’automatisation des tests ou votre cadre de test actuel. Avec certains outils d’automatisation des tests, il est même possible de réutiliser la bibliothèque de données pour la stimulation. En fait, dans votre modèle, vous pouvez utiliser ces fonctions de la bibliothèque directement comme mots-clés dans les actions (entrées et sorties) ! L’outil génère alors pour vous des scripts de test prêts à être exécutés automatiquement. Mais soyons francs, il existe des limites naturelles à l’automatisation de l’exécution des tests en général. Mais les tests basés sur des modèles peuvent certainement vous aider à augmenter votre niveau d’automatisation des tests, à permettre la génération automatique de tests et à vous faciliter la vie. Mais il s’agit toujours d’un outil.

En conclusion, certaines leçons peuvent être tirées des techniques de conception des systèmes embarqués. Ces techniques ne sont pas des idées de recherche – elles sont appliquées avec succès dans l’industrie depuis de nombreuses années. Alors pourquoi ne pas appliquer ces techniques aux tests ? Vous pouvez gagner du temps et permettre à l’équipe de test de se concentrer sur l’exploration des fonctionnalités plutôt que de créer des tests manuellement, de convertir ces tests en scripts de test manuellement et de mettre à jour les tests manuellement lorsque les spécifications changent. Pourquoi ne pas utiliser des tests basés sur des modèles et tout automatiser ?

Read more on : https://www.conformiq.com/category/blogs/

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