Je vous parlais, dans un précédent article, de l’usage indispensable de l’automatisation pour mener efficacement et régulièrement les tests dans un cadre de développement Agile. Aujourd’hui arrêtons-nous un instant sur l’un des fondamentaux du test logiciel : la notion de qualité.
La qualité logicielle
Selon vous, qu’est-ce que c’est ?
- Le nombre de bugs par ligne de code ?
Non. Voilà une métrique bien dangereuse qui ne tient pas compte, par exemple, des bugs qui n’ont pas encore été découverts, ni de l’effort investi en détection des bugs…
- Le montant investi en recette applicative ?
Non plus. Certaines entreprises aimeraient qu’il y ait un lien direct entre l’investissement en recette applicative (souvent manuelle) et la qualité du produit, mais ce n’est pas toujours le cas. Cet investissement permet d’augmenter le niveau de qualité d’une version d’un produit mais cela n’en fait pas toujours un produit « de qualité »…
Nous pourrions établir une longue liste d’indicateurs qui ne font que mesurer un aspect bien précis lié de près ou de loin à la qualité d’un logiciel, mais cela ne répond pas à la question initiale.
En réalité, il existe de multiples définitions de la qualité logicielle, toutes aussi valables les unes que les autres et dont la pertinence dépend beaucoup du contexte dans lequel elles sont énoncées.
Certaines normes sont cependant établies pour obtenir une modélisation standardisée de cette notion de qualité :
L’ISO 9126 définit depuis 1992 un langage commun et modélise les différentes qualités d’un logiciel : on y retrouve 6 grandes caractéristiques, découpées en 27 sous-caractéristiques :
- Capacité fonctionnelle (capacité à répondre aux exigences)
Aptitude, exactitude, interopérabilité, conformité, sécurité, …
- Fiabilité (dans le temps et selon certaines conditions d’utilisation)
Maturité, tolérance aux fautes, capacité de récupération, …
- Rendement (coût de possession de l’infrastructure technique)
Efficacité des ressources employées, efficacité des temps de réalisation, …
- Utilisabilité (effort d’appropriation requis)
Exploitabilité, facilité d’apprentissage, facilité de compréhension, …
- Maintenabilité (coût des évolutions)
Stabilité, facilité de modification, facilité d’analyse, facilité à être testé, …
- Portabilité (coût d’un transfert de plate-forme)
Facilité d’installation, facilité de migration, adaptabilité, conformité, …
Cette norme a été remplacée en 2011 par la norme ISO 25010 qui reprend certaines définitions et dont la principale évolution est l’apparition d’une nouvelle caractéristique qualité à part entière : la sécurité. (La question longtemps débattue a donc finalement été tranchée : « la sécurité est-elle à considérer comme une fonctionnalité ? »).
Cela donne un cadre assez complet qui permet de penser à différents aspects parfois injustement mis de côté au profit des fonctionnalités. On peut se rendre compte alors que les fonctionnalités d’un logiciel ne constituent qu’un axe parmi d’autres de l’évaluation de la qualité de celui-ci.
Finalement, la qualité d’un produit ne serait-elle pas simplement l’aptitude qu’a un logiciel à satisfaire son utilisateur et ce, quels que soient les leviers de cette satisfaction ?
Les principes du test logiciel
Maintenant que nous avons une idée plus claire de ce qu’est la qualité d’un logiciel, penchons-nous sur les moyens à mettre en œuvre pour l’évaluer et pouvoir ainsi l’améliorer. L’évaluation du niveau de qualité passe par la mise en place de tests qui peuvent prendre de nombreuses formes et être de différents types, en vue de couvrir les différentes caractéristiques de qualité du logiciel.
Malgré la variété des tests possibles, certains principes sont valides, quel que soit le type ou le niveau de test considéré. C’est ainsi que l’International Software Testing Qualifications Board (ISTQB) a défini 7 principes fondamentaux du test logiciel. Vous allez pouvoir voir à quel point, par des exemples de situation vécues, ces principes sont présents au quotidien chez nous, éditeurs de logiciels :
1. Le test montre la présence de défauts : il ne peut garantir leur absence
Le PO (Product Owner), au moment de valider une fonctionnalité : « les tests sont au vert : c’est bien qu’il n’y a plus de bugs ? » Euh…. Pas tout à fait, non…. ?
2. Découvrir les défauts le plus tôt possible : l’importance du test dès les premières phases
En 2016, nous avions en effet intégré le surcoût engendré par la découverte tardive des défauts. Nous avions alors trouvé « LA » solution : « on va mettre en place une taskforce avec un membre de chaque équipe pendant un à deux jours lors de chaque mise en production pour limiter les impacts chez nos clients. Cela est plus efficace que traiter les remontées de clients mécontents, sans compter l’impact sur notre image ! ». Nous avons depuis compris qu’on peut anticiper cela en investissant sur de bons tests en amont, sur nos environnements internes. Chacun, du client à nos développeurs, peut alors vivre tranquillement les mises en production qui sont aussi devenues bien plus fréquentes !
3. Le test exhaustif est impossible : nécessité de prioriser / adapter l’effort de test
Notre produit Navigation, sortie en BETA en mars 2018 a dû faire l’objet d’une priorisation de l’effort de test, en fonction des risques évalués sur les différents scénarios d’utilisation. Nous avons donc choisi d’implémenter seulement une partie des tests envisagés, pour répondre au mieux aux attentes de nos clients qui souhaitent un produit de qualité mais qui étaient aussi (très) impatients d’explorer leurs données avec cette nouvelle interface.
4. Agrégation de défauts : nécessité de considérer la répartition des défauts constatés pour cibler l’effort de test
En 2016, 18% de nos défauts en production étaient concentrés dans un composant du moteur de requêtage des données. Nous avons donc investi sur le test à cet endroit : ce même composant compte en 2018 4 fois moins de bugs remontés, ce qui a un large impact sur notre volume d’exploitation global. Avec un effort bien ciblé, nous avons gagné en efficacité et amélioré la qualité de notre solution.
5. Paradoxe du pesticide : nécessité de mettre à jour / faire vivre les jeux de tests
Il est évident que les fonctionnalités et les utilisations de nos clients évoluent, il est donc nécessaire de faire évoluer les tests de non régression en conséquence !
6. Le test dépend du contexte : nécessité d’adapter les pratiques et objectifs suivant les contextes
7. Illusion de l’absence de défauts : trouver/corriger des bugs n’est pas gage de satisfaction du client, le produit doit aussi répondre à son besoin
C’est avec ces fondamentaux en tête que nous avons élaboré et que nous faisons vivre notre stratégie de test, en tenant des contextes spécifiques à chaque situation, chaque projet et chaque équipe.
Notre approche de la qualité de nos produits
« La qualité est l’affaire de tous » disait W. Edwards Deming : c’est une réalité chez AT Internet où chacun s’implique à son niveau pour améliorer la qualité du produit, la fiabilité des données mesurées et donc la satisfaction de nos utilisateurs.
Les développeurs et testeurs optimisent leurs pratiques de tests unitaires et leurs analyses de code, peaufinent les tests de non régression automatisés pour couvrir les nouvelles fonctionnalités, les Product Owner revoient à la hausse leurs exigences en termes de qualité et d’automatismes de test, la direction investit et soutien les actions de fond et je m’occupe de l’accompagnement transverse, pour aider chaque équipe à avancer de la manière la plus adaptée.
C’est grâce à cette mise en commun de l’effort que nous pouvons aujourd’hui avancer efficacement pour nos clients et que la qualité est une de nos priorités. Elle fait partie de notre ADN en s’installant dans tous les rouages de l’entreprise.
Comments are closed.