Table of Content
Ce n’est pas un secret : les Responsables Qualité Logiciel sont soumis à une pression croissante car ils doivent livrer des logiciels de qualité à une vitesse record. Mais en matière de qualité logicielle, comment évaluer la réussite avec précision ?
Le calcul du délai de mise sur le marché est beaucoup plus simple. À l’inverse, nos performances en livraison de logiciels de qualité dépendent d’une multitude de facteurs comme la méthodologie du projet (en cascade, hybride, agile), la complexité du logiciel, le niveau technologique, le nombre d’interfaces, et bien d’autres facteurs. Pour résumer, il ne faut pas sous-estimer le nombre de variables qui entrent en jeu pour une quantité acceptable de défauts critiques.
Pour survivre sur ce marché, nous devons évoluer constamment, aussi bien dans notre manière de penser que dans les outils de mesure que nous employons, et c’est pourquoi nous avons élaboré 8 KPI que nous vous recommandons d’ajouter à votre Fiche d’évaluation de la qualité. Adoptez dès aujourd’hui un suivi pour réduire les risques associés à la publication des nouvelles versions, améliorer leur qualité et évaluer votre réussite.
Efficacité de la détection des défauts (DDE, ou pourcentage de détection des défauts)
L’efficacité globale des tests de régression correspond au rapport entre les défauts décelés avant et après la publication d’une version, par vos clients. Les défauts identifiés après publication sont généralement appelés des « incidents » et consignés dans un système d’assistance, tandis que les défauts détectés au cours des phases de test (tests unitaires, système, de régression ou UAT) sont identifiés avant la publication et documentés à l’aide d’outils comme Panaya Test Dynamix. Pour calculer correctement ce KPI, vous devez systématiquement catégoriser dans quelle version de logiciel chaque défaut a été identifié avant toute publication dans votre environnement de production.
Vous trouverez ci-dessous la formule souvent utilisée pour calculer la DDE :
Nombre de défauts identifiés au moment de la publication d’une version logicielle /
Nombre de défauts au moment de la publication + Défauts non détectés identifiés par les utilisateurs finaux (p. ex., incidents).
En voici une illustration simple : imaginons que 95 défauts ont été identifiés lors de votre cycle de tests de régression portant sur le dernier Service Pack SAP mensuel, puis que 25 défauts ont été consignés après publication. La DDE est calculée comme suit : 95 divisé par (95 + 25) = 79 %.
N’oubliez pas que la DDE doit être représentée par un graphique partant de 100 % le jour suivant la mise en production de la version. En travaillant avec le dernier service pack SAP de notre exemple, vos utilisateurs finaux internes et vos clients consigneront inévitablement quelques incidents. On observe couramment une « frénésie de signalements » deux jours après la mise en production d’un service pack, et ce phénomène se prolonge pendant une semaine. C’est au cours de cette période que la DDE chute rapidement, passant de 100 % à environ 95 % au fil de l’enregistrement des incidents. Si votre entreprise suit un rythme mensuel de publication de service packs, elle doit alors évaluer la DDE pendant 30 jours pour chaque version. Par contre, si elle n’exécute que quatre cycles de version majeure par an, il faudra l’évaluer sur 90 jours pour observer la baisse de la DDE sur toute cette période.
Que serait « une bonne DDE » ? Comme la tension artérielle qui évolue chez un individu, la DDE d’une entreprise varie. Et bien que 120/80 corresponde à une tension optimale pour la communauté médicale, il est naturel d’observer une augmentation de la tension systolique avec l’âge. En matière de DDE, les experts de l’industrie et les éminences intellectuelles considèrent généralement 90 % comme un chiffre respectable dans la plupart des secteurs. Toutefois, certaines entreprises dépassent régulièrement les 95 % de DDE en détectant davantage de défauts avant publication grâce à des outils de simulation d’impact comme Impact Analysis de Panaya.
Défauts à l’échelle système (SWD)
Avez-vous déjà rencontré des défauts multiples tous liés aux mêmes objets ? Certainement – c’est un phénomène courant rencontré par de nombreux responsables de tests. Vous observez tout à coup un pic dans le nombre de bugs signalés pendant un cycle UAT.
Quelles sont alors vos options pour gérer l’inévitable drame de « l’inflation des défauts » ? C’est simple : commencez à suivre ce que Panaya appelle les « défauts à l’échelle système ». Réaliser ce suivi manuellement prendrait des siècles. Ce serait par ailleurs très fastidieux avec les outils ALM traditionnels qui ne permettent que d’établir des liens entre différents défauts et d’ajouter des commentaires. Mais si vous n’avez pas le choix des outils pour le moment, vous devrez réserver du temps au suivi attentif des défauts à l’échelle du système afin de justifier que la courbe des bugs soit à la hausse vers la fin d’un cycle de test, et non à la baisse. Si vous avez la possibilité d’essayer Panaya Test Dynamix, sachez que le moteur de cette solution prend en charge les SWD et peut les calculer en un clic.
La Toile d’araignée : figurant dans le « Cockpit des risques » de la plateforme Panaya, cette représentation graphique, aussi puissante que simple, de 6 indicateurs de performances clés supplémentaires réunit les KPI à suivre en priorité pour tous les responsables de qualité, de tests et de version.
Respect des exigences
Les responsables qualité comprennent très bien les risques, et ont besoin de bénéficier, pour chaque exigence, d’une visibilité au niveau du code ou du transport. Pour cela, il faut les bons outils. Panaya est le seul outil qui réponde aux attentes des entreprises qui utilisent SAP et qui ont besoin de recommandations intelligentes de tests unitaires et d’analyses des risques basées sur l’activité de transport. Ce niveau de suivi est offert par Panaya Release Dynamix (RDx).
Aboutissement du développement
Nous vivons dans l’ère du client, qui est moteur de la stratégie de transformation numérique de toutes les entreprises. Dans ce contexte, nous ne pouvons pas nous permettre de nous appuyer sur une vision ou une approche organisationnelle segmentée de l’assurance qualité et du delivery des logiciels. Nos modèles ALM traditionnels surannés n’ont pas été conçus pour le modèle de delivery continu d’aujourd’hui. Pour contrer cette approche obsolète, les responsables de l’assurance qualité et des tests doivent s’immerger au cœur de l’action du développement des applications, et se tenir informés du delivery des scénarios utilisateurs. Il ne suffit plus d’attendre qu’un scénario utilisateur atteigne l’état Terminé. Il faut en suivre l’évolution, assister aux Scrums quotidiens et discuter ouvertement des risques qui se manifestent lorsque des modifications importantes sont apportées à l’application testée. Ce processus est également pris en charge par Panaya Release Dynamix (RDx).
Couverture du plan de test
Il s’agit ici d’un KPI particulièrement intéressant à suivre parce que vous n’êtes plus limité à la portée des tests système, d’intégration, de régression et UAT. Toujours dans l’optique de détecter les défauts avant publication, nous cherchons de plus en plus à surveiller la couverture des tests unitaires. Cela vous semble fou ?
Pourtant, c’est loin d’être le cas, en particulier si vous êtes muni des bons outils qui faciliteront non seulement l’exécution des tests unitaires, mais aussi la capture des résultats (ou des preuves). Grâce aux capacités intégrées d’enregistrement et de lecture des tests de Panaya Test Dynamix, vous constaterez que les taux de participation aux tests unitaires augmentent de manière exponentielle. Et ce n’est pas tout : vous pourrez également afficher une Matrice de traçabilité des exigences illustrant la couverture de bout en bout, tout en présentant des résultats réels, des tests unitaires aux tests de régression, à votre service d’audit.
Analyse des risques de modification
Le risque est inhérent à toute modification que l’on apporte à une application en cours de test, mais on ne sait pas toujours si l’on teste les bons aspects. De nombreuses entreprises ont leur propre définition du « risque de modification ». Dans le « Cockpit des risques » de Panaya Release Dynamix (RDx), vous pouvez éliminer toute spéculation du suivi des modifications en utilisant Impact Analysis pour votre projet ou votre prochaine version. RDx calcule systématiquement le risque associé à chaque exigence et vous informe de son évolution au fil du cycle de vie de delivery.
Risque d’exécution des tests
Bien trop souvent, les entreprises suivent des KPI comme les tests qu’elles ont déjà élaborés, réussis, automatisés et exécutés. Mais pourquoi ne pas suivre également les étapes de chacun de ces tests ? La plupart des plateformes ALM courantes n’offrent pas de capacités de reporting clé en main permettant de suivre l’avancement de l’exécution des « étapes » des tests. Lorsqu’un cycle d’UAT comprend plusieurs « changements de mains », il est particulièrement utile de suivre les risques et l’état de l’exécution des tests, non seulement à l’échelle des tests, mais aussi à celle du processus métier. Et c’est précisément ce que permet Panaya Test Dynamix dès le départ.
Conclusion
Avec Panaya, les responsables de la qualité logicielle et toutes les autres parties prenantes atteignent leurs KPI de test favorisant l’innovation tout en réduisant les efforts de test de 30 à 50 % sans aucun compromis sur leur étendue ou leur qualité. Standardisez vos processus de test et évaluez véritablement la réussite de vos projets en munissant toutes les parties prenantes de la même méthodologie, afin d’acquérir une visibilité en temps réel sur tous les cycles de test, y compris les UAT à grande échelle.