État de l'Intelligence Artificielle appliquée à l'Ingénierie de la Qualité 2021-2022
Section 3.1 : Mesures

Chapitre 2 par Capgemini & Sogeti

Des simples métriques à l'analytique intelligente

Métier ●●●○○
Technique ●●○○○

 

Download the "Section 3.1: Inform & Measure" as a PDF

Use the site navigation to visit other sections and download further PDF content

 

By submitting this form, I understand that my data will be processed by Sogeti as described in the Privacy Policy.

La qualité n'est jamais un accident. Elle est toujours le résultat d'un effort intelligent.
(John Ruskin)

L'utilisation d'analyses et de tableaux de bord basés sur le Machine Learning nous aide à prendre des décisions éclairées et à accroître l'efficacité et l'efficience de nos activités.

Dans le chapitre précédent, nous avons examiné l'importance des portails qualité dans notre culture d'amélioration continue. Ils contribuent à accroître le niveau de transparence et à améliorer nos processus. Plus important encore, elles s'appuient sur des mesures pour donner un aperçu de la progression des tests de notre équipe, de la productivité et de la qualité du système testé. Cependant, alors que nos techniques de développement ont considérablement évolué au cours des cinq dernières années, nos mesures sont restées pour la plupart cohérentes.

Les questions telles que "quoi tester", "quoi automatiser", "comment automatiser davantage" et "quand arrêter les tests tout en conservant le même niveau de qualité" trouvent toujours leurs réponses dans des estimations et des jugements d'experts.

Et si nous pouvions répondre à des questions telles que "Nos tests ont-ils atteint leur objectif ?", "Pourquoi des problèmes sont-ils survenus ?", "Combien de temps ou d'efforts faudra-t-il pour corriger les futurs défauts ?", "Que devrions-nous tester maintenant ?". Il y a tellement de possibilités pour établir des métriques dans les tests que le critère clé que les équipes et les organisations dans leur ensemble devraient se fixer est de se demander :

  • Est-ce que le fait d'avoir cette métrique aide à déterminer si l'application sera un atout pour l'entreprise ?
  • Sommes-nous en mesure d'améliorer éventuellement la productivité des utilisateurs finaux ?
  • Comment les métriques nous aident-elles à améliorer notre efficacité et notre efficience ?

Dans ce chapitre, nous passons en revue les principes fondamentaux des métriques utiles, et comment l'IA peut nous fournir des analyses d'assurance qualité encore plus intelligentes.  

Choisir les bons indicateurs

Pour préparer le terrain, arrêtons-nous un instant sur les différentes approches de l'identification des mesures. TMAP recommande  d'aborder es métriques par le biais d'un processus itératif et collectif les métriques par le biais d'un processus itératif et collectif. Ils définissent les bonnes mesures comme étant centrées sur l'entreprise, améliorables et inspirant l'action. Les mesures doivent être utilisées pour les bonnes raisons. Par exemple, tout indicateur d'automatisation des tests doit nous permettre de nous concentrer sur la qualité globale, plutôt que sur l'obtention d'une automatisation à 100%. Les métriques calculées doivent nous permettre de :

  • Soutenir les activités de test et les décisions associées.
  • Vérifier continuellement l'évolution (amélioration ou dégradation de la qualité) de la qualité sous la forme d'un ensemble de métriques calculées en continu.
  • Utiliser des seuils et des critères compilés, pour agir comme des portes de qualité dans un pipeline de livraison continue.

Équilibrer l'efficacité et l'efficience

Les indicateurs nous aident à suivre nos activités en cours et à identifier les domaines à améliorer. À ce titre, nous devons constamment examiner l'efficacité et l'efficience de nos efforts. L'efficience et l'efficacité sont deux notions étroitement liées, avec une différence sémantique subtile mais néanmoins significative.

  • L'efficacité indique si le résultat du processus a été atteint ou non. Contrairement à l'efficience, l'efficacité ne porte pas sur le processus lui-même, mais sur son résultat.
    • Pourcentage de tests unitaires réussis, couverture du code, couverture des exigences, anomalies critiques détectées.
  • L'efficience est le degré d'utilisation des ressources pour accomplir une tâche. (L'utilisation d'une métaphore telle que le chemin le plus court vers la cible peut être bénéfique). Un processus est dit efficace lorsque peu de ressources sont utilisées par rapport à la norme commune convenue. Ces ressources peuvent être, par exemple, du temps, des efforts (heures-personnes), des marchandises ou de l'argent.
    • Pourcentage de tests automatisés, pourcentage du coût des tests, densité de défauts
