KPI pour les tests logiciels - assurance qualité pour votre produit

Le développement d'un logiciel qui résout un "point de douleur" pour l'utilisateur est sans aucun doute le fondement d'un produit logiciel réussi. Il existe toutefois un autre aspect de la plus haute importance : les tests logiciels. Souvent, les tests de logiciels sont négligés, alors que le résultat des tests détermine si le produit se démarque de la concurrence - ou non.

Dans cet article, nous examinons de plus près l'importance des tests logiciels et la manière de mesurer si le développement du produit est sur la bonne voie. Nous vous présentons les indicateurs de performance (KPI) les plus présents pour tester le logiciel que vous avez développé, nous illustrons la théorie des tests logiciels par un exemple pratique et nous vous donnons des informations importantes sur la manière dont vous pouvez obtenir un avantage concurrentiel en testant votre logiciel.

Principaux indicateurs de performance (KPI) pour les tests logiciels

Il existe de nombreux KPI qui reflètent le succès des processus de test. Pour des raisons de brièveté et de priorité implicite, nous avons sélectionné les plus importants de ces KPI. Voici notre sélection :

KPI 1 "Requirements Test Coverage" - Exigences en matière de couverture de test

Requirements Test Coverage mesure la mesure dans laquelle les cas de test exécutés pendant le test couvrent l'ensemble des exigences fonctionnelles et non fonctionnelles spécifiées pour la Logiciel de l'entreprise. Pour que cet indicateur soit applicable, il faut que les exigences relatives au logiciel aient été entièrement spécifiées.

Interprétation et application de la couverture de test en tant que KPI :

  • Cet ICP garantit que chaque exigence est liée à au moins un cas de test qui la vérifie. Il est important de mentionner que chaque exigence peut être testée par plusieurs cas de test. En même temps, un test peut aussi vérifier plusieurs exigences logicielles. Cela signifie qu'il y a beaucoup trop de relations entre les cas de test et les exigences.
  • Une couverture de test des exigences de 100 % ne signifie pas qu'il n'y a pas d'autres tests possibles à écrire. Cela signifie seulement que chaque exigence est associée à au moins un cas de test. Cependant, il n'y a aucune garantie que ce cas de test couvre l'ensemble des spécifications de l'exigence.
  • N'oubliez pas : si les exigences envers le logiciel changent, les cas de test doivent également changer.
  • Pour mettre en œuvre ce KPI, vous devez Outils de traçabilité pour relier les cas de test et les exigences. Cette traçabilité aide à suivre les exigences qui ont déjà été testées et celles qui doivent encore l'être. Cette traçabilité permet de mesurer la couverture en pourcentage.

Exemple de "couverture de test des exigences

Vous occupez un poste de direction au sein d'une entreprise de commerce électronique qui prévoit une mise à jour complète de sa plateforme de commerce électronique afin d'améliorer l'expérience client. Pour ce faire, des exigences tant fonctionnelles que non fonctionnelles ont été définies. Dans le cadre du Processus d'assurance qualité il est essentiel de s'assurer que toutes les exigences sont suffisamment testées.

Votre équipe de développement utilise des outils de traçabilité pour relier les cas de test et les exigences. Cela vous permet de mesurer la couverture de test et de vous assurer que chaque exigence est couverte par au moins un cas de test.

Après avoir effectué les tests et relié les exigences et les cas de test, vous constatez que la couverture de test est de 90%. Cela signifie que 90% des exigences spécifiées ont été vérifiées par au moins un cas de test. C'est un bon résultat, mais qui montre qu'il y a encore une marge d'amélioration.

Lors de l'analyse de la couverture de test, vous constatez que certaines exigences non fonctionnelles, comme les performances de la plateforme sous une charge élevée, n'ont pas encore été suffisamment testées. Dans ce cas, vous devez vous assurer que des cas de test supplémentaires sont créés pour couvrir ces exigences spécifiques. En outre, il s'avère que certains cas de test couvrent plusieurs exigences et vice versa. Cela met en évidence la trop grande relation entre les cas de test et les exigences. Si des modifications sont apportées aux exigences au cours du développement, les cas de test doivent être adaptés en conséquence afin de garantir que la couverture de test Rquirements reste à jour.

