Comment optimiser vos campagnes de tests (part 2)

– 30% des tests réalisés sont inefficients,
– 30% des tests couvrent 65% des risques de régression,
– 30% des tests sont redondants.

Comment améliorer la qualité et la pertinence des campagnes de tests tout en diminuant l’effort de test?

La solution « test coverage intelligence » répond notamment à cette problématique.

Ce produit très innovant est édité par la société Kalistick. Personnellement, j’ai découvert les produits de cette société, il y a quelques années, au détour de la lecture d’un article sur le blog du « touilleur express » http://www.touilleur-express.fr/2009/04/21/kalistick-propose-une-solution-danalyse-de-la-qualite-du-code-en-mode-saas/. A l’époque, le produit commercialisé couvrait le domaine de la qualimétrie des logiciels. Bien qu’il ait toujours une valeur ajoutée importante, le produit leader au catalogue de la société Kalistick, est désormais la solution de couverture des tests « Test coverage intelligence ».

Je me suis donc intéressé à ce produit dont le retour sur investissement peut être obtenu très rapidement dès le premier mois d’utilisation.

En synthèse « test coverage intelligence » permet d’évaluer la couverture de test de vos applications, d’identifier les risques de régression, et d’optimiser vos campagnes de tests en appliquant des stratégies de test qui vous permettent de minimiser le nombre de tests tout en maximisant leurs couvertures.

Un peu de technique pour comprendre le fonctionnement de cette solution.

Le produit est commercialisé en mode SaaS (Software as a Service). Seule une partie du produit doit être installée sur la plate-forme du client. Outre la simplicité de déploiement et de configuration, ce mode de fonctionnement permet aux clients de bénéficier en continu des améliorations apportées au produit, et de disposer d’une solution très disponible.

Éludons dès maintenant la problématique de sécurité.
Le moteur d’analyse fonctionne sur une infrastructure AWS. Il y a donc des informations qui transitent depuis l’infrastructure du client vers l’infrastructure Kalistick. Mais rassurez vous, votre code applicatif n’est pas communiqué vers l’extérieur, et vous pouvez le vérifier si vous avez un doute en visualisant dans un éditeur le contenu des fichiers générés par les outils de la solution. Les seules informations qui transitent sont composées de nom de classes et de méthodes, des graphes d’appel de méthodes, et des numéros de ligne de code. Le tableau de bord du moteur d’analyse (appelé le cockpit) est accessible via une connexion sécurisée (https), avec une identification du type identifiant/mot de passe.

Le support de l’éditeur est très efficace et la documentation parait suffisante.
L’éditeur propose dans son catalogue trois tarifs correspondants à un usage particulier. La tarification est basée sur le nombre d’applications supervisées et le nombre d’agents logiciels à déployer (nous reviendrons plus loin sur cette notion). Il est également possible d’interfacer le produit avec des référentiels de tests (par exemple HP QC ou Refertest).

Pour en terminer avec la technique voici comment fonctionne la solution.
Elle est composée de plusieurs modules. Nous avons déjà parlé du module Cockpit qui contient le moteur d’analyse et le tableau de bord permettant de piloter les tests. Ce module est déployé à l’extérieur de l’infrastructure du client. Plusieurs composants peuvent être utilisés sur l’infrastructure du client: un agent chargé de collecter les informations concernant les tests, un module de « scan » qui est utilisé à chaque nouvelle version pour capturer une empreinte de l’application, un module « contrôleur » servant de liaison entre l’infrastructure du client et celle de Kalistick. Ce dernier permet entre autre fonction de contrôler la configuration de l’agent, de télécharger les différentes empreintes capturées sur l’application et de gérer les tests.

Le processus de fonctionnement est globalement le suivant: les livrables de l’application sont scannés par un module déployé localement. Ces informations sont transmises au module externe appelé le Cockpit. Il s’agit en quelque sorte de l’empreinte digitale de l’application. On lie cette empreinte à une version cible qui représente une version stable de l’application (par exemple une version à livrer à un client). Lorsque cette version est testée, l’agent se charge de capturer l’empreinte du test, en d’autres termes tous les appels de méthodes et éventuellement les lignes de code exécutées par le test sont mémorisés. Ces empreintes sont chargées sur le moteur d’analyse (cockpit), corrélées, et là, la magie commence agir.

Vous disposez sur le tableau de bord d’indicateurs vous permettant d’avoir une analyse immédiate et synthétique de la couverture des tests sur l’application, sur les modifications, ou chaque module fonctionnel. Cette analyse distingue les tests fonctionnels et les tests techniques (par exemple les tests unitaires). En un seul coup d’œil vous pouvez évaluer la couverture des risques par les tests.

La solution vous propose également d’analyser ces métriques selon une perspective fonctionnelle (pour que cette fonction soit disponible il faut noter qu’il y a un petit effort de modélisation à réaliser au préalable). A ce stade vous pouvez également obtenir une vision de la couverture des tests par module et par niveau de criticité. Imaginez que vous ayez modifié le code du composant de sécurité. Il est important que vous soyez rassuré sur la couverture de test de ce module et tous ceux ayant le même niveau de criticité. Le tableau de bord vous présente graphiquement cette perspective et vous permet de piloter vos tests en fonction des risques liés aux changements non testés.

Cerise sur le gateau, le produit propose de vous aider à définir votre stratégie de test pour couvrir  efficacement les modifications apportées à l’application et limiter l’effort de test.

