Adopter une vision économique

Description

Le premier principe que SAFe adopte est la vision économique dans son organisation [SAFe 2021-1]. Ce principe ne concerne pas seulement l'estimation des budgets, mais aussi toute la chaîne de livraison et d'exploitation des solutions, notamment en déployant le plus tôt et le plus souvent possible, ce qui est la base d'une organisation Lean/Agile/DevOps afin de limiter la dérive budgétaire. En effet, plus une release attend, plus :

• l'organisation retarde le moment où les nouvelles fonctionnalités peuvent lui rapporter de l'argent, à elle ou à ses clients [Reinertsen 2009].
• le budget prévu et la dérive des coûts réels

‍

De plus, une vision économique vient dépendre [SAFe 2021-1] de :

• les retards introduits par les processus
• les coûts de fabrication du produit
• la valeur ajoutée apportée
• coûts de développement
• les risques techniques et commerciaux associés au produit

Application à la maturité des tests

Google introduit dans sa vision de DevOps la notion de" budget d'erreur" [Beyer 2016] qui prend en compte une certaine vision économique liée à la sortie d'une version de mauvaise qualité et le test permet d'estimer le coût lié à la non-qualité.

En effet, le test est avant tout un retour d'expérience et la diffusion la plus précoce possible contribue à la mise en œuvre du principe de l'ISTQB " tester tôt " [Radid 2018].

En effet, plus le retour d'information est précoce, moins il est facile de trouver bugs et plus il est coûteux de le réparer.

De plus, l'automatisation des tests permet de réduire le coût de chaque lot à livrer, notamment sur les tests de régression, et limite les coûts inhérents à la non-qualité par leur présence systématique. Ce dernier point est cependant limité par deux facteurs :

• le site maintenance des scripts en cas de modification de l'interface à tester
• le nombre de faux positifs générés par les scripts [Philipp 2018] [Moustier 2020].

‍

La position d'Agilitest sur cette pratique

Agilitest est un outil simple à prendre en main et réduit les coûts associés à la courbe d'apprentissage que l'on retrouve dans les outils traditionnels tels que Selenium qui nécessitent au préalable de solides connaissances en programmation [Chevalier 2019].

Les scripts sont #nocode [Forsyth 2021] et donc dépourvus des boucles que l'on trouve dans les langages de programmation, bien qu'il permette une itération sur un fichier csv ou json. Cette simplicité des scripts a pour but de limiter les coûts maintenance des scripts complexes [Hannachi 2019], le déroulement d'un scénario étant linéaire.

L'éditeur dispose de fonctionnalités spécifiques qui réduisent et facilitent les activités de maintenance , telles que Rapports vidéo de déroulement pas à pas.

Le moteur d'exécution de ATS supporte de nombreuses technologies et a été conçu pour éviter flaky tests, ce qui permet au client d'exécuter un grand nombre de tests (en général, les clients d'Agilitest ont plus de 1000 tests qu'ils exécutent chaque nuit ou chaque version).

De plus, contrairement à de nombreux frameworks d'automatisation, seul l'éditeur est payant, alors que le moteur est disponible sur open source (ATS) et que les scripts peuvent être édités avec un simple éditeur de texte. Cela signifie que les clients d'Agilitest ne sont pas prisonniers de la plateforme et ne perdent pas le legacy des scripts développés sous Agilitest.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