Prévenir bugs

Éviter des bugs dans les tests

Le troisième principe de test est appelé "Test early" [Radid 2018-3]. Lorsque l'on tente d'appliquer cette stratégie de manière extrême, on met en place des pratiques pour empêcher l'apparition de bugs plutôt que de devoir écrire des tests et les exécuter pour vérifier si les bugs sont apparus.

Cette pratique est énoncée dans le "Manifeste des tests agiles" [Laing 2016] et est conforme au vieil adage"Mieux vaut prévenir que guérir".

Cela peut se faire en intégrant la qualité dès la conception, comme le propose la valeur "Qualité intégrée" de SAFe [SAFe 2021-26]. Cependant, cette démarche de prévention nécessite une certaine connaissance des impacts d'un élément une fois mis en production : on évite de toucher les braises si on sait à l'avance qu'elles vont brûler !

Ces connaissances peuvent être acquises par la lecture ou par l'expérience acquise sur le terrain, comme le propose la pratique des sessions "Gemba", qui peut être mise en œuvre par la présence de collaborateurs T-Shape dans l'équipe, ou d'équipes de type X-Team. Ces configurations sont théorisées par les notions de "Double Loop Learning" [Argyris 1977] [Moustier 2020] et de "Panarchy", dont la mise en œuvre concrète passe par l'automatisation des observables.

Application à la maturité des tests

En termes de prévention bug, la première posture préconisée par Extreme Programming [Beck 2000] et SAFe [SAFe 2021-27] est de commencer par les tests. Cette posture a conduit Kent Beck à développer le TDD, qui a trouvé son équivalent pour les User Stories avec l'ATDD.

D'autres pratiques liées au code permettent également d'éviter l'apparition de bugs, telles que la programmation en binôme, voire la programmation en groupe, ou la programmation défensive, qui consiste à vérifier systématiquement l'absence de plages de valeurs de paramètres invalides lors de l'appel d'une fonction ou de web service, avec un mécanisme d'avertissement approprié pour indiquer que le module appelant contient manifestement une erreur.

On peut aussi penser à la mise en place de mécanismes techniques, qui évitent de faire quoi que ce soit au plus tôt, et cela, que ce soit :

• avec un Linter [Promyze 2021] qui indique au développeur un bug dans son éditeur pendant qu'il écrit le code.
• ou pendant la compilation ou même l'intégration continue où les critères de blocage arrêteront le processus de livraison.

Ou tout autre contrôle automatique permettant la mise en place d'un "Poka Yoke" qui bloque la progression du produit en mettant en évidence l'erreur identifiée.

Toutes ces pratiques peuvent être regroupées dans l'approche Software Craftsmanship [McBreen 2002] [Martin 2008] [Moustier 2019-1] [Moustier 2020] [Kokaina 2019], avec des techniques comme le refactoring [Fowler 1999] pour rendre le code plus maintenable.

Toujours dans une stratégie où l'on préfère prévenir bugs plutôt que de le vérifier, on peut aussi introduire des techniques d'idéation de groupe comme les "3 Amigos" ou "Event Storming" [Brandolini 2019] qui permettent aux personnes techniques de comprendre les situations particulières à prendre en compte en réduisant les ambiguïtés, et plus globalement, la notion de testabilité et de"Pantesting" [Moustier 2020] pour permettre à l'ensemble du système d'intégrer cette qualité tant dans le système qui génère le produit que dans le produit lui-même.

La stratégie consistant à prévenir les bugs avant qu'ils n'apparaissent peut également être appliquée une fois la solution en production, c'est ce qu'on appelle le Shift Right Testing. Elle consiste à identifier un bug déjà présent avant qu'il ne soit détecté par les utilisateurs : pas vu, pas pris ! Cette approche est évidemment plus complexe à mettre en œuvre, mais elle contribue à la satisfaction du client, qui est l'objectif premier de la qualité [ISO9000 2005].

La position d'Agilitest sur la prévention bugs

Agilitest peut faire partie d'une approche de type ATDD. Cependant, cet outil ne peut être le seul moyen de prévenir les bugs. En effet, avec une telle approche, la pyramide de test finirait par pointer vers le bas [Craske 2020] pour former ce qu'on appelle un "cône de glace". Agilitest doit être combiné avec d'autres techniques de test, par exemple en suivant le modèle des tranches d'emmental [Reason 2006] [Moustier 2019-1] [Moustier 2020].

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