En utilisant des outils de traçabilité et en vérifiant régulièrement la couverture des tests des exigences, vous vous assurez que la plateforme de commerce électronique répond aux exigences spécifiées et que les problèmes potentiels sont détectés et résolus à temps. Une couverture de test des exigences de 100% ne signifie pas nécessairement qu'aucun autre test n'est requis, mais que chaque exigence a été vérifiée au moins une fois.

KPI 2 "Code Coverage" - Couverture du code

La couverture de code mesure la quantité de votre code source, y compris les lignes de code, les instructions, les ramifications et les chemins d'accès, qui a été effectivement exécutée par vos tests.

Interprétation et application de la couverture de code en tant que KPI :

  • La couverture de code est généralement exprimée en pourcentage, par exemple 20% ou 90%. Un pourcentage plus élevé implique des tests plus étendus. Il n'y a pas de chiffre unique qui puisse être fixé uniformément comme objectif, mais si le pourcentage atteint plus de 70%, c'est une bonne valeur.
  • Les outils de couverture de code mettent souvent en évidence les lignes ou les branches de code spécifiques qui n'ont pas été exécutées par vos tests.
  • Si vous identifiez des zones de code non détecté, vous pouvez utiliser ces informations pour combler les lacunes des tests. Il est également possible de créer des cas de test supplémentaires ou de modifier des cas existants afin de tester ces chemins de code non découverts.

Exemple de "couverture de code

Votre plateforme de commerce électronique a récemment fait l'objet d'une mise à jour, au cours de laquelle de nouvelles fonctionnalités ont été ajoutées et certaines fonctionnalités existantes ont été modifiées. Dans le cadre de votre processus d'assurance qualité, il est important de s'assurer que l'ensemble du code a été suffisamment testé, en particulier après de telles mises à jour.

Votre équipe de développement utilise un outil de couverture de code pour s'assurer que les cas de test parcourent le code de manière approfondie. Après la Mise à jour vous effectuez une analyse de couverture de code et constatez que la couverture de code n'est que de 65%. Cela signifie que seuls 65% du code source ont été parcourus par vos cas de test.

L'outil de couverture de code met en évidence les lignes et les branches de code spécifiques qui n'ont pas été exécutées par les tests. Dans ce cas, on remarque que certaines des nouvelles fonctionnalités et parties du code existant n'ont pas été suffisamment testées.

Pour améliorer la couverture de code, prenez les mesures suivantes :

  1. Identification des lacunes des tests: ils analysent les lignes et les branches de code mises en évidence qui n'ont pas été atteintes par les tests et identifient les zones de code non détectées.
  2. Création de nouveaux cas de testVous créez des cas de test supplémentaires qui couvrent ces chemins de code non découverts. Cela peut impliquer de développer des scénarios spécifiques qui testent en profondeur les nouvelles fonctionnalités ou de modifier les scénarios de test afin de prendre en compte ces nouveaux domaines.
  3. Modification des cas de test existantsIls révisent les cas de test existants afin de s'assurer qu'ils couvrent les parties modifiées du code.

En prenant ces mesures, vous augmentez la couverture du code et garantissez un test suffisant des nouvelles fonctions et des parties modifiées du code.

KPI 3 "Test Automation Coverage" - Couverture de l'automatisation des tests

Test Automation Coverage vous montre quelle proportion de tous les cas de test disponibles dans le cadre de votre ensemble de tests est automatisée. Cette métrique est obtenue en divisant simplement le nombre de tests automatisés par le nombre total de tests - automatisés et manuels. Il est important de mentionner que tous les cas de test à prendre en compte sont ceux qui sont exécutés au niveau du système - c'est-à-dire de manière à ce que chaque utilisateur final du logiciel puisse les exécuter.

Interprétation et application de la couverture de l'automatisation des tests en tant que KPI :

  • La couverture de Test Automation est exprimée en pourcentage. Un pourcentage plus élevé signifie une meilleure couverture et inversement.
  • L'automatisation des tests n'est pas un processus rapide, elle nécessite du temps et donc une bonne planification. Pour savoir quels tests doivent être automatisés en premier, vous devez définir des priorités. Tenez compte par exemple de la fréquence d'utilisation de la fonctionnalité testée, de la dépendance par rapport à d'autres cas de test et de la complexité de l'implémentation de votre logiciel. Les cas de test ayant une priorité élevée, une forte dépendance et une faible complexité sont de bons candidats pour l'automatisation.
  • L'automatisation des tests n'a guère de fin tant que vous continuez à développer votre produit. N'oubliez pas de vérifier et de mettre à jour régulièrement vos cas de test automatisés afin qu'ils reflètent les derniers changements en termes de fonctionnalités et de performances.

