Automatisation des tests : qu'en est-il du ROI ?

Pourquoi ? Notamment parce que les attentes de la direction sont fréquemment guidées par les médias, le matraquage des vendeurs ainsi que des conférences et des ouvrages vantant les mérites de l’automatisation des tests. Certaines de ces informations ont beau être plutôt justes et réalistes, la plupart minimisent toutefois les conditions et les considérations spécifiques au projet en question, mettant volontairement l’accent sur les réussites. Or, ne pas prendre en compte le contexte de chaque projet et définir des attentes sans mener les réflexions nécessaires se traduira pourtant par un échec. Et ce, malgré un effort louable en termes d’automatisation.

Le présent article a pour but de vous aider à mieux faire valoir les avantages de l’automatisation. Étant donné que chaque contexte propice à l’automatisation est différent, il n’existe pas de règles générales infaillibles et valables pour tous les projets. Les idées et exemples recensés ci-après sont donc génériques et peuvent servir de base pour le calcul du ROI dans votre contexte spécifique.

Comment calculer le ROI ?

Investissement

L’investissement inclut l’ensemble du matériel et des ressources humaines nécessaire pour mettre en place une solution opérationnelle entièrement intégrée au cycle de vie du projet, à savoir :

• Architecture et concept d’automatisation
• Rédaction des scripts des scénarios de tests
• Environnement, préparation des données
• Entretien des scripts
• Qualification des tests (contrôle de la reproductibilité des bugs, de la survenue de bugs, suivi…)
• Formation des ressources
• Licences
• Serveurs / VM éventuellement requis pour procéder aux tests

Retour

Le ROI ne correspond pas au rapport entre la valeur de l’automatisation et les coûts de réalisation de ces tests, s’ils avaient été faits manuellement. Il inclut également la valeur ajoutée de ce type de tests, ainsi que le bénéfice imputable au temps gagné par la personne qui aurait effectué les tests manuellement.
À présent, intéressons-nous plus précisément aux différents avantages de la mise en œuvre de cette solution.

Résultats tangibles

• Réduction des coûts de réalisation de tests automatiques, pour un même champ d’application
• Réduction du temps nécessaire à la réalisation des tests
• Possibilité de procéder aux tests 24/24 (coûts de tests manuels – coûts de tests automatisés) pour le même champ d’application
• Réduction des coûts de prise en charge des bugs identifiés plus tôt

La réduction des coûts pour un champ d’application donné peut être calculée au moyen de la formule suivante :
ROI = (coûts des tests manuels – coûts des tests automatisés) / coûts des tests automatisés

Résultats intangibles

• Réduction du cycle de tests et l’évaluation rapide de la qualité de l’application
• Disponibilité des personnes habituellement chargées des tests manuels, pertinence accrue des tests, absence de démotivation entraînée par la réalisation de tâches répétitives
• Minimisation des erreurs humaines engendrées par l’exécution répétée de tâches identiques

Exemple de calcul du ROI obtenu grâce à l'automatisation des tests

Encore une fois, l’investissement initial dépend du contexte du projet. L’entreprise utilise-t-elle des solutions commerciales ou des outils open source ? Dispose-t-elle de ressources compétentes ou aura-t-elle besoin de dispenser des formations préalables ? Quelles sont les plateformes à prendre en compte ? Quelle en est l’étendue ?

Les coûts suivants constituent les postes principaux qu’il convient de budgéter dans tous les cas :

