Nous échangeons beaucoup avec nos clients. Que cela concerne l’utilisation de notre plateforme, les problèmes auxquelles ils font face ou et les solutions réalisables.
Suite à ces nombreux échanges, une chose nous apparaît clairement : améliorer l’efficacité des activités de test est un enjeu majeur pour la plupart d’entre eux.
Autre point commun : dans cette recherche d’efficacité, ils sont le plus souvent freinés par des problèmes similaires et récurrents.
Nous avons choisi de partager avec vous ces problématiques qui empoisonnent de nombreuses équipes de test, avant d’aborder les solutions mises en place par nos clients.
Pourquoi les équipes de test ont besoin de plus d’efficacité ?
Les 3 problèmes majeurs et récurrents
A la suite des échanges que nous avons avec nos clients, 95% d’entre eux nous confient qu’ils rencontrent 3 problèmes principaux :
- La complexité croissante des applications informatique : finies les applications monolithiques et autonomes, bonjour les intégrations inter-applications sans fin (à travers les web-services par exemple). Ces intégrations augmentent le risque lié à chaque évolution et complexifient les tests à réaliser. Mieux tester est indispensable car malgré les risques en augmentation, les délais et ressources attribués au test n’évoluent pas.
- L’accélération du rythme des versions : les évolutions dans les applications sont indispensables pour les équipes métier. Bien que chaque version contienne moins d’évolutions, les tests n’en sont pas plus simples. Et puisqu’il est impensable de tout re-tester à chaque fois, des stratégies de test mieux adaptées sont indispensables.
- Les modifications incessantes à tous les niveaux : de nouvelles fonctionnalités sont ajoutées aux applications, de nouvelles applications sont ajoutées au SI… en bref, de très nombreux risques sont ajoutés. Et si les exigences de qualité ne faiblissent pas, les moyens ne sont jamais en hausse non plus…
Il y a 2 semaines, l’un de nos clients nous parlait justement de son expérience plutôt désagréable :
« A chaque mise en production, le retour est très rapide. On atteint rapidement une centaine d’utilisateurs, et avec l’usage qu’ils font de l’application, si un bug traine, ils le trouvent vite ; et s’il est bloquant, on a un retour rapide et « violent ». Couvrir ce risque est une priorité, et nous devons impérativement augmenter l’efficacité de nos activités de test.»
Les sources d’inefficacité identifiées
Au-delà du besoin d’efficacité grandissant, nos clients partagent trois sources importantes de perte d’efficacité dans les tests :
- Une mauvaise visibilité sur le contenu des versions livrées
- Des modifications de mauvaise qualité
- Un nombre d’itérations élevé pour valider une nouvelle version
Les 3 boulets auxquels sont enchainés les testeurs
Pas de bon test sans bonne visibilité
Dans la majorité des cas, les équipes de test se plaignent de n’avoir aucune visibilité sur les développements réalisés par les équipes projet. Les impacts ne sont donc pas clairement identifiés et il est impossible d’orienter la stratégie de test vers ces risques (ou alors avec une confiance limitée).
Cette mauvaise visibilité est due à plusieurs situations :
- Les équipes de test et de développement fonctionnent en mode « silo ». C’est surtout le cas lorsque les développements sont externalisés chez un sous-traitant, mais pas seulement.
- Développeurs et testeurs travaillent dans le même open-space, mais ils ne parlent pas la même langue ! Lorsque les développeurs parlent fichier, classe ou code, les testeurs veulent entendre cas de test, besoin métier et scénario fonctionnel.
Les premières tentatives d’amélioration sont les release notes. Mais là encore, le contenu est trop technique pour être exploité par les testeurs, ou parfois trop général (listant les exigences associées à la livraison) ou simplement déclaratif et jugé pas suffisamment fiable.
Par conséquence, le responsable de la validation fonctionnelle ne dispose pas d’une vision assez précise des modifications et de leurs impacts pour sélectionner les scénarios les plus pertinents pour couvrir les risques.
Pour mieux comprendre les conséquences de ce manque de visibilité, voici l’exemple d’une situation vécue par l’un de nos clients :
4 jours avant la fin de validation - une dernière version de l’application est livrée, elle contient 10 correctifs à valider et il faut s’assurer qu’ils n’ont pas généré de régressions.
J-4 - évaluation du périmètre des modifications.
- Est-ce qu’il n’y a bien que les 10 les corrections prévues dans la livraison ? Pas certain à 100%…
- Quels sont les impacts de ces corrections sur le reste des fonctionnalités ? On ne connaît déjà pas exactement les modifications ! Alors les impacts…
- Quels sont les risques ? Impossible d’évaluer précisément ; on décide de valider d’abord les corrections, puis on passera les tests de régressions prioritaires habituels.
J-2 – des régressions apparaissent sur des éléments censés ne pas avoir été modifiés
- Une livraison d’urgence d’une nouvelle version avec les nouveaux correctifs est nécessaire !
- On valide en urgence ces correctifs mais sans pouvoir pousser plus loin les tests de non-régressions.
Ok on passe en production, mais - premiers retours utilisateurs : des bugs et des mécontents. D’où viennent les bugs ? Bonne question…
Non seulement ce genre de situation génère des bugs qui ne seront décelés qu’une fois l’application mise en production, mais en plus, en trouver l’origine s’avère particulièrement délicat.
Mauvaise qualité des développements : une entrave pour les testeurs
La mauvaise qualité des développements à un impact fort sur les équipes de test fonctionnel. Bien que le lien ne soit pas toujours évident, on retrouve souvent ce type de situation :
- Des régressions fréquentes à chaque livraison car le code est difficilement maintenable et peu évolutif : chaque changement est périlleux. Un cas détecté chez plusieurs clients : le copié-collé dans le code. Cela se traduit lors des tests par le besoin de plusieurs itérations pour corriger un même bug de partout !
- Des anomalies techniques détectées par les testeurs fonctionnels mais difficiles à reproduire, à documenter et donc à faire corriger. Ces anomalies sont généralement classées « non reproduites » mais refont surface en production.
- Une équipe de développement qui préfère livrer l’application à la date prévue quitte à ne pas réaliser tous les tests techniques nécessaires (ou avec quelques développements à finir). En résultent des changements inclus dans la livraison suivante (retour au point manque de visibilité !) et des résultats de test douteux. Une source de régression très commune !
Le manque de qualité n’est pas uniquement perceptible en production. Avec des tests du type boite noire, il est très difficile de faire le lien entre certains problèmes et leur origine. Pourtant, si on peut ouvrir la boite, ce lien saute aux yeux !
Nombre de livraisons : une indicateur clé de performance ?
A chaque livraison supplémentaire dans une même phase de validation est associé un risque ; généralement mal maîtrisé. Chaque changement peut remettre en cause le résultat d’un test déjà exécuté sans même que ce risque ne soit perçu.
De nombreuses études, à l’instar de celles d’IBM et Caper Jones, montrent que l’impact de cette situation est énorme :
« 5 à 8% des anomalies détectées en production sont issues de modifications réalisées durant les phases de test »
IBM & Caper Jones
Afin d’éviter cette situation, des entreprises choisissent de retarder les campagnes de test de non-régression. Mais trop les retarder est impossible, et le problème les rattrape toujours.
De ce fait, la perception des tests est dégradée : ils paraissent inefficaces alors que l’équipe met tout en œuvre pour éviter ces problèmes. Elle adapte ses plans de test à chaque livraison et augmente ses efforts à l’approche de la deadline.
Améliorer l’efficacité de test : une voie sans issue ?
Il existe des solutions qui permettent aux équipes de test de contrer et d’anticiper ces problèmes qui minent leur efficacité. Nous analyserons les solutions mises en œuvre par nos clients dans une série d’articles à venir. Nous vous montrerons :
- Comment avoir une bonne visibilité sur les versions reçues
- Comment exploiter la couverture de test pour maîtriser et anticiper les risques
- Comment définir une stratégie de test de non-régression plus efficace
En attendant, si vous ou votre entreprise faites face à des problèmes que nous n’avons pas évoqués, exposez-les en réaction à cet article !