Figure: Productivity quadrant

Figure: Quadrant de productivité

La valeur des métriques

En 2019, Tricentis a demandé à Forrester de mener une recherche sur les métriques de qualité les plus critiques pour le succès de DevOps. Les résultats ont été compilés dans un ebook de 55 pages, qui a catégorisé toutes les métriques à travers 4 sections de valeur.

  • Valeur ajoutée : Métriques fréquemment utilisées par les experts DevOps et systématiquement jugées précieuses par les organisations qui les mesurent.
  • Perles rares : Les mesures qui ne sont pas utilisées fréquemment par les experts DevOps, mais qui sont systématiquement considérées comme précieuses par les organisations qui les mesurent.
  • Surévaluées : Mesures utilisées fréquemment par les experts DevOps, mais qui ne sont pas considérées comme utiles par les organisations qui les mesurent.
  • Distraction : Mesures qui ne sont pas utilisées fréquemment par les experts DevOps et qui ne sont pas jugées utiles par les organisations qui les mesurent.
Figure: Metrics quadrant


Figure: Metrics quadrant

Évolution récente des mesures de qualité

Le rapport 2020 sur l'état des tests continus indiquaient que les trois principales mesures de l'efficacité des tests continus se concentraient sur les résultats commerciaux (données de production, retours utilisateurs et retour sur investissement). Plus des trois quarts des personnes interrogées (78 %) ont déclaré que "l'obtention d'une visibilité tout au long du cycle de développement" constitue un défi lors de la mise en œuvre des tests continus. Cela montre que les organisations gagnent en maturité et qu'elles s'intéressent de plus près à la fourniture d'une qualité et d'une valeur globales pour l'entreprise et le client final.

Figure: Survey question from the 2020 Continuous Testing Report


Figure: Question d'enquête tirée du rapport 2020 sur les tests continus

