Quels paramètres et indicateurs choisir pour mesurer la qualité logicielle dans les projets agiles ?

Nous savons tous que la qualité des logiciels est en grande partie subjective et peut signifier différentes choses pour différentes personnes, mais quels indicateurs de performance clé doit-on choisir si l’on veut mesurer la qualité logicielle dans un contexte agile ?

Bien entendu, l’indicateur ultime est le nombre de défauts critiques révélés en production à la suite du lancement de nouvelles fonctionnalités et peut-être (dans une équipe agile) le nombre des stories validées par rapport aux stories livrées.

Mais quels autres facteurs peuvent être utilisés pour mesurer la qualité logicielle ?

1. Quels indicateurs pour mesurer la qualité logicielle ?

Afin de mieux mesurer la qualité des logiciels, il est important d’identifier des indicateurs significatifs. Si aucune anomalie n’a été identifiée, cela signifie-t-il que le logiciel est de la plus haute qualité ?

D’autre part, lorsqu’un grand nombre de bugs a été créé, cela signifie-t-il que l’équipe d’assurance qualité fait un bon travail et que le logiciel est mal conçu ?

La valeur est déterminée par la qualité des bugs et du processus d’assurance qualité, mais comment cela est-il mesuré ? L’indicateur de qualité logiciel le plus signifiant est le nombre de bugs qui arrivent au client et l’impact de ces anomalies sur les utilisateurs du logiciel.

Une autre façon de voir les choses est que des logiciels sont développés dans le but de répondre aux besoins des utilisateurs. Nous délivrons de la valeur, pas de la qualité, donc la meilleure manière de le faire est de s’assurer que quoi que nous fassions délivre de la valeur à l’utilisateur. Ce qui est important, c’est la manière dont nous offrons cette valeur à vos utilisateurs, à quelle vitesse et à quelle fréquence. Tout cela est lié au processus et au pipeline de livraison du logiciel qualité.

Plutôt que d’essayer de mesurer la qualité des logiciels via certaines métriques, pourquoi ne pas essayer de créer un modèle de diffusion parfait ?

Voici les éléments à prendre en compte afin de mieux mesurer vos métriques :

2. 7 éléments à prendre en compte dans un contexte agile :

  1. S’assurer que les user stories ont des critères d’acceptance clairs, concis et compréhensibles
  2. Avant le démarrage du développement, s’assurer que les membres de l’équipe (PO, DEV, TESTEUR) ont la même compréhension du besoin des user stories.
  3. Encourager les 3 amigos à se réunir et préciser les exigences afin de concevoir des scénarios pertinents (Méthode BDD par exemple)
  4. Tester les stories au fur et à mesure de leur élaboration – revues de code, tests unitaires, couplage pour fournir un retour rapide
  5. S’assurer de livrer ce qui a été convenu au début du sprint
  6. S’assurer de ne pas mettre en production des défauts de priorité élevée ayant un impact sur le client !
  7. Pas de rollback cela est facile à mesurer – le nombre de rollback peut indiquer un processus très défaillant.

Pour créer un « produit de qualité »/ « logiciel de qualité », nous devons mettre en place un processus de qualité. En pratiquant les activités ci-dessus, il est utile de créer un pipeline de livraison logicielle fluide offrant une valeur ajoutée aux utilisateurs.

3. Paramètres supplémentaires à prendre en compte

  • Mesurer la vélocité au fil du temps (le nombre de points déterminés VS le nombre de points réellement réalisés lors d’un sprint)
  • Suivre le nombre de bugs tout le long pour voir s’il existe des corrélations avec la vélocité et le nombre de bugs par sprint

4. Qu’est-ce qu’une une bonne qualité de logiciel ?

Dans les normes ISO 25010, il existe 8 facteurs principaux, chacun ayant de différents attributs qui peuvent être testés avec différents types de tests.

Un logiciel de très bonne qualité doit avoir intégré des tests ci-dessous dans sa stratégie de développement.

  • Test de maintenance (il est facile de maintenir le code et d’ajouter des modifications)
  • Test de portabilité (facile à installer, remplacer, adapter à de nouveaux environnements)
  • Test fonctionnel (Il fait ce qu’il est destiné à faire)
  • Test de performance (il fonctionne rapidement sans utiliser trop de ressources, même lorsque de nombreuses personnes accèdent au logiciel en même temps, dans le monde entier)
  • Test de compatibilité (le logiciel est compatible avec plusieurs composants)
  • Test d’utilisabilité (facile à utiliser sans nécessiter d’instructions, même pour les personnes handicapées)
  • Test de fiabilité (nous pouvons être certains que le logiciel fonctionnera et résoudra les problèmes)
  • Test de sécurité (les informations importantes ne peuvent pas être extraites par des pirates).

Mais, pour chaque logiciel, certains de ces tests seront plus importants que d’autres, tout dépendra pourquoi et par qui le système sera utilisé.

5. Il est également important de définir qui teste quoi dans une équipe agile

Chaque personne peut intervenir sur des niveaux de test différents.

Exemple : Un développeur sera responsable de réaliser, voir automatiser ses tests unitaires, un PO sera plus en charge des tests d’acceptance et s’il y a un testeur il sera en charge des tests fonctionnels, tests de bout en bout, etc. Ces éléments seront formalisés dans une stratégie de test si possible.

Si vous souhaitez recevoir notre newsletter mensuelle abonnez-vous via notre page de dossiers thématiques !

Vous souhaitez échanger avec nos experts du test sur ces sujets ? Contactez-nous !

Cet article a été traduit et adapté par All4test (Source Amir Ghahra)