Hypothèse de variabilité

Description

Ce troisième principe de SAFe [SAFe 2021-3] est le premier à aborder l'idée d'agilité où les attentes peuvent changer jusqu'au dernier moment. Il est l'impact direct du deuxième principe agile décrit dans le manifeste :

"Accueillir les changements d'exigences, même tard dans le projet [...]".

Cette hypothèse implique en particulier :

• Ne pas aller trop loin dans l'idéation pour éviter de devoir tout recommencer en cas de changement d'orientation des besoins.
• Une conception capable de s'adapter à des circonstances imprévues. Pour y parvenir, l'équipe peut agir sur plusieurs axes tels que :
  ○ la conception flexible, notamment en appliquant les principes SOLID [Wikipedia 2021-1] [Moustier 2019].

                        ○ le développement de plusieurs solutions techniques en parallèle [CMMi 2010] en utilisant une approche "Set-Based Design" [SAFe 2021-13].

• Un code minimal afin de ne pas avoir à jeter trop de travail.
• Ne documenter en détail que les parties fixes.

‍

Application à la maturité des tests

En plus des pratiques décrites ci-dessus, le test doit aussi pouvoir prendre en compte cette hypothèse de variabilité dès la conception :

• Par exemple, lors de la conception d'un produit, les Business Owners (Product Managers, les Product Owners, Marketing...) font des hypothèses qui doivent être vérifiées. C'est ce qu'Eric Ries appelle le "Lean Startup" [Ries 2012] [Vallone 2021]. Cette pratique consiste à concevoir des métriques à partir de l'utilisation du produit qui permettront de vérifier ces hypothèses.
• Pour éviter de perdre du temps en compétition, certaines organisations mettent en production plusieurs implémentations permettant de consolider une hypothèse avec l'approche "A/B Testing" [Moustier 2019-1] [Wikipedia 2021-2].
• Lorsque les cohortes sont trop difficiles et complexes à identifier ou que l'impact sur le marché d'une implémentation est inconnu mais que l'organisation ne veut pas risquer de déstabiliser ses utilisateurs, une autre technique de test appelée"Canary Releasing" (ou "Rollout") peut être utilisée [Sato 2014] [Moustier 2019-1], afin que les problèmes potentiels n'impactent qu'une frange de la population et ne menacent pas l'ensemble de la base d'utilisateurs.
• D'autres techniques de déploiement traitent de l'incertitude liée au besoin ou à la conception, comme le "Dark Launch" ou le "Green/Blue deployment" [Trenel 2017].
• Enfin, pour un code minimal, la pratique du TDD en mode TPP est à forte valeur ajoutée [Martin 2013].

Le test doit également être conçu de la manière la plus flexible possible, par exemple :

• en utilisant des scénarios basés sur l'intention, par exemple par un objectif de test brièvement décrit, afin d'éviter les variantes de mise en œuvre,
• en effectuant des tests exploratoires [Kaner 2004].

‍

Pour éviter la sur-qualité, l'idée est de déduire la stratégie de test à appliquer [Bach 2019] :

• le contexte du projet [Radid 2018]
• les éléments mis à disposition
• et les critères de qualité attendus.

‍

La position d'Agilitest sur cette pratique

Agilitest est un outil qui vous permet de générer rapidement un script de test automatisé grâce à une interface de cartographie de widgets efficace et rapide. De plus, étant donné que les scénarios sont linéaires (il n'y a pas de boucle), le test des scripts est également très rapide. Ainsi, l'automatisation est facilement jetable ce qui réduit le phénomène d'aversion à la perte [Tversky 1981].

‍

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

‍