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 :
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 Responses
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 ?
En effet, je corrige, merci!
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é ?
Dans cet article c’est le nombre d’exécution du cas de test A
Bonjour,
Pourriez-vous partager avec nous le fichier excel svp ?
Cordialement,
Bonjour,
désolé je n’ai plus ce fichier excel. Mais c’était un fichier factice fait pour l’article.