5S sur le code

Qu'est-ce que le 5S sur code ?

L'approche "5S" a été inventée chez Toyota, entre les années 50 et 70 et popularisée dans les années 80 [Miller 2017-2]. Certains experts des 5S définissent son origine au XVIe s. avec l'arsenal vénitien [Miller 2017] [Cruz 2018], qui aurait prétendument démontré au roi Henri III de France leur capacité à construire un navire en deux heures [voir https://www.quality-assurance-solutions.com/History-of-5S.html].

"5S" est une technique de Lean Management qui permet de prendre soin d'un bien.

Pour plus de détails sur cette notion, veuillez vous référer au 5S sur les cas de test.

Impact des 5S sur code sur la maturité des tests

Naturellement, l'application des 5S au code de production et aux scripts de test est quelque chose qui devrait être promu dans l'organisation ; cependant, en ce qui concerne les scripts de test, il est extrêmement précieux pour les scripts qui sont responsables de flaky tests - également connus sous le nom de faux positifs (FP). Les FP sont des problèmes provenant des scripts de test qui arrêtent le pipeline d'intégration et nécessitent que le développeur corrige le problème, tout comme l'opérateur de ligne dans une usine automatisée.

En fait, les FP surviennent 72 % du temps lorsqu'un problème est soulevé, principalement en raison de problèmes de script (46 %) [Philipp 2019].

‍

Voici 4 exemples qui démontrent l'utilisation des 5S sur les scripts de test :

• Les PC prouvent que l'amélioration de la fiabilité des scripts de test est majeure. Les 5S sont un moyen de l'améliorer, car ils visent à gérer les tests non fiables.
• Il en va de même pour les scripts de test "gris" dont le résultat peut être blanc alors qu'il est en réalité noir ou vice versa, réduisant ainsi la fiabilité du pipeline de livraison.
• Les scripts lents doivent également être traités lors d'une session 5S, afin de les lancer dans un pipeline hors ligne qui s'exécutera de manière asynchrone par rapport aux commits de code Dev qui doivent être exécutés dans les 10'.
• Lorsqu'un script n'est plus lancé depuis un certain temps, il peut rencontrer des problèmes liés aux changements de produits. Le maintien de tels scripts conduira inévitablement à leur mise hors service, car le retour sur investissement ne sera plus digne d'intérêt. 

Par conséquent, la mise au rebut des scripts inutiles avec un 5S, est utile concernant le paradoxe du pesticide [ISTQB 2018] puisque les cas de test ne déclenchent plus bugs ; et idéalement, les tests devraient être automatiquement étiquetés à partir de l'exécution du test, notamment grâce au pipeline ou à la plateforme d'automatisation des tests. Ces tags peuvent ensuite être utilisés pour trier et regrouper les éléments. Ils fournissent des informations claires sur tout script afin que les équipes puissent planifier ou prendre les mesures d'amélioration appropriées tout en visitant le script.

Le point de vue d'Agilitest sur les 5S sur code

En tant qu'éditeur de scripts capable de gérer des scripts de test, Agilitest propose une fonction de marquage. C'est un support important pour mettre en place un 5S sur les cas de test. De plus, l'outil propose de rassembler les tags en groupes pour permettre une vue d'ensemble sur cet actif de test.

Si vous souhaitez activer la génération de tags à partir de l'exécution d'un script, demandez de l'aide à Agilitest.

‍

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

‍