Introduction
Vous l’aurez compris, les aventures de notre CoQ sont facilement transposables à nos logiciels. Dans le conte « à la recherche de la qualité perdue » le choix a été fait de s’axer sur les critères qualité définis par la norme ISO-25010. Ce choix a été fait suite à une longue réflexion: quel axe choisir ? Les difficultés fréquemment rencontrer et proposer des réponses usuelles à des problématiques fréquentes, parler d’un cas pseudo réel anonymisé ou alors essayer de rester aussi neutre que possible ? Le choix a été le 3ème point car l’idée d’un conte est d’être intemporel.
Tout au long de notre aventure on voit des cités qui sont des allégories des applications,=. Ces cités qui ont poussé des critères qualités à l’extrême. On voit alors le rôle des différents critères qualité que sont: le fonctionnel, la performance, la compatibilité, l’utilisabilité, la fiabilité, la sécurité, la maintenabilité et la portabilité. Cette définition n’est pas suffisante pour définir la qualité et le discours d’Eric Pournoo du dernier chapitre est essentiel: la qualité, comme les tests, dépend du contexte. De même il n’est pas de qualité si l’on ne pense pas à l’humain qui utilise le logiciel.
Définir la qualité
La bonne qualité est quelque chose de complexe à définir, vous ne trouverez pas de définition faisant consensus et c’est normal, car définir ce qu’est la bonne qualité revient à répondre à une question comme « qu’est-ce qu’une bonne campagne de test« .
Le but principal que j’ai souhaité mettre en avant avec le conte « à la recherche de la qualité perdue » est de faire comprendre cette complexité car la qualité est:
- composée de multiples facettes
- dépendante de ses utilisateurs
- dépendante de l’environnement
- évolutive avec le temps…
Bien évidemment, le conte ne cherche pas seulement à définir la qualité mais propose aussi d’autres axes de lecture! On y voit par exemple que la qualité est plus facile à perdre qu’à regagner.
La qualité plus facile à perdre qu’à retrouver
Ceci est une évidence pour tout testeur ou toute personne travaillant à la construction de quoi que ce soit: il est plus facile de bien faire directement que de corriger un existant de mauvaise qualité.
De même, la qualité se perd très facilement et ce sans que l’on s’en aperçoive forcément. Il suffit de quelques erreurs ou d’éléments « remis à plus tard » pour sombrer dans des problèmes de qualité. C’est pour cela qu’il est important de suivre des Definition of Done (DoD), de ne pas remettre des tests ou vérifications à plus tard. Toutes ces remises « à plus tard » qui semblent nous faire gagner du temps nous en font finalement perdre énormément. Ces mêmes actions reportées ont en plus de potentiellement introduire des anomalies potentiellement majeures la faculté d’engendrer une dette de test qui devient vite incontrôlable.
Dans le conte on voit que retrouver la qualité est complexe. Dans le contexte du conte la dette qui s’est accumulée au fil des versions nécessite une équipe à plein temps, accompagnée d’un expert, pendant plus d’une année. Cela a donc nécessité un fort investissement en temps et en argent… Pour un résultat qui mettra encore plus de temps à se voir complètement. C’est également le cas dans le logiciel.
Pour améliorer la qualité il faut être capable de la mesurer
Il est facile de dire qu’une application est de « bonne » ou de « mauvaise » qualité il est par contre compliqué de mesurer cette dernière. Ce qui se fait régulièrement est de mesurer la maturité des tests qui sont là pour évaluer la qualité. C’est l’option choisie dans le conte est celle de l’audit « Audit » qui donne une feuille de route.
On voit dans le conte une série de voyages à entreprendre pour pouvoir retrouver cette qualité. Ces voyages servent à faire prendre conscience de l’importance des critères qualité… mais aussi la nécessité d’être capable de tirer des enseignements des ces voyages et non appliquer bêtement ce qui a été vu. C’est également le cas dans la vraie vie. Une liste d’action et une trajectoire théorique sont formulées par un ou plusieurs experts. Il ne faut pas oublier que l’implémentation des actions n’est pas forcément aisée et qu’il y aura dans tous les cas des imprévus… Un audit est le fruit d’une photo faite à un instant « t », cette photo contient forcément des défauts et comme toute photo plus le temps avance moins elle correspond à la réalité.
Vous noterez, la présence tout au long des voyages d’Eric Pournoo qui accompagne l’équipe et l’aiguille dans ces réflexions. Il illustre bien le rôle d’un expert dans une transformation.
Définir le bon niveau de qualité
Enfin, le dernier point majeur que j’ai souhaité mettre en avant dans ce conte dédié à la qualité est le fait qu’il est nécessaire de bien évaluer le niveau de qualité à atteindre. Ce dernier est fortement dépendant du contexte qui lui même évolue. C’est pourquoi une réflexion est nécessaire:
- dès le début du travail afin de déterminer des pratiques et « jalons » pour atteindre ce bon niveau de qualité. En Agile on peut le voir à travers les DoD.
- tout au long de la vie du logiciel. En Agile on peut le voir à travers les rétrospectives et la mise à jour des DoD
Et vous, dans tout ça ?
J’espère que cette série vous a plu et qu’elle vous aura permis d’alimenter votre réflexion sur la qualité ainsi que de votre manière de la présenter.
De votre côté que retenez-vous de cette série ? Quels sont les éléments liés à la qualité qui ne sont pas et auraient dû être abordés à travers cette série ?
Comment parlez vous de la qualité ?
Encore merci à Zoé Thivet pour l’image de mise en avant
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