Exemple "Couverture de l'automatisation des tests

Restons dans le cas de notre entreprise, qui exploite une plateforme de commerce électronique sur laquelle les clients peuvent acheter des produits. Votre plateforme comporte de nombreuses fonctionnalités, notamment la recherche de produits, le panier d'achat, le traitement des commandes et les évaluations des clients. En tant que responsable de l'assurance qualité, vous êtes chargé de superviser l'automatisation des tests et d'assurer une bonne couverture des tests.

Votre plateforme d'e-commerce a un total de 500 cas de test différents qui sont pertinents pour le niveau système. Il s'agit de tests qui garantissent qu'un utilisateur final peut utiliser toutes les fonctions importantes de la plateforme. Pour calculer votre couverture d'automatisation des tests, vous avez automatisé 200 de ces tests. Cela signifie que 200 de vos cas de test sont exécutés par un framework d'automatisation des tests, tandis que les 300 restants sont exécutés manuellement par des testeurs.

La couverture de l'automatisation des tests, dans ce cas, est de :

(cas de test automatisés / nombre total de cas de test pertinents) x 100 = (200 / 500) x 100 = 40%

Cela signifie que votre couverture d'automatisation des tests est de 40%. Cela signifie que 40% de vos cas de tests pertinents automatisé alors que les 60% restants sont effectués manuellement. Cela peut être dû à différents facteurs, comme les contraintes de temps et de ressources ou la difficulté d'automatiser certains tests.

Pour améliorer la couverture de l'automatisation des tests, les étapes suivantes sont possibles :

  1. Donner la prioritéIls analysent les tests les plus fréquemment effectués par les utilisateurs, comme par exemple la recherche de produits et le traitement des commandes. Ces tests sont prioritaires pour l'automatisation.
  2. Tenir compte des dépendancesIls identifient les cas de test qui dépendent fortement des autres. Les tests automatisés doivent être ceux qui ont le plus d'impact sur les autres tests afin d'augmenter l'efficacité.
  3. Prendre en compte la complexitéLes tests faciles à automatiser doivent être privilégiés, car ils demandent moins de temps et de ressources.
  4. Mise à jour régulière: ils veillent à ce que les cas de test automatisés soient constamment révisés et adaptés aux dernières modifications de la plateforme afin de maintenir la couverture de test à jour.

En appliquant ces principes, vous serez en mesure d'augmenter la couverture de l'automatisation des tests et de garantir la qualité de votre plateforme de commerce électronique, tout en utilisant efficacement le temps et les ressources.

KPI 4 "Defect Detection Efficiency - DDE" - Efficacité de la détection des défauts

Defect Detection Efficiency (DDE) est exprimé en pourcentage et représente la proportion de défauts ou de bugs détectés par les tests par rapport au nombre total de défauts/bugs dans la Logiciel est.

La formule de calcul du taux de détection des défauts est la suivante :

Taux de détection des erreurs (%) = (nombre d'erreurs trouvées lors du test / nombre total d'erreurs) x 100

Interprétation et application de la formule de DDE comme KPI :

  • Un pourcentage plus élevé signifie que les tests sont plus efficaces. Il indique que votre procédure de test est suffisante et que seul un nombre minimal d'erreurs sera introduit dans l'environnement de production.
  • Un faible pourcentage signifie que votre processus de test est moins efficace pour détecter les erreurs et que vous devez étendre votre ensemble de tests. Pour décider de la manière de procéder, vous pouvez utiliser les données fournies par vos outils de couverture de code.

Exemple "Defect Detection Efficiency" (efficacité de la détection des défauts)

Une équipe de développement de logiciels travaille sur un nouveau système de commerce électronique. Durant la phase de développement, 100 erreurs ou bugs ont été identifiés dans le code. Avant de passer à l'environnement de production, le logiciel est soumis à des tests approfondis afin d'identifier et de corriger les erreurs. Au cours de ces tests, 80 des 100 erreurs sont trouvées et corrigées.

