Le développement d’applications représente encore une partie importante des missions des DSI. Avec l’accélération des cycles de développement, la qualité applicative risque d’en pâtir, à moins de mettre en place des processus de tests robustes et industrialisés.
Il faut commencer par évaluer l’état actuel de ces processus pour identifier les actions à mener en priorité. Le numérique, devenu omniprésent, irrigue tous les secteurs d’activités et tous les pans de la société. Dans ce contexte, la qualité des applications n’est pas un luxe, mais le facteur différenciant qui permet de devancer vos concurrents, notamment dans l’expérience client. Les tests sont depuis toujours l’un des piliers de cette qualité. Il n’est pas question de les négliger, à l’heure où le système d’information s’ouvre de plus en plus à l’extérieur, que ce soit à travers des applications mobiles, des réseaux d’objets connectés, des plateformes partenaires ou des comparateurs de prix : le moindre bug peut mettre en péril les ventes, la relation client ou les processus métier de l’entreprise.
Dans le même temps, la pression pour livrer toujours plus vite et à moindre coût s’accentue sur les équipes projet. Celles-ci ne peuvent plus se satisfaire de tests menés de manière artisanale, au risque de sacrifier la qualité. Il est donc vital d’industrialiser les tests : intégrés de manière fluide aux projets de développement applicatif, ceux-ci pourront alors être pratiqués en continu, comme le préconisent des approches de type DevOps, et ils ne seront plus perçus comme une variable d’ajustement dans les plannings.
I – Autodiagnostic et points d’attention
| Grille d’autodiagnostic : les tests applicatifs | |||
| Questions à se poser | Oui | Non | Principal risque |
| Rencontrez-vous souvent des problèmes de qualité sur vos applications développées en interne ? | B | A | Si ce cas de figure se produit de manière récurrente, l’image de la DSI peut en pâtir et l’entreprise être tentée d’externaliser ses développements |
| Vous est-il arrivé de détecter des bugs majeurs après la mise en production d’une application ? | B | A | Plus un bug est détecté tardivement, plus il est complexe et coûteux de le corriger |
| Avez-vous formé vos équipes, notamment vos développeurs, aux méthodes de tests et à la qualité applicative ? | A | B | Une équipe qui n’est pas sensibilisée à la qualité applicative peut percevoir les tests comme une étape fastidieuse et non indispensable |
| Avez-vous mis en place un processus pour vérifier la qualité des applications développées par vos prestataires ? | A | B | Si l’entreprise choisit d’externaliser certains développements, ne pas mesurer la qualité de ce qui est livré l’expose à de nombreux risques (maintenabilité qui se dégrade, correctifs tardifs et coûteux…) |
| Avez-vous mis en place des indicateurs mesurant la qualité de vos applications au fil du temps ? | A | B | Sans indicateurs, la qualité des applications peut se dégrader à votre insu, jusqu’à atteindre un stade critique |
| Evaluez-vous le coût de la non-qualité de vos applications (temps d’indisponibilité, ressources consommées en résolution de bugs, perte de CA…) ? | A | B | L’impact de la non-qualité est rarement mesuré, pourtant c’est un bon moyen de valoriser les tests et de justifier d’éventuels investissements dans ce domaine |
| Avez-vous établi des objectifs pour les résultats de vos tests (taux de défauts accepté par niveau de gravité, seuils de performances souhaités, taux de couverture fonctionnelle accepté…) ? | A | B | Faute d’objectifs pour les tests, l’entreprise ne pourra pas mesurer leur utilité et leur pertinence. Ils risquent d’être dévalorisés et négligés |
| Avez-vous tendance à effectuer la plupart de vos tests en fin de projet, lors de la phase de recette ? | B | A | Plusieurs tests peuvent être menés tôt dans le projet, même sans avoir l’ensemble des composants : attendre de disposer de tout rend les tests plus longs et complexes à mettre en place |
| Vérifiez-vous que vos scénarios de tests sont utilisés et/ou pertinents (à travers des indicateurs comme le nombre d’exécutions par scénario et le nombre de défauts identifiés) ? | A | B | Si un scénario n’est pas utilisé, il faut se demander pourquoi. Il ne sert à rien de garder des scénarios de tests obsolètes ou mal conçus : s’ils ne mettent jamais d’anomalies en évidence, sont-ils utiles en l’état ? En revanche, s’ils ne sont pas utilisés pour d’autres raisons (trop long à exécuter par exemple), il faut identifier le problème et tenter de le résoudre |
| Hormis la phase de recette, prévoyez-vous explicitement du temps pour les tests dans vos plannings ? | A | B | Ne pas faire apparaître les tests dans les plannings a tendance à les faire considérer comme des étapes optionnelles, qui peuvent être sacrifiées en cas de retard |
| Avez-vous déjà omis d’effectuer des tests prévus pour cause de retard de livraison ? | B | A | Faire des tests une variable d’ajustement, c’est exposer l’entreprise aux risques associés à la non qualité |
| Vos équipes disposent-elles d’outils adéquats pour mener les tests ? | Des outils de test trop vieux, ou absents, ne sont plus en mesure de répondre aux enjeux de l’économie numérique | ||
| – unitaires | A | B | |
| – d’intégration | A | B | |
| – fonctionnels et de non-régression | A | B | |
| – de charge et de performance | A | B | |
| Testez-vous la sécurité de vos applications ? | A | B | La sécurité est souvent le parent pauvre des tests. Voulez-vous vraiment prendre le risque d’exposer les données de vos clients ou de perturber le fonctionnement de vos activités ? |
| Disposez-vous d’outils de tests adaptés pour chaque type d’application que vous développez (applications mobiles, Web, e-commerce, IoT, API…) ? | A | B | Chaque type d’application a ses spécificités : diversité des terminaux pour les applications mobiles, pics de charge pour l’e-commerce, architectures et contraintes spécifiques pour l’IoT… Tester avec des outils mal adaptés peut faire passer à côté de défauts qui auraient pu facilement être évités |
| Pouvez-vous, si nécessaire, accéder facilement à des ressources supplémentaires (cloud interne ou externe) pour exécuter vos tests, notamment les tests de charge ? | A | B | Certains types de tests, notamment de performance, peuvent nécessiter des ressources plus importantes que celles allouées par défaut à l’environnement de test |
| Avez-vous automatisé tout ce qui peut l’être dans vos processus de tests ? | A | B | L’exécution manuelle des tests est fastidieuse, chronophage et ne convient qu’à de petits projets ponctuels, avec très peu de livraisons |
| Avez-vous mis en place un processus et des outils pour remonter aux développeurs les problèmes observés lors des tests ? | A | B | Tous les tests ne sont pas forcément menés par l’équipe de développement. En cas d’anomalie, il faut donc pouvoir la remonter rapidement à celle-ci, avec les informations nécessaires à sa correction (ce que permettent notamment les environnements de qualification intégrés) |
| Disposez-vous de jeux de données adaptés pour vos tests ou pouvez-vous facilement les générer ? | A | B | La constitution des jeux de données est un écueil fréquent des projets de tests, qu’il est préférable d’anticiper |
| Pouvez-vous rendre ces données anonymes si nécessaire ? | A | B | Dans le cas où les jeux de données utilisés reprennent des données réelles issues de la production, il faut veiller à ce que les données sensibles (données personnelles, RH…) soient anonymisées |
| Vos environnements de test sont-ils alignés sur vos environnements de production ? | A | B | Si les changements des environnements de production ne sont pas systématiquement répercutés sur les environnements de tests, il peut se produire un décalage qui fausse les résultats |
| Ecrivez-vous vos tests unitaires avant d’entamer le développement d’une fonctionnalité ? | A | B | Cette pratique issue des méthodes agiles réduit le risque de se retrouver avec du code compréhensible seulement de son auteur, impossible à tester et à maintenir |
| Avez-vous défini des scénarios de tests re-jouables pour vos applications stratégiques ? | A | B | Plus une application est stratégique, plus il est important de pouvoir la tester facilement à chaque livraison |
| Ces scénarios sont-ils basés sur des cas d’usages concrets, courants et réalistes ? | A | B | Pour être pertinents, les scénarios de tests doivent se baser sur de vrais cas d’usage, déterminés par les utilisateurs plutôt que sur les suppositions des développeurs |
| Révisez-vous régulièrement ces scénarios pour les mettre à jour/les adapter ? | A | B | Si l’application évolue mais pas les scénarios de tests, ceux-ci peuvent devenir obsolètes |
| Après chaque livraison majeure, ajoutez-vous les tests des nouvelles fonctionnalités à vos tests de non-régression ? | A | B | Les tests de nouvelles fonctionnalités d’aujourd’hui sont les tests de non régression de demain. Oublier ce principe, c’est s’exposer à voir ses tests de non-régression devenir obsolètes |
| Source : Best Practices – Digitalonomics | |||
II – Les préconisations
Par rapport aux vingt-cinq questions listées dans la grille d’autodiagnostic, l’évaluation de la maturité peut s’effectuer avec l’échelle suivante :
- Moins de cinq réponses « B » : la situation est maîtrisée.
- De 6 à 10 réponses « B » : la situation est inégale.
- De 11 à 15 réponses « B » : la situation est dans une zone de risques.
- De 16 à 20 réponses « B » : la situation est dans une zone de danger.
- Plus de 20 réponses « B » : la situation est critique.
Lorsque la situation est maîtrisée : restez vigilants !
La pression sur la qualité ne va pas décroître avec le temps, bien au contraire ! Si ce n’est pas déjà le cas, intéressez-vous aux approches de type DevOps, méthodes agiles, développement par fonctionnalités (feature-driven development). Celles-ci peuvent vous apporter de nouvelles idées de pratiques à expérimenter, afin de fluidifier encore davantage vos processus de tests.
Des start-up peuvent également vous aider en proposant des approches innovantes et complémentaires de ce que vous avez déjà mis en place : StarDust et sa plateforme de crowdtesting, Kameleoon ou AB Tasty et leurs solutions pour l’A/B testing et la personnalisation des interfaces clients, Yogosha pour détecter des failles de sécurité…
Lorsque la situation est inégale : les fondamentaux sont maîtrisés, mais il subsiste des zones d’amélioration
Vous êtes conscient des enjeux en matière de qualité applicative, mais sur certains aspects vous êtes restés sur une approche artisanale des tests, qui peut vous freiner pour la mise en place d’un processus de qualification continue.
Un audit de maturité des tests peut vous aider à identifier de manière plus précise les points qui posent problème. Il convient également de partager les bonnes pratiques qui ont fait leurs preuves sur certains projets, afin de les diffuser de manière plus large.
Lorsque la situation est dans une zone à risques : vous avez quelques zones de défaillance
Vos processus de tests ne sont pas fluides, ils se heurtent à des facteurs bloquants ou rencontrent des goulets d’étranglement. Un rapide passage en revue de vos réponses peut vous orienter vers les facteurs à l’origine de ces difficultés :
- Si vous avez beaucoup de « B » sur les questions 4 à 11, vous avez sans doute des défaillances au niveau du pilotage et de la planification des tests. Un accompagnement par un consultant spécialisé dans ce domaine peut vous aider à mettre en place les bons indicateurs et à mieux définir vos plannings.
- Si vous avez beaucoup de « B » sur les questions 12 à 20, vos outils et vos environnements de tests actuels sont probablement insuffisants. Songez à les moderniser ou à les compléter
- Si vous avez beaucoup de « B » sur les questions 21 à 25, peut-être devez-vous remettre en question certaines de vos pratiques actuelles, pour vous orienter vers des approches plus agiles.
Un accompagnement peut ensuite vous aider à mettre en œuvre un plan d’actions pour rectifier le tir.
Lorsque la situation est dans une zone de danger : valorisez les tests pour leur redonner de l’attractivité
Peut-être en êtes-vous déjà arrivés au point où les tests sont considérés comme un pensum, voir comme une punition, peut-être n’en êtes-vous pas loin. Pendant ce temps, l’insatisfaction des utilisateurs s’aggrave…
Il est urgent de valoriser les tests, en commençant par mettre en place quelques indicateurs chocs sur la non-qualité et en sensibilisant vos équipes. Dans un deuxième temps, investissez afin de disposer d’outils plus adaptés, puis démontrez la valeur des tests sur un projet stratégique.
Lorsque la situation est critique : rebâtissez les fondations
Vous avez probablement répondu « B » aux questions 1 à 3, ce qui dénote un problème global sur la qualité applicative. Testez-vous au petit bonheur la chance, seulement quand vos équipes ont deux heures à tuer entre deux tâches urgentes, ou bien en mode pompier, quand une mise en production provoque un dysfonctionnement majeur ?
Les causes de cet abandon des tests peuvent être multiples :
- Une absence de dialogue (ou pire, un conflit) entre les équipes de développements, les testeurs et les équipes de production.
- Des outils obsolètes.
- Un manque de formation.
- Un processus de test excessivement lourd.
- Ou, au contraire, l’absence d’un processus de test formalisé.
Face à ce type de situation, il faut repartir sur de bonnes bases. Commencez par former vos équipes, en vous adressant par exemple au CFTL (Comité Français des Tests Logiciels) qui propose des certifications. Ensuite, outillez-vous, même modestement pour démarrer. De nombreux outils Open Source sont disponibles pour les tests et l’intégration continue. Ils sont souvent mieux adaptés aux applications et aux pratiques actuelles que des environnements conçus à l’époque où les cycles en V étaient la norme. Enfin, une fois votre processus de tests établi, éprouvez-le sur un nouveau projet stratégique de par sa cible ou ses objectifs (s’il peut être tentant de le tester d’abord sur un petit projet sans importance, cela ne permettra pas de montrer la valeur et le rôle des tests).
| Maturité des processus de tests : principales préconisations selon l’existant | ||
| Degré de maturité | Principal indice révélateur de la situation | Principale préconisation |
| Situation maîtrisée | Bon niveau de qualité applicative globale | Veillez à maintenir ce niveau dans le temps, voire poussez-le un cran plus loin en innovant. |
| Situation inégale | Niveaux de qualité différents selon les applications et les projets | Faites un audit de maturité des tests pour mieux cerner les points qui posent problème. |
| Situation à risques | Points bloquants ou goulets d’étranglement dans les processus de tests | Identifiez les zones de défaillance, puis définissez un plan d’action |
| Zone de danger | Désintérêt de vos équipes pour les tests | Valorisez les tests |
| Situation critique | Mauvaise qualité applicative globale | Reconstruisez les bases |
| Source : Best Practices Systèmes d’Information. | ||