Introduction

La connaissance du métier est un des versants les plus forts dans le test, à tel point qu’une personne qui n’a aucune vision sur le test saura trouver des anomalies à forte valeur ajoutée tandis qu’un testeur professionnel sans connaissance métier saura s’organiser, mais il devra partir à la pêche aux informations pour commencer à savoir ce qu’il faut chercher…

Ce chapitre va répertorier quelques pratiques qui viendront vous aider dans l’obtention d’un meilleur produit par des pratiques qui vont permettre la maîtrise du métier.

Quelques techniques d’idéation

Que ce soit lors d’un PI planning ou d’un Sprint Refinement, avant d’arriver au sein d’une équipe de réalisation, les besoins émergent par certains méandres de l’organisation. Cette section montre quelques techniques qui peuvent être utilisées dans des équipes liées au management de produit tel qu’une équipe marketing.

Dans le cadre du test, l’intérêt porté sur la fourniture des besoins tient à deux points :

elles font partie de la base de test [ISTQB 2023] et sont donc la matière première des tests, et en tant que tels la qualité des tests s’en ressentira ;
parce qu’elles font partie du socle qui définit le produit et constitue une base tangible de la connaissance du produit (voir chapitre Facteurs de succès).

C’est pourquoi, dans une approche du « tester tôt », nous allons voir comment peut se passer la formalisation des besoins afin d’être capable de traiter les défauts au plus près de leurs racines, sachant que selon Boris Beizer, cette partie provoque environ 8 % des anomalies d’un produit [Beizer 1990][Laporte 2017]. Cependant, la rentabilité des actions préventives et correctives liées aux tests sur l’idéation est évidente, car elles sont situées tôt dans la génération du produit.

1. Design Thinking

Le Design Thinking, démarche inspirée par la conception que l’on peut traduire par « Pensée par le Design », trouve ses racines dans les années 1970 à 90 avec les travaux de McKim [McKim 1972] [McKim 1980] et Faste [Faste 1993]. C’est une approche de l’innovation basée sur l’observation directe de ce que veulent les utilisateurs et le marché. Elle suit les phases suivantes [Lewrick 2018] :

comprendre notamment les types d’utilisateurs ;
observer les types d’utilisateurs ;
définir un point de vue sur les points relevés par les types d’utilisateurs ;
faire une idéation créative des points de vue ;
développer des prototypes autour des idéations ;
tester les prototypes avec les utilisateurs ;
mener...

Idéation et spécification des besoins

Quelle que soit la technique d’idéation utilisée, lorsque le besoin a émergé, il est nécessaire de passer à sa réalisation.

1. Backlog du portfolio

Lorsque les idées naissent au sein d’une organisation, il est nécessaire que ce besoin soit priorisé et budgété.

Lorsque le besoin a un impact limité à une équipe, le PO est pour ainsi dire le seul maître à bord. Il priorise ses besoins et demande à l’équipe la charge prévisionnelle, le budget, dont elle aura besoin pour savoir si l’ensemble des besoins, les US, pourrait être réalisé dans l’intervalle d’un sprint.

Cependant, lorsque le besoin s’avère être plus large qu’une équipe, il devient alors indispensable de prendre plus de hauteur dans la hiérarchie, car les enjeux peuvent impacter la stratégie de l’entreprise. De même, si une idée ne concerne qu’un train, elle sera déléguée au manager fonctionnel du train. Cette approche décentralisée correspond au principe de décentralisation proposé par SAFe [SAFe 2023-12].

Tandis que « Huge LeSS » se contente de définir des domaines fonctionnels, SAFe propose de mettre en œuvre un kanban pour qualifier le besoin, c’est le « portfolio backlog ».

Ce kanban comporte différentes étapes [SAFe 2023-11] :

Entonnoir : capture de grandes idées ;
Revue : affinage et formalisation de l’idée, priorisation pour l’analyse ;
Analyse : solutions alternatives, affinage des estimations, définition du MVP, génération d’un « Lean Business Case », Go/NoGo ;
Prêt : approbation par la hiérarchie, priorisation pour l’implémentation ;
Implémentation : génération et évaluation d’un MVP, rejeter ou persévérer ;
Fait : l’idée sort du périmètre du backlog de portfolio.

Figure III-5 : Kanban du portfolio

2. Temporalisation des demandes

Il peut être tentant de prendre le macrobesoin le plus important...

Test des éléments

Nous avons vu plus haut comment décrire des US ou des epics pour qu’elles soient suffisamment bonnes. Ici, nous allons nous pencher sur la composante liée aux tests des éléments dans le backlog du produit.

1. Démarche ATDD pour développer une US

Écrire les tests d’acceptation, puis coder, et enfin tester n’est pas suffisant. Si votre équipe pense coder toute la US puis la vérifier avec les tests, cela revient à introduire un mini Waterfall dans le processus de développement, introduit un stock intermédiaire de code non vérifié avec le risque qu’aucun critère ne passe.

Lorsque Dan North a imaginé le BDD, il avait à l’esprit l’approche « Test First » - « commencez par les tests » - proposée par Kent Beck avec sa technique de développement nommée TDD (« Test-Driven Development » - développement piloté par les tests). Lorsque l’ATDD est mis en œuvre par des tests automatisés, vous pouvez facilement décomposer la démarche en trois phases :

ROUGE : introduire un seul test, qui doit échouer - le test est marqué en rouge - s’il passe, on en crée un autre car celui-ci ne nous a rien appris ;
VERT : faire le minimum de code de production pour que tous les tests passent et soient au vert ;
REFACTORING : profiter que tous les tests sont au vert pour faire du ménage dans le code en surveillant ainsi les régressions.

Figure III-18 : L’approche « Red-Green-Refactor » du TDD

Cette approche est évidemment plus efficace lorsque les tests sont automatisés car à chaque fois il faut repasser tous les tests pour s’assurer qu’il n’y a pas de régression, c’est pourquoi la syntaxe Gherkin est à forte valeur ajoutée pour faciliter l’automatisation.

Toujours sur le plan de l’efficacité, les bénéfices sont maximisés...

Versant métier