Le calcul du ROI des tests automatisés, que prendre en compte ?

Pour calculer le ROI des tests automatisés il faut d’abord bien estimer le coût des tests.

J’en avais déjà parlé dans cet article.

Le coût des tests ce n’est pas que leur exécution. Le coût des tests c’est :

·        L’écriture du cas (coût qui n’arrive qu’une seule fois)

·        Le coût de son exécution (ce nombre est potentiellement infini !)

·        Le coût de son analyse en cas d’échec (cela dépend en partie de la qualité de l’écriture du cas, manuel ou automatisé)

·        Sa maintenance (un cas est potentiellement impacté à chaque livraison, pour cela il faut le mettre à jour, un test non maintenu est pire qu’un test inexistant car il fait croire à l’existence d’une couverture qui en fait n’est pas présente)

Pour simplifier, le coût des tests peut être vu en 2 axes qui sont :

·        La phase de mise en place. Cette phase regroupe l’écriture et la conception des cas ainsi que la plupart des procédures de sélection et n’a lieu qu’une fois. J’appellerai A le coût de la phase de mise en place. Le coût A est généralement nettement supérieur avec un test automatisé qu’avec un test manuel. En effet, le test automatisé ajoute le travail d’automatisation (et si besoin, l’implémentation de l’outil ou du framework)

·        La phase de « run », qui démarre après la première exécution du cas. Cette phase regroupe toutes les phases liées à l’exécution (exécution, analyse, bugs…) et la maintenance des cas. Cette partie, moins onéreuse que la première peut être reproduite à l’infini. J’appellerai  n le nombre d’exécutions du cas et B le coût de la phase de run.

Le coût des tests peut donc est calculé après chaque exécution avec cette formule :

Coût = A + n*B

La différence entre les tests automatisés et les tests manuels va se faire entre le « A » et le « B ».

Pour les tests automatisés A est beaucoup plus important que pour les tests manuels.

Par rapport à la partie B, l’exécution seule est normalement beaucoup moins élevée pour les tests automatisés que pour les tests manuels. Pour calculer correctement le Retour sur Investissement il va falloir avoir des tests dont la maintenance n’est pas trop coûteuse !

Il existe de nombreux moyens/bonnes pratiques de limiter ce coût de maintenance. Par exemple :

·        Automatiser des cas de test sur des applications stables et fonctionnalités matures (à quoi bon automatiser un test si on doit le réécrire à chaque livraison ?

·         Ecrire les cas de tests de façon modulaire, c’est-à-dire que les tests appellent des fonctions qui sont mutualisées. Si la fonction évolue il suffit alors de la mettre à jour pour mettre tous les cas à jour.

Vient ensuite le calcul du retour sur investissement : à partir de quand suis-je gagnant ?

Appelons CA le coût des tests automatisés et CM celui des tests manuels.

CA = A + n*B

CM = A’ + n*B’

Dans un cas normal, on a A’ < A et  B’ > B.

CA va donc être, au départ, plus élevé que CM.

Au fur et à mesure des exécutions CA va se rapprocher de CM car son coût de run est moins cher. A partir d’un certain moment les courbes vont se croiser (on peut appeler ce point le point mort). A partir de là l’automatisation aura un retour sur investissement qui ne cessera plus de grandir.

On obtient des courbes similaires à celles-ci :

ROI

Le retour sur investissement n’est présent que si les exécutions sont multipliées (et que la maintenance ne coûte pas trop chère) !

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

6 réponses

  1. Bonjour,

    J’ai comme un doute sur les expressions : « Dans un cas normal, on a A’ > A et B’ < B", n'est-ce pas l'inverse ?

  2. petite question : le nombre d’exécution n est le nombre exécution d’un cas de test A ou de tous les cas de test d’une fonctionnalité ?

    1. Bonjour,
      désolé je n’ai plus ce fichier excel. Mais c’était un fichier factice fait pour l’article.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Image représentant le test et de nombreux éléments liés
Avenir

Sondage: Quel futur pour le test?

Je vous propose aujourd’hui de faire partager votre vision sur le futur du test. Le test est en pleine évolution et essor, les possibilités sont nombreuses, c’est pourquoi je vous propose ce sondage: Quel est selon vous, le futur de notre métier? Vous pouvez répondre en cliquant sur ce lien:

Lire la suite »
Indicateurs

Les dérives des indicateurs… par l’exemple!

Lorsque j’anime des ateliers ou des conférences sur les indicateurs je reviens régulièrement sur la loi de Goodhart: « lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure ». Cette loi très simple rappelle que les indicateurs ne sont qu’une mesure, qu’il faut être capable de les analyser mais également

Lire la suite »
Jardin vécu avec les différents désagréments identifiés (enfants partout, herbes et fleurs envahissantes, arbres problématiques...)
Bug

[Programmez] Contexte, bugs et botanique

Article publié initialement dans le magazine Programmez! Introduction Qu’est-ce qu’un bug ? Comment gérer les bugs ? Faut-il nécessairement les corriger ? Ne doit-on corriger que des bugs ? Il n’y a pas de « bonne » réponse à l’ensemble de ces questions. La notion de « bug » est floue. On n’y trouve d’ailleurs pas, à l’heure

Lire la suite »