• Coûts de l’architecture de l’automatisation : que le projet opte pour un outil d’automatisation gratuit / open source ou pour une solution commerciale, mettre en place l’architecture nécessaire au développement des scénarios de tests nécessite un effort initial. Cette architecture est constituée d’outils, de bibliothèques, de modules réutilisables et de fonctions prêtes à l’emploi, qui favorisent l’activité d’automatisation et aident vos développeurs à travailler plus efficacement à l’élaboration des scripts. Bien entendu, dans certains cas spéciaux, une personnalisation ou une évolution pourra s’avérer nécessaire. Elle devra alors faire l’objet d’une étude séparée.
  Les projets développés par SQLI font le plus souvent appel à la solution TestReg, maîtrisée par ses ressources. Le client peut toutefois exiger le recours à un autre outil / une autre architecture de son choix. Nous recommandons fréquemment TestReg et ses options car c’est une solution qui intègre les meilleures pratiques dans le domaine de l’automatisation des tests. L’architecture TestReg peut être utilisée dans le cadre d’une approche de test classique ou BDD. Elle prend en charge l’automatisation web, mobile ou API et peut également être intégrée à une infrastructure de test existante ou à un service de test à distance via le Cloud (saucLab, perfecto …). Cette architecture est utilisée dans les projets d’automatisation de SQLI sans surcoût. Seul le paramétrage de l’architecture en vue du projet fera l’objet d’un devis (en fonction du nombre de plateformes à tester).

• Développement de scénarios de tests : c’est le principal poste de coûts. Au cours de cette étape, le champ d’application défini par le QA est automatisé dans le cadre de directives et de l’architecture, en fonction encore une fois de l’ampleur de l’automatisation. (Veuillez noter que la tâche / l’effort visant à identifier ce qui doit être automatisé et ce qui doit rester manuel a déjà été effectuée / fourni. Par ailleurs, lors de cette étape, les scénarios de tests doivent être définis au moyen d’étapes / de données de tests détaillées qui contribuent à un résultat cohérent.)
• Veuillez noter que l’élaboration des scripts doit également prendre en compte les navigateurs requis (mobiles et PC). L’effort d’adaptation doit soit être calculé dans le cadre de l’estimation du développement des scénarios de tests, soit faire l’objet d’une tâche séparée.
• Rédaction de scénarios dans un langage donné : pour utiliser l’approche BDD, il faut que les scénarios aient déjà été écrits par des BA / testeurs en langage Gherkin. À défaut, il faudra prévoir un poste de coûts supplémentaire correspondant. Veuillez noter que les BA / testeurs doivent respecter les meilleures pratiques en termes de rédaction de scénarios Gherkin afin de favoriser les étapes Réutilisation et Champ d’application.
• Préparation des données de tests : pour obtenir l’environnement de données / la configuration attendu(e) pendant le déroulement des tests, et afin d’éviter la survenue de bugs dus à l’absence de données ou à des données imprévues, chaque test doit être déployé automatiquement dans l’environnement de données / la configuration nécessaire. Cette tâche de préparation doit également être prise en compte.
• Définition de l’infrastructure des tests : si le projet n’opte pas pour un cloud de test commercial, l’infrastructure de test doit être préparée sur place (Quels systèmes d’exploitation utiliser ? Dans quels navigateurs ? Quels outils mettre en place ?) et être prête pour effectuer chaque test. La tâche de préparation de l’infrastructure avec toutes les ressources matérielles supplémentaires requises (VM, serveurs) doit faire l’objet d’un devis.
• Maintenance et qualification : ce poste de coûts est souvent négligé dans le cadre de la planification de l’automatisation des tests. Pourtant, le fait est qu’à la fin de l’exécution des tests, une intervention humaine reste nécessaire pour traiter les tests défaillants. S’agit-il d’un réel bug qui doit être transmis à l’équipe dédiée en vue d’être corrigé ? Ou est-ce le résultat d’un comportement spécifique de l’application dans certaines circonstances ? Ce qui impliquerait de devoir mettre à jour les scénarios de tests de manière à prendre en compte ce comportement aussi. Ou est-ce que quelque chose a changé dans l’application, qui nécessiterait la maintenance correspondante du scénario de test ?

Pour deux modules d’une application web, nous décomptons en tout 77 régressions avec des scénarios de tests small / medium et E2E (end to end). L’investissement initial est calculé.

Comment calculer le gain tangible

• La réalisation manuelle du même panel de 77 tests, sur un navigateur, coûterait environ 3 JH ;
• Pour couvrir les 4 navigateurs, la facture s’élèverait donc à 12 JH.