Vous pouvez opter soit pour une des stratégies pré configurées par l’éditeur ou définir vous même le périmètre de la campagne de tests en fonction  de la pertinence des tests (Kalistick calcule un scoring des tests pour vous aider à planifier les tests à exécuter).

Avec les stratégies pré configurées vous pouvez limiter le périmètre des campagnes de tests aux modifications apportées sur la dernière version de l’application ou élargir les tests aux modifications apportées depuis la dernière livraison. Vous pouvez également faire porter votre effort uniquement sur les « trous de test » c’est à dire les modifications non testées pour lesquelles il existe un cas de test.
Pour chacune de ces stratégies vous pouvez également choisir, en fonction du temps que vous voulez allouer à cette campagne de tests, une validation accélérée qui vous proposera d’exécuter un minimum de tests pour couvrir le maximum de modifications ou choisir une validation sécurisée qui proposera de jouer tous les tests pour couvrir le maximum de modifications.

Par exemple, vous avez porté un effort de test conséquent sur différentes versions intermédiaires et vous souhaitez sécuriser la dernière version contenant des modifications codées en urgence, vous avez également peu de temps pour tester cette nouvelle version tout en souhaitant obtenir un livrable de très bonne facture et limiter les risques de régression introduits par cette version de dernière minute. Dans ce cas, vous choisissez la stratégie « non régression sur la dernière version reçue » et une validation accélérée… et le produit vous propose les cas de tests qui correspondent à cette stratégie.

Je vous laisse imaginer le temps que vous pouvez gagner avec un référentiel de tests de plusieurs dizaines ou centaines de cas de tests, ou sur des projets agiles avec des livraisons fréquentes.

La deuxième stratégie est basée sur l’évaluation pondérée des tests (« scoring »). La pondération est calculée selon trois facteurs :

  • la taille de l’empreinte de test : Plus le test appelle des méthodes différentes plus il est considéré pertinent ;
  • le nombre de modifications testées si le test est exécuté ;
  • le nombre de modifications non couvertes par les autres tests : En effet, plusieurs tests peuvent couvrir les mêmes modifications ou parcourir des chaînes de liaison communes. Dés lors qu’un test est execute, la pertinence des autres tests qui partagent une couverture du code diminue ;

Quelles sont les objectifs poursuivis par ces types de stratégie de test :

  • diminuer les risques de regression en executant les tests qui mettent en jeu le plus grand nombre de modifications;
  • optimizer les campagnes de tests en priorisant les cas de test extraits des exigences pour éviter d’exécuter des tests non pertinents ;
  • améliorer la pertinence des tests en executant des tests qui mettent en jeu des modifications qui n’ont pas été couvertes par les autres tests ;

Le produit fournit également un explorateur de couverture qui permet d’évaluer les risques liés aux « trous de test » (partie de l’application qui n’est pas testée). Cette fonctionnalité permet par exemple de concentrer l’analyse des risques sur des modules fonctionnels particuliers ou sur les modules les plus critiques.

Le dernier outil proposé par la solution est un simulateur d’impact. Vous souhaitez par exemple connaître l’impact de la modification de certaines parties de l’application sur les tests, ou connaître les modules impactés par la modification, ou encore identifier les trous de tests correspondant à votre  modification. Par exemple, vous souhaitez intégrer une modification sur des règles de calcul liées à la réservation de séjours de vacances, le simulateur d’impact peut vous aider à identifier les scénarios de test que vous devrez exécuter pour qualifier ce changement.
Cet outil peut donc vous apporter une aide à la planification de votre activité de qualification.

Des fonctions d’administration vous permettent de gérer les utilisateurs et leurs rôles, de gérer le chargement des empreintes, les versions cibles, etc.

Quelles sont les bénéfices mesurables apportés par cette solution :

Tout d’abord la pertinence des scénarios de tests exécutés apporte un gain de temps et de ressources dans les phases de tests.

Ensuite, l’élimination des anomalies par l’exécution de tests ciblés permet d’obtenir un gain sur la qualité et la fiabilité des livrables. Par effet de bord, moins de bugs sont détectés lors des étapes suivantes ce qui représente une source d’économie importante lorsqu’on sait que plus une anomalie est décelée tard dans le processus de validation, plus le coût lié à la correction de cette anomalie est important. Je suis certain que vous avez tous une expérience intéressante sur ce sujet.

Enfin le planning est mieux maîtrisé car les phases de qualification sont plus efficaces.

Pour finir, si vous souhaitez faire une évaluation du produit, nous vous conseillons de demander une web demo à l’éditeur sales@kalistick.fr pour vous familiariser avec les concepts et les indicateurs puis de mettre en oeuvre un POC (une version gratuite est disponible pendant 1 mois). En effet, pour évaluer efficacement le produit il est nécessaire en amont de preparer un peu cette evaluation en identifiant un environnement de test, 2 versions de l’application à tester, éventuellement des ressources pour tester l’application et un referentiel de tests.

Ci dessous le lien vers la presentation du produit Test Coverage Intelligence.
http://bit.ly/14YwPiW

http://www.jperf.com

https://jperf.wordpress.com/2013/03/15/comment-optimiser-vos-campagnes-de-tests/

Publicités

A propos jlerbsc

founder of JavaPerf Consulting Http://www.jperf.com
Cet article a été publié dans Qualité. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s