Des simples métriques à l'analytique intelligente

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.  

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.

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: 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 :

Figure: Autres exemples d'analyse intelligente  

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.

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).

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.

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.

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.