17 février 2020 admin

Comment mesurer la qualité des logiciels dans des projets agiles ?

Quand il s’agit de la qualité des logiciels, nous nous retrouvons face à un vaste sujet tant chacun a son propre avis sur la question. Alors quels indicateurs de performance clé choisir si l’on souhaite mesurer la qualité dans un contexte agile ?

Bien entendu, l’indicateur ultime serait le nombre de défauts critiques révélés en production à la suite du lancement de nouvelles fonctionnalités et le nombre des stories validées (dans une équipe agile) par rapport aux stories livrées. Cependant, on peut se demander quels autres facteurs peuvent être utilisés pour mesurer la qualité ?

1.     Quels indicateurs ?

Afin d’obtenir une meilleure mesure de la qualité des logiciels, il est important d’identifier des indicateurs significatifs en se posant les bonnes questions selon le contexte donné. 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éé, l’équipe d’assurance qualité a-t-elle fait un bon travail ? le logiciel est-il mal conçu ? On se rend vite compte que la est désignée par le nombre de bugs qui arrivent au client et l’impact de ces anomalies sur les utilisateurs du logiciel.

Une autre façon d’appréhender le sujet serait de de constater que des logiciels sont développés dans le but de répondre aux besoins des utilisateurs. Par la création desdits, de la valeur est délivrée et  non de la qualité. Il est donc important de considérer la manière dont cette valeur est remise aux utilisateurs (à quelle vitesse ? à quelle fréquence ?). Tout cela est lié au processus et au pipeline de livraison du logiciel.

2.     Comment mieux mesurer ?

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 donc quelques éléments à prendre en compte afin de mieux mesurer vos métriques 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 l’équipe à 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.

Qui dit « produit de qualité », dit la mise en place d’une processus de qualité. En suivant les conseils cités ci-dessus, il sera bien plus simple de créer un pipeline de livraison logicielle fluide offrant une véritable valeur ajoutée aux utilisateurs. Et pour un résultant encore plus probant, d’autres paramètres peuvent être mise en place comme :

  1. 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) ;
  2. Suivre le nombre de bugs tout au long du projet pour voir s’il existe des corrélations avec la vélocité et le nombre de bugs par sprint.

3.     Mon logiciel est-il de qualité ?

Selon les normes ISO 25010, il existe 8 facteurs principaux, tous ayant des attributs bien distincts qui peuvent être testés avec différents types de tests. Pour qu’un logiciel soit considéré comme qualitatif, il doit avoir intégré les 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 et à 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 pourrons ê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.

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

4.     L’importance des rôles dans l’équipe.

Chaque personne peut intervenir sur des niveaux de test différents mais il faut toujours définir les tâches et les rôles de chacun de manière à pouvoir répondre à cette simple question : qui teste quoi ?

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

Zakaria A.

Contact

N’hésitez pas à nous solliciter pour vos projets ou pour en savoir plus sur nos expertises, nos offres et nos domaines de compétences.