Il m’arrive encore de voir des équipes qui prennent la décision de tout tester en fin de sprint et seulement à ce moment là. Nous allons voir ensemble les raisons qui amènent à penser qu’il n’est pas recommandé de tout tester en fin de sprint.
Pourquoi il n’est pas recommandé de tout tester en fin de sprint ?
Attendre la fin des développements de l’ensemble des items d’un sprint pour tester n’est pas idéal. Bien qu’au premier abord, cela ne peut sembler poser aucun problème, l’équipe se retrouve vite confrontée à diverses problèmes non négligeables.
Je vais lister quelques problèmes que nous rencontrons régulièrement avec cette façon de faire (il en existe probablement d’autres).
Des tests plus longs que prévu
Le Product Owner ou l’homologateur (nom donné aux testeurs dans certaines entreprises) n’a pas le temps de tout tester correctement. Il sera contraint de reporter des tests qui viendront-))p^)—— perturber l’équipe dès le démarrage du sprint suivant (en cas d’anomalies constatées).
Certaines équipes vont même jusqu’à décaler le démarrage du sprint suivant pour terminer cette phase de tests. Cela perturbe totalement le bon fonctionnement de l’équipe.
Perturbation des équipes
De plus, le scrum tente d’amener les équipes de réalisation à s’engager sur un sprint ; si les tests décalent le démarrage réel du sprint suivant, il sera compliqué pour eux de s’engager réellement.
De plus, ces perturbations peuvent également démotiver les équipes de réalisation. Il y a plusieurs raisons qui peuvent amener à cela :
- burndown chart qui n’est jamais bon
- le décalage des sprint planning qui donne une impression de bidouiller
- gestion des anomalies en une seule fois (impression d’y dédier du temps)
La sprint review mise à mal
En effet, quand tout est testé en fin de sprint, il sera plus compliqué de bien maitriser sa sprint review. L’idéal de cette cérémonie est d’amener les utilisateurs, parties prenantes voire sponsors pour obtenir des feedbacks constructifs.
Mais si nous testons tout en fin de sprint, nous ne saurons jamais réellement ce qui sera présentable. Et en invitant des acteurs extérieurs pour présenter des fonctionnalités qui ne les intéressent pas, vous risquez de ne plus les revoir lors des prochains rendez-vous.
S’il ne viennent plus, nous n’aurons plus de feedbacks constructifs… Il faut donc faire très attention à ne pas les faire déplacer pour rien?
Quel est le fonctionnement idéal ?
L’idéal est de tester un user-story dès qu’elle arrive dans la colonne « test ». Encore mieux, le testeur (ou product owner) va directement tester la user-story avec les développeurs qui ont travaillé dessus.
Cette méthode est très efficace car cela évite que les développeurs qui ont travaillés sur cette user-story se lancent dans un autre challenge avant d’avoir intégralement terminé la user-story.
Pour limiter au maximum les anomalies, il est possible de mettre des pratiques d’excellences en place :
- BDD/ 3 amigos : écriture des tests pour guider les développeurs
- TDD/ATDD : automatisation de tests
- TCR : amener à l’excellence technique
Voici quelques articles que je peux vous proposer pour approfondir sur ces différentes pratiques.
Articles :
Quelle est la différence entre l’ATDD et la BDD ?
Travailler en TDD (Test Driven Development)
Les tests TCR (test && commit || revert)
Les 3 amigos en agile
Le BDD (Behavior Driven Development)
Conclusion ne pas tester en fin de sprint
Vous l’aurez compris, tester l’ensemble des user-stories en fin de sprint n’est pas idéal car cette façon de faire apporte son lot de problème. Nous vous recommandons de privilégier de tester les user-stories dès la fin des développements de chacune d’entre elles.
Soyez le premier à commenter