Le but de cette nouvelle série d’articles est de vous montrer comment, dans l’hypothèse où vous n’avez pas un outil ATDD de génération automatique de test (ce qui est la situation la plus courante), spécifier et générer les tests d’un système de manière rigoureuse, rapide et … simple ! Cette méthode est valable pour les systèmes développés traditionnellement, … ou en agile. Elle cible l’acceptation des nouveautés agiles (depuis les US et même les changements internes à celles-ci, jusqu’aux « epics » les plus grandes) et l’analyse de la non-régression fonctionnelle dans tout le système.
Notez que cette méthode “ATDD manuelle” peut être suivie, ou non, de l’automatisation de l’exécution des tests.
Préambule
Généralement les agilistes pensent que la conception des tests est simple parce qu’ils ne voient souvent que les User Stories. Nous allons constater que cette vision est erronée. Rien n’est aussi évident ! En effet le système doit être testé, pas seulement les US … et, même pour celles-ci, il y a des choses pertinentes à dire !
Ce qui nous amène à nous pencher sur la conception des tests, bien avant de dire qu’on va les automatiser. Que faire, comment faire, jusqu’où faire ? Et tout cela souvent sans outil à ce stade du processus de test !
Nous avons déjà expliqué comment traiter le sujet dans la série consacrée aux tests ATDD et aux outils (l’illustration a été faite avec l’outil YEST). Nous allons donc vous montrer sur des exemples (agiles ou non) comment faire, même sans outil ATDD, sur une démarche qui comprend deux aspects :
- Comment spécifier au mieux les exigences fonctionnelles du produit ?
- Comment pouvez-vous, à partir des spécifications fonctionnelles, trouver rapidement et facilement les scénarios de test de manière progressive ? Autrement dit comment moduler le nombre de tests pour obtenir des plans de test qui répondent à votre niveau de qualité et/ou à vos disponibilités ? En contrepoint il s’agit ainsi de donner des dispositifs pour “durcir” petit à petit les tests fonctionnels.
La valeur ajoutée de cette nouvelle série d’articles
Cette série d’articles se distingue de la précédente.
On trouvera en effet, ici, les solutions proposées et spécifiques à mon expérience dans l’aéronautique (logiciels embarqués AIRBUS), mais, surtout, mises au point à travers de centaines de projets dans la banque-assurance et l’administration. C’est le fruit d’une longue et continuelle réflexion sur le sujet. Elle va amener à remettre en cause les concepts vus en ATDD automatisée. Nous verrons que les définitions proposées ne s’appliquent pas de la même manière à cause du changement de nature des activités.
Nous verrons que cette série d’articles est encore plus longue que la précédente. Elle s’avère très riche, avec des aspects théoriques et des illustrations concrètes.
Quelles sont, en effet, les propositions développées par la suite ?
- Une solution de spécification BML (Business Modeling Language) compatible avec les standards du marché pour les exigences :
- Gabarits d’exigences fonctionnelles pour le domaine de la solution et préconisés par l’IREB,
- Modélisation tabulaire pour des US INVEST, modélisation graphique ATDD pour des fonctionnalités de granularité supérieure,
- Reprise et précision sur les énoncés Gherkin des critères d’acceptation en agile.
- Une première solution algorithmique pour générer progressivement (« par tamis ») les scénarios de test et tests d’une User Story (US) “INVEST”.
- Une solution de génération de scénarios de test d’intégration par “l’algorithme des tamis successifs”, prolongé par une distribution pertinente des données pour former des tests.
Par “tests d’intégration” il faut comprendre que la solution s’applique tout autant pour :
- Les tests d’un cas d’utilisation (Use Case : UC) intégrant plusieurs US
- Les tests d’intégration d’une macro-fonctionnalité (MUC) intégrant plusieurs UC
- Les tests de toute ou partie d’un parcours utilisateur intégrant plusieurs macro-fonctionnalités.
Donc vous pouvez utiliser la solution suggérée pour des tests d’intégration qui correspondent à des niveaux de granularité bien différents. Elle concernera les différents acteurs de projet, par exemple le Business Analyst pour le premier cas (a)) et le Product Owner pour les cas (b et c).
Process driven vs data driven
Il faut comprendre que nous parlons des tests basés sur une approche “process driven” c’est-à-dire conduite par des personnes indépendantes des développeurs (des Business Analysts / testeurs par exemple) et des Product Owners. Ils visent à s’assurer par les tests que les choix du parcours client sont bien implémentés. C’est-à-dire qu’ils satisfont l’usage attendu.
Cette approche se différencie d’une approche “data driven” qui est celle suivie par des utilisateurs finaux, qui est plus facile de mise en œuvre et qui cherche à couvrir les domaines de données en entrée et sortie des traitements. La conception des tests leur laisse le soin de contrôler le déroulement des tests sans avoir à les documenter autrement que par la création de jeux de données pertinents.
En résumé, la conception des tests dont nous allons parler, avant d’en automatiser éventuellement l’exécution, est fondée sur les nouveautés fonctionnelles agiles, les tests de régression, mais aussi sur l’architecture fonctionnelle du système réalisé.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