En supposant que la campagne sera effectuée une fois par sprint (2 semaines), chaque test de sprint coûtera 12 JH.

ROI à la fin de la première année

Coûts de la même intervention effectuée manuellement = 25 x 12 JH = 300 JH -> 69 000 € (soit 230 €/jour)

Coûts de l’intervention avec la solution d’automatisation = coût initial + frais de maintenance sur un an

Coût initial total + 25 x 1,5 JH = 32 913 € + 8652 € = 41 515 € 

à À la fin de la première année, le ROI est estimé à :

(coûts des tests manuels – coûts des tests automatisés) / coûts des tests automatisés = (69 000 – 41 515) / 41 515 = 60 %

ROI à la fin de la deuxièe année

Coût des scénarios de tests manuels : 138 000 €

Coût des tests automatisés = coût initial + frais de maintenance sur 2 ans = 32 913 € + 17 250 € = 50 163 €

Le ROI monte à 175 %

Cela signifie que le ROI augmente avec la durée de vie du projet et aussi avec la fréquence des tests réalisés.

Le ROI peut facilement augmenter si :

• La solution d’automatisation respecte les règles de réutilisation des scénarios fonctionnels, et si de nouveaux scénarios de tests peuvent être ajoutés simplement en modifiant uniquement des paramètres ou des données de tests ;
• Un nouveau navigateur peut être ajouté.

Cela implique que nous pouvons étendre le champ d’application de l’automatisation des tests à moindres frais, alors que la même extension manuelle du champ d’application nécessiterait le même coût initial pour la prise en charge de nouveaux scénarios de tests / navigateurs.

En outre, un ensemble de scénarios de tests peut être intégré dans le pipeline de build du projet afin de procéder à un contrôle lors de chaque nouveau build / build de nuit, ce qui augmente la qualité ou assure un retour rapide sur la qualité du nouveau build à l’équipe dédiée, sans effort supplémentaire.

Cas où l'automatisation des tests n'est pas rentable

Nous l’avons expliqué : le ROI est directement proportionnel au nombre de tests effectués et à la possibilité de réutiliser le même scénario de test avec des efforts d’adaptation restreints pour couvrir une nouvelle plateforme ou un nouveau scénario. Ceci étant dit, il est vrai que le gain se révèle plus difficile à établir dans les situations suivantes :

• Modules mal couverts : dans l’exemple précédent, le ROI a augmenté au bout de la deuxième année dans l’hypothèse qu’aucun changement majeur n’a été apporté pendant ces deux ans. En cas de nouveau concept ou de modification fonctionnelle du champ d’application de l’automatisation, un nouvel effort de développement serait nécessaire et les scénarios de tests initiaux ne seraient plus payants.
• Aucun plan de test n’a été préparé : Avant de se lancer dans l’automatisation des tests, l’équipe du projet doit s’assurer qu’elle dispose d’un plan de test prévoyant en détail la manière dont les caractéristiques de l’application doivent être testées. Ce plan de test constitue la base de l’automatisation. Son absence peut donner lieu à la rédaction de scripts de scénarios de tests qui n’abordent pas réellement le processus principal et essentiel de l’application, et à un champ d’application qui ne fournit aucune information véritablement utile sur le risque commercial lié à la version testée ; à la rédaction par les développeurs de scripts de scénarios de tests qui fonctionnent uniquement dans une certaine configuration et pas dans d’autres, alors qu’ils le devraient.
  Son absence peut, pire encore, donner lieu à la rédaction de scripts de scénarios de tests qui valident un comportement incorrect.
• Scénarios de tests compliqués qui nécessitent des coûts considérables de mise en œuvre, qui échouent souvent et qui impliquent une maintenance à chaque exécution. Mieux vaut ne pas inclure ce genre de tests dans le champ d’application.
• Les plateformes dont la compatibilité est limitée
• Une solution d’automatisation qui ne favorise pas le principe de réutilisation ni une bonne qualité de code susceptible de faciliter les tâches de maintenance et permettant de réutiliser les mêmes scénarios de tests avec différents jeux de données / différentes configurations.