Lorsqu'on leur a demandé comment ils suivaient l'efficacité des tests continus, les trois premières réponses se sont concentrées sur le résultat de la fonctionnalité (données de production, retour d'expérience des utilisateurs et retour sur investissement). Cela suggère que la majorité des répondants sont plus préoccupés par les résultats de l'entreprise que par les KPI au niveau des processus. Cependant, étant donné que les KPI au niveau du processus/technique sont plus exploitables, les équipes voudront mesurer les métriques qui soutiennent leur travail et leur prise de décision. Au fur et à mesure que les tests continus gagnent en maturité, les indicateurs clés de performance de niveau inférieur, tels que le niveau d'automatisation, la couverture des exigences et les défauts trouvés, s'améliorent, et ces résultats sont visibles dans les mesures commerciales de niveau supérieur qui révèlent la qualité et la valeur globales pour l'entreprise et le client final.

Mesures de qualité par rapport à la fréquence de publication

Pour beaucoup, la livraison continue est l'état final souhaité, permettant de diffuser une nouvelle fonctionnalité dès qu'elle est développée. Nous pensons que le choix des métriques de qualité pour un produit donné dépend fortement de ce cycle de publication, qu'il soit immédiat et incrémentiel, d'un mois ou même plus long. Dans le tableau ci-dessous, nous proposons une correspondance entre le calendrier de livraison et des exemples de métriques.

Fréquence de parution
Moins d'un jour Entre un jour et une semaine Entre une semaine et un mois
  • Constructions de code réussies
  • Taux de réussite/échec des tests BVT
    • Sélection et exécution automatisées basées sur les changements :
    • Résultats de l'analyse statique du code
    • Revues de code automatisées
      Réussite/échec des tests unitaires
    • Test de régression réussi/échec
    • Test de fonctionnalité réussi/échec

Mêmes mesures que pour la "fréquence de déploiement inférieure à un jour", en plus de cela,

  • Sélection et exécution automatisées basées sur les changements :
    • Couverture du code
    • Test de régression (Nombre de défauts réouverts)
    • Couverture fonctionnelle
    • Couverture des exigences d'intégration

Mêmes mesures que précédemment, en plus de la sélection et de l'exécution automatisées basées sur les changements :

  • Couverture des exigences non fonctionnelles
  • Couverture des exigences du système
  • % d'échecs en production ou sur le terrain

L'essor de l'analyse intelligente

Nous venons d'examiner que les données peuvent facilement être transformées en métriques pour surveiller et suivre les activités. Les mesures se concentrent principalement sur le "quoi", pour évaluer les performances ou les progrès de nos activités. Cependant, les mesures seules ne nous aideront pas à prendre des mesures, à comprendre ce qui se passe ou à améliorer les résultats. Les activités d'ingénierie de la qualité génèrent un grand volume de données structurées et non structurées qui sont souvent laissées en suspens et inutilisées.

Le développement récent de l'IA peut aider à transformer les données et les mesures en analyses intelligentes pour nous aider à prendre de meilleures décisions. Par exemple, elle peut rendre obsolètes certains de nos tests antérieurs, si des données comparables sont disponibles. En outre, nous pouvons être en mesure de détecter les tests à faible priorité ou à faible valeur, tels que ceux concernant des fonctionnalités qui ne sont pas utilisées.

Des analyses peuvent être recueillies pour nous aider à valider nos critères de qualité d'utilisation et pour obtenir un retour d'information sur l'efficacité des tests effectués et de ceux qui ont été omis pour cette version. Dans l'idéal, aucun plantage ou défaut ne sera signalé si nos tests étaient adaptés à l'objectif (en supposant que tous les problèmes connexes ont été corrigés avant la publication). De plus, au fur et à mesure que nous acquérons des connaissances grâce aux analyses, nous pouvons développer des tests plus efficaces pour les futures versions de l'application.

De même, le responsable du développement de produits aura un aperçu de la rotation du code qui s'est produite à chaque construction, de la qualité de la construction et des taux de réussite des tests à chaque phase des tests. L'analyse peut également servir à prédire le pourcentage de risque de trouver des défauts critiques en production.

Figure: example of predictive analytics

 

Figure: exemple d'analyse prédictive

Dans le cadre de ce chapitre, nous nous concentrerons sur trois catégories de capacités d'analyse, décrites ci-dessous :

Capacités d'analyse
  Analyse descriptive Analyse prédictive Analyse prescriptive
Objectifs L'analyse descriptive peut rendre les données de test plus informatives et déterminer ce qui s'est passé dans les cycles de test précédents. Cela semble être une intelligence d'orchestration standard, mais les données sources s'étendent sur plusieurs référentiels. L'analyse prédictive nous permet de comprendre les informations que nous possédons actuellement et de prévoir ce qui pourrait se produire. L'apprentissage automatique peut fournir des informations précieuses sur l'affectation des ressources et du temps. Les analyses prescriptives permettent de traduire les observations et prévisions ci-dessus en actions tangibles et de générer des recommandations concrètes sur ce qui devrait se produire, y compris la mise en œuvre de ces recommandations.
Focus Rapport et analyse basés sur des données historiques Prévision et simulation pour prévoir les problèmes critiques, réduire les temps de réaction et automatiser la résolution. Alertes et recommandations pour optimiser les tests et augmenter la détection des défauts
Cas d'utilisation axés sur le ML
  • Classifier un nouveau défaut par rapport aux niveaux de gravité, à l'origine des défauts, au temps de correction, etc.
  • Classifier une nouvelle exigence par rapport au niveau de testabilité
  • Classifier un composant nouveau ou modifié en fonction de sa propension à l'erreur
  • Améliorer la priorisation des tests par la prédiction du risque lié aux exigences.
  • Améliorer la planification des tests par la prédiction du nombre attendu de défauts et de leur gravité.
  • Optimiser l'allocation des ressources de test par la prédiction du temps d'exécution des tests requis.
  • Hiérarchisation des fonctionnalités par version
  • Hiérarchisation des cas de test pour obtenir le meilleur résultat possible.
  • Amélioration du scénario de conception des tests en fonction des modèles d'utilisation de l'utilisateur final en production.
Figure: Additional examples of smart analytics

Figure: Autres exemples d'analyse intelligente  

Exemple concret d'utilisation de Cognitive QA

Cognitive QA est une plateforme d'analyse en temps réel développée par Capgemini qui permet aux professionnels de l'assurance qualité d'améliorer leur prise de décision. Alors que certains indicateurs sont disponibles mais dispersés sur plusieurs plateformes, l'objectif est de fonctionner comme une tour de contrôle unique. Cognitive QA permet de relever des défis typiques tels que l'incapacité à terminer le cycle de test de régression en raison du volume de cas de test, du temps limité, des contraintes de ressources ou de l'absence de stratégie d'automatisation des tests.

Figure: high-level architecture of Cognitive QA

Figure: high-level architecture of Cognitive QA

Comme l'absence de préparation des données et de cartographie des actifs équivaut à l'inéligibilité au déploiement, une évaluation de la qualité, du volume et de l'intégrité des données est effectuée avant toute considération. Une enquête plus approfondie est réalisée autour des aspects suivants :

  1. Identifiez les informations (en temps réel) manquantes dans le processus de décision.
  2. Préparez les différentes mesures et analyses de la qualité commerciale et technique
  3. Identifiez tous les points de données nécessaires pour mesurer la qualité
  4. Mettez en correspondance les points de données avec les sources de données requises, par exemple la gestion des exigences, la gestion des cas de test, la gestion des défauts, la gestion des tickets de production, le retour d'information du magasin d'applications, etc.)
  5. Vérifiez l'intégration entre les différents systèmes
  6. Réalisez un petit pilote pour vérifier que les champs axés sur la qualité (pour mesurer la qualité) sont disponibles dans les systèmes sources et que les ingénieurs saisissent les bonnes données. Il s'agit d'une étape importante, car les champs sont très souvent soit manquants, soit mal spécifiés.
  7. Si des données sont manquantes dans les champs, il faut alors mener une gestion du changement pour les ingénieurs afin de s'assurer que les bonnes données sont saisies dans le système.
  8. Une fois tout cela fait, l'étape finale consiste à corréler les données, à mettre en œuvre des algorithmes d'apprentissage automatique (pas d'approche de type "taille unique"), à fournir une visualisation, des alertes et une intégration de chatbot.
Exemples de tableaux de bord
Analyse descriptive Analyse prédictive Analyse prescriptive
  • Analyse des défauts à 360 degrés
  • Analyse à 360 degrés des cas de test
  • Productivité et efforts
  • Résumé de l'automatisation
  • Résumé des défauts
  • Résumé des défauts de production
  • Résumé des réponses et des performances
  • Prévision des anomalies
  • Prédiction du temps nécessaire à la correction des anomalies
  • Prédiction des défaillances des cas de test
  • Prédiction des efforts de conception
  • Prédiction des efforts d'exécution des tests
  • Ce qu'il faut automatiser
  • Que tester ?
  • Analyse "What if"
  • Correspondance entre défauts et scénarios de test
  • Correspondance entre les cas de test et les exigences
  • Entités dupliquées (exigences, cas de test, défauts)

Par exemple, la plateforme Cognitive QA nous permet d'effectuer des analyses approfondies pour déterminer les causes exactes des problèmes et leur impact sur le système. Dans une approche manuelle typique, l'analyse des causes profondes (RCA) peut prendre des jours, voire des semaines, pour être menée à bien. Le "rapport d'analyse des causes profondes" illustre un rapport RCA automatisé. Il permet d'effectuer une plongée en profondeur par projet, application, module avec une distribution pareto automatisée. Cela aide réellement à déterminer où des ressources/du temps supplémentaires devraient être investis pour résoudre les problèmes. Ce rapport utilise un algorithme quasi-Monte Carlo avec classement, ainsi que quelques autres techniques NLP. On peut utiliser une machine à remonter le temps pour réexécuter l'analyse. Cela nous permet de tirer les leçons des versions précédentes et d'affiner notre stratégie.

Figure: Root Cause Analysis Report

 

Dans le graphe "quoi tester", nous examinons comment augmenter la qualité avec des tests basés sur les risques pour chaque build de développement. Cognitive QA nous aide à prendre des décisions sur les cas de test à exécuter pour une application spécifique ou un flux de bout en bout. Cela peut être accompli par l'utilisation d'une approche de classement par traitement du langage naturel (NLP).

Figure: What To Test

 

Souvent, le temps disponible pour le cycle de test est si restreint que nous ne sommes pas en mesure de terminer le cycle de régression complet. Cependant, nous sommes sous pression pour créer un travail de haute qualité. De plus, nous pouvons ajouter une dimension temporelle aux données et prescrire un ensemble fixe de cas de test pour assurer la plus grande couverture de test possible dans le temps imparti. La plateforme Cognitive QA peut nous aider à identifier les cas de test hautement prioritaires dans un projet en attribuant un rang à chaque cas de test. Le classement des tests est déterminé à l'aide du score de sélection des tests, qui est calculé en combinant le score d'exécution, le score d'échec, le score de défaut, le score de récence et le score de risque pour chaque test.

Exemple 1:

Une société de stockage aux États-Unis étudiait la manière de hiérarchiser les tests et les configurations en fonction de la probabilité de risque et d'échec. L'idée était de gagner du temps et de faire un meilleur usage du matériel disponible.

  • La plate-forme a recommandé 325 suites de tests à haute priorité et 571 suites de tests à faible priorité sur un total de 896.
  • Seules 44 configurations ont reçu une cote de priorité élevée sur 192.

Exemple 2:

Un fournisseur de solutions d'imagerie médicale envisageait de modifier sa technique de sélection des tests de régression en fonction de différentes entrées. La liste de tests recommandée devait être incluse dans les cycles d'exécution des tests automatisés. La plate-forme a correctement suggéré de se concentrer sur 1 664 cas de test de régression parmi les 13 721 existants.

Figure: What to Automate

 

Nous devons également tenir compte de la fréquence à laquelle les cas de test étaient réalisés auparavant, de la vitesse des changements de code, de l'interdépendance des applications, des cas de test et des données de test, ainsi que des exigences de conformité, de sécurité, de performance et de retour sur investissement. La figure "quoi automatiser" nous aide à prioriser les cas de test automatisés. Ceci peut être réalisé en utilisant une solution de classement par traitement du langage naturel (NLP).

Avoir peu ou pas de visibilité sur les risques et les fuites de fautes en production est un défi récurrent, avec un impact direct sur l'entreprise. Depuis des années, de nombreuses méthodes sont employées pour prévoir les problèmes avec un haut niveau de précision. Le défi est qu'aucun modèle de prévision ne peut être simplement estimé statistiquement à partir des tendances des défauts. Il doit également tenir compte des vérifications de code, de la volatilité des exigences et d'une variété d'autres facteurs. La figure "prédiction des défauts" illustre l'étendue des résultats du modèle de prédiction. Des algorithmes tels que la régression linéaire permettent d'atteindre 98% de précision.

Figure: Defect Prediction

 

Nous sommes maintenant arrivés au point de choix critique "d'être ou de ne pas être". La seule décision qui peut propulser une entreprise au niveau supérieur ou qui peut éroder la confiance des clients et avoir un impact négatif sur les revenus et la réputation de la marque. Il y a toujours un débat pour savoir si nous testons suffisamment ou si nous testons trop, et finalement, comment nous pouvons livrer les produits à temps et avec la meilleure qualité. À mesure que le processus de pipeline DevOps mûrit, il est également essentiel de considérer la rapidité avec laquelle nous pouvons répondre aux erreurs qui se produisent en production. De temps en temps, nous pouvons prendre un gold build, le stabiliser dans un environnement de test, et nous assurer que tous les problèmes découverts sont traités par des hotfixes. Nous pouvons également publier immédiatement des produits et des correctifs. Savoir quand cesser les tests vous donne toutes les informations nécessaires pour faire le meilleur choix. Il vous donne toutes les informations nécessaires pour prendre une décision éclairée. Il génère des recommandations basées sur l'apprentissage automatique, le traitement du langage naturel et les principaux indicateurs de performance clés.

Figure: When To Stop Testing

About the authors

Maheshwar KanitkarMaheshwar Kanitkar

Maheshwar is a Senior technology executive with over 25 years of rich experience in large corporate and start-up environments. During this period, Maheshwar has performed several leadership roles in driving business (top-line and bottom-line), Innovation, R&D, Product Management, Partnership, Analyst relationship, Workforce Productivity, Talent Transformation, Project delivery. Maheshwar's Strength is in driving transformation internally within the organization resulting in significant growth and bottom-line impact and also working closely with the customer in helping them achieve their business transform. Maheshwar lead Innovation COE for AI and QE. Maheshwar has Hands-on expertise in Cloud, AI, Automation, Dev-OPS, test automation technologies, building High-Performance Multi-Cultural Leadership Team around the globe, and turn around project delivery. Maheshwar leads testing portfolio sales & solutions for Capgemini Europe.

Vivek Jaykrishnan

Vivek Jaykrishnan

Vivek Jaykrishnan is an enterprise test consultant and architect with extensive experience. He has over 22 years of experience leading Verification and Validation functions, including functional, system, integration, and performance testing, in leadership positions with reputable organizations. Vivek has demonstrated success working across a variety of engagement models, including outsourced product verification and validation in service organizations, independent product verification and validation in captive units, and globally distributed development in a product company. Additionally, Vivek has extensive experience developing and implementing test strategies and driving testing in accordance with a variety of development methodologies, including continuous delivery, agile, iterative development, and the waterfall model. Vivek is passionate about incorporating cognitive intelligence into testing and is also interested in exploring the frontiers of IoT testing.

Antoine Aymer

Antoine Aymer (chief editor)

Antoine Aymer is a passionate technologist with a structured passion for innovation. He is currently the Chief Technology Officer for Sogeti's quality engineering business. Antoine is accountable for bringing solutions and services to the global market, which includes analyzing market trends, evaluating innovation, defining the scope of services and tools, and advising customers and delivery teams. Apart from numerous industry reports, such as the Continuous Testing Reports, the 2020 state of Performance Engineering, Antoine co-authored the "Mobile Analytics Playbook," which aims to assist practitioners in improving the quality, velocity, and efficiency of their mobile applications through the integration of analytics and testing.

About Sogeti & Capgemini

Part of the Capgemini Group, Sogeti operates in more than 100 locations globally. Working closely with clients and partners to take full advantage of the opportunities of technology, Sogeti combines agility and speed of implementation to tailor innovative future-focused solutions in Digital Assurance and Testing, Cloud and Cybersecurity, all fueled by AI and automation. With its hands-on ‘value in the making’ approach and passion for technology, Sogeti helps organizations implement their digital journeys at speed.

Visit us at www.sogeti.com

Capgemini is a global leader in partnering with companies to transform and manage their business by harnessing the power of technology. The Group is guided everyday by its purpose of unleashing human energy through technology for an inclusive and sustainable future. It is a responsible and diverse organization of 270,000 team members in nearly 50 countries. With its strong 50 year heritage and deep industry expertise, Capgemini is trusted by its clients to address the entire breadth of their business needs, from strategy and design to operations, fueled by the fast evolving and innovative world of cloud, data, AI, connectivity, software, digital engineering and platforms. The Group reported in 2020 global revenues of €16 billion.
Get the Future You Want | www.capgemini.com