Comprendre ce que l'on doit tester

Comment comprendre ce qu'il faut tester

La création d'un produit nécessite de le comprendre au préalable. Si les développeurs sont confrontés à une histoire d'utilisateur (US) qu'ils ne comprennent pas, il leur faudra des siècles pour créer ce qui est réellement attendu. De plus, ils feront rapidement de fausses hypothèses sur la base de ce qu'ils pensent avoir compris. Le pire, c'est qu'il est inévitable de faire des hypothèses, sauf si le chemin emprunté est déjà connu ou évident. Malheureusement, la construction d'un système n'est généralement pas quelque chose d'évident mais une tâche plutôt complexe et plus vous vous enfoncerez dans l'inconnu, plus les hypothèses que vous devrez faire seront importantes.

La logique peut aider à aller plus loin grâce à ce qu'on appelle le "Modus Ponens", une approche déductive connue depuis l'Antiquité et formulée par Théophraste:

Considérant deux assertions

• Si A alors B
• A

Par conséquent, B peut être revendiqué

Malheureusement, une fois de plus, le Modus Ponens conduit à un raisonnement qui est correct et renforce la conviction que nous avons raison bien que la conclusion soit fausse si la prémisse est réellement fausse [McGee 1985].

Il existe une autre technique de raisonnement appelée "Modus Tollens", une approche inductive toujours de Théophraste qui permet de nier les antécédents :

Considérant deux affirmations :

• si A alors B
• pas B

Par conséquent, A est invalide

Pour éviter les sophismes déductifs du Modus Ponens, sa transposition en Modus Tollens peut être utilisée pour exclure des hypothèses, à condition que l'apprentissage en double boucle[Argyris 1977] [Moustier 2020] soit impliqué. Cette stratégie d'apprentissage conduit les personnes à cibler une direction grâce à une connaissance attendue située à un niveau supérieur qui infère une compréhension claire de ce qui est attendu.

Impact sur la maturité des tests

Lorsqu'il s'agit d'environnements complexes tels que le développement d'un grand logiciel, selon le cadre Cynefin [Snowden 2007], l'état d'esprit doit passer de la catégorisation ou de l'analyse à l'exploration et à la détection, ce qui est la base des tests.

‍

Une autre composante du test est l'utilisation de la pensée critique à chaque étape sur une base régulière avec des itérations courtes [Bolton 2012] [Bach 2016] [Moustier 2019-1]. Cet état d'esprit conduit à " être un testeur, pas un vérificateur " et à devenir des défenseurs du client, ce qui n'est possible que si les testeurs comprennent vraiment les utilisateurs et la façon dont ils utiliseront le produit et comment ils vérifieront si quelque chose fonctionne correctement [Laing 2016] [Moustier 2019-1].

En termes de pratiques, il existe plusieurs astuces agiles qui permettent des dispositifs d'apprentissage en double boucle :

• Lean Startup aide à consolider les hypothèses du marché, ce qui est rendu possible par des observables automatisés et déduits US qui mettent en œuvre les hypothèses à vérifier. 
• L'atelier "3 Amigos" est un très bon moyen d'insuffler dans les USce qui doit être testé à un niveau supérieur du code ; les critères d'acceptation peuvent ensuite être automatisés par une approche ATDD.
• Enfin, le style de codage TDD fournit une boucle de rétroaction immédiate sur les hypothèses faites au niveau du code.

‍

Le point de vue d'Agilitest sur cette pratique

Agilitest vise essentiellement les critères d'acceptation au niveau de US et du produit. Mais se fier uniquement à ces tests n'est pas suffisant pour éviter les erreurs ni au niveau du marché ni au niveau du code. De plus, cela introduirait également un certain retard dans le retour d'information puisque l'automatisation exige un produit prêt à être livré ou au moins suffisamment bon pour être testé par un robot.

Par conséquent, pour éviter de se retrouver avec un cône de glace de test et de laisser les développeurs plonger dans des hypothèses erronées, il est fortement recommandé d'effectuer plusieurs types de techniques de test qui devraient être intégrées dès le début [SAFe 2021-26][SAFe 2021-27] avec un produit hautement testable.

‍

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