Pour calculer la DDE, nous utilisons la formule suivante :

DDE (%) = (nombre d'erreurs trouvées lors du test / nombre total d'erreurs) x 100

Insérons les valeurs dans la formule :

DDE (%) = (80 / 100) x 100 = 80%

Dans cet exemple, le Defect Detection Efficiency (DDE) est de 80%. Cela signifie que 80% des défauts présents ont été trouvés pendant les tests. Une DDE élevée indique que les efforts de test sont efficaces. Seuls 20% des défauts pourraient passer inaperçus dans l'environnement de production.

Dans la pratique, l'équipe de développement s'efforcerait de maintenir la DDE aussi élevée que possible afin de garantir la qualité du logiciel et de minimiser les plaintes des clients ou les problèmes de qualité après la publication. Si la DDE était plus faible, les testeurs et les développeurs repenseraient leur stratégie de test et augmenteraient éventuellement la couverture de test afin de garantir une meilleure détection des erreurs. L'utilisation d'outils de couverture de code pourrait notamment favoriser cela et identifier les zones du code qui n'ont pas été suffisamment testées.

KPI 5 "Escaped Defects" - Défauts échappés

Le terme "Escaped Defects", en français "erreurs manquées", fait référence à des erreurs ou des problèmes dans une Application logicielleLes problèmes qui n'ont pas été détectés et résolus pendant la phase de test et qui ont ensuite été introduits dans l'environnement de production. Ils ont "échappé" au processus de test et ont été découverts par l'utilisateur final. Les utilisateurs finaux ne sont pas seulement des clients, mais aussi des intervenants internes qui ont découvert le défaut en dehors du processus de test.

Interprétation et application des défauts d'échappement en tant que KPI :

  • Les défauts échappés peuvent entraîner une augmentation des coûts de maintenance. La correction des bugs dans l'environnement de production est souvent plus coûteuse et prend plus de temps que la correction en phase de test.
  • Ces erreurs peuvent avoir un impact négatif sur l'expérience de l'utilisateur.
  • La présence de défauts échappés peut indiquer des lacunes dans le processus de test, par exemple une couverture insuffisante du code, une couverture insuffisante des tests d'exigences ou un manque de cas de test efficaces.

Exemple "Escaped Defects" (défauts évités)

Votre entreprise de commerce électronique a récemment lancé une nouvelle version de sa plateforme de commerce électronique dans l'environnement de production, avec quelques modifications et améliorations significatives. Avant sa mise en ligne, le logiciel a subi une phase de test approfondie, au cours de laquelle les développeurs et les équipes d'assurance qualité ont soigneusement examiné les exigences, la couverture du code et différents cas de test.

Quelques semaines après la sortie de la nouvelle version, vous commencez à recevoir des rapports de problèmes et d'erreurs de la part des utilisateurs finaux. Ces erreurs nuisent à l'expérience utilisateur et donnent lieu à des plaintes de la part des clients. En examinant ces erreurs manquées, vous constatez qu'elles sont dues à des vulnérabilités non détectées dans l'environnement de production. Ces vulnérabilités n'ont pas été détectées pendant la phase de test et se sont retrouvées dans l'environnement en direct.

Une telle erreur manquée est par exemple une erreur dans le processus de commande qui fait que les commandes ne peuvent pas être finalisées correctement. Cela nuit considérablement à l'expérience utilisateur et entraîne une perte de chiffre d'affaires, car les clients ne peuvent pas mener à bien leurs achats.

Les conséquences des erreurs manquées sont nombreuses :

  1. Coûts de maintenance plus élevés: La correction des bugs dans l'environnement de production nécessite des ressources et du temps supplémentaires. Cela entraîne une augmentation des coûts de maintenance, car les développeurs et les équipes d'assistance doivent travailler d'urgence à la correction des bugs plutôt que de travailler sur de nouvelles fonctionnalités.
  2. Expérience utilisateurLes erreurs manquées nuisent à l'expérience utilisateur et peuvent conduire les clients à être insatisfaits et à se tourner vers la concurrence.
  3. Processus d'assurance qualitéLes erreurs manquées indiquent de possibles lacunes dans le processus de test. Cela indique éventuellement une couverture insuffisante du code, une couverture insuffisante des exigences ou des cas de test inefficaces. Il est important de revoir et d'améliorer le processus de test afin d'éviter de telles erreurs à l'avenir.

En conséquence, il est important d'analyser les erreurs manquées et de les corriger tout en renforçant le processus de test afin d'éviter de tels problèmes dans les futures mises à jour du logiciel. Cela contribuera à réduire les coûts de maintenance et à maintenir la confiance des utilisateurs dans votre plateforme de commerce électronique.

KPI 6 "Customer Satisfaction" - Satisfaction des clients

Même si la satisfaction du client n'est pas directement et exclusivement liée aux tests logiciels, vous devez prendre en compte cet indicateur de performance clé (KPI) à la fois dans l'élaboration et dans la Optimisation d'une stratégie de test de logiciel. Customer Satisfaciton est une mesure de la capacité de votre logiciel à répondre aux attentes des utilisateurs. De cette manière, ce KPI peut vous montrer - en plus des connaissances sur la fonctionnalité elle-même - quel est le niveau de qualité perçu de votre logiciel.

Interprétation et utilisation de la satisfaction client comme KPI :

  • Il existe de nombreuses enquêtes que le client doit remplir régulièrement et qui fournissent une valeur numérique de la satisfaction du client. Exemples : Net Promoter Score ou Score d'effort du client.
  • Bien que les valeurs numériques soient simples et rapides à comprendre, ne vous fiez pas uniquement à elles. Assurez-vous plutôt d'intégrer des questions qualitatives. Ces réponses vous montreront le "pourquoi" derrière le chiffre qui, dans de nombreux cas, n'est pas une fonction manquante, mais simplement un produit logiciel peu fiable et plein d'anomalies.
  • Évaluez le lien entre les problèmes identifiés et vos procédures de test. Déterminez si ces problèmes auraient pu être détectés par des tests plus complets ou plus ciblés. Il pourrait s'agir de tests fonctionnels, de tests de facilité d'utilisation, de tests de performance ou de tests de sécurité.

Exemple "Satisfaction du client

Votre entreprise de commerce électronique a mené une enquête auprès de ses clients et a utilisé le Net Promoter Score (NPS) pour mesurer la satisfaction des clients. Le NPS a donné une note moyenne de 7. Bien que cela semble positif à première vue, les réponses qualitatives ont montré que les clients avaient des problèmes avec les performances du site, ce qui a affecté leur expérience d'achat.

L'analyse qualitative a montré que ces problèmes de performance affectaient la qualité perçue du logiciel. La cause en était des tests de performance insuffisants pendant le développement. En réaction, ils ont optimisé la stratégie de test et intégré des tests de performance plus complets.

Le Customer Satisfaction KPI a aidé à identifier l'écart entre les exigences des clients et les procédures de test et à adapter la stratégie de test afin d'augmenter la satisfaction des clients et d'assurer le succès à long terme de l'entreprise.

Conclusion sur les KPI pour les tests de logiciels

Tests logiciels KPIs Conclusion

Les tests logiciels se révèlent souvent être un aspect négligé du développement de logiciels. Pourtant, les tests de vos logiciels jouent un rôle central dans le succès d'un produit. Il existe une multitude d'indicateurs clés de performance (KPI) permettant d'évaluer la qualité des tests effectués à chaque itération.

Il n'est pas réaliste ni même nécessaire d'appliquer tous les KPI. Cependant, ils sont souvent complémentaires et doivent être considérés en combinaison.

Par exemple, c'est une façon de suivre l'évolution de l'indicateur de performance des effets d'échappement à travers les différentes versions du logiciel. Ainsi, ce KPI décide en fin de compte de l'estimation du succès de toutes vos stratégies de test. Cependant, d'autres KPI tels que Code Coverage, Test Automation Percentage et DDE vous aident à décider sur quelles parties du logiciel vous devriez vous concentrer dans vos efforts pour améliorer votre stratégie de test si le nombre d'effets d'échappement augmente.

RemarqueEn outre, lors de la mise en œuvre de ces indicateurs clés de performance, veuillez tenir compte d'autres bonnes pratiques de développement logiciel, telles que l'investissement de temps et d'efforts dans l'analyse des exigences afin d'obtenir un ensemble complet d'exigences.

Vous avez des questions sur le thème des tests logiciels ? Envoyez-nous un message.








    "
    "
    Avatar de Bojidar Parvanov

    Derniers articles