14. Comment nous faisons les tests▲
C'est la partie la plus difficile. Je ne sais pas si c'est la partie la plus difficile de Scrum, ou juste la partie la plus difficile du développement logiciel en général.
Le test est la partie qui va probablement varier le plus entre différentes organisations. Cela dépendra du nombre de testeurs que vous avez, de l'ampleur de l'automatisation de vos tests, de quel type de système vous avez (juste server+application web ? ou bien vous êtes un éditeur de logiciel vendu dans des boîtes ?), de la durée des cycles de release, de la criticité du logiciel (un serveur de blog vs. un système de contrôle de vol), etc.
Nous avons pas mal expérimenté sur la manière de faire des tests dans Scrum. Je vais essayer de décrire ce que nous avons fait et appris jusque là.
14-1. Vous ne pouvez probablement pas éliminer la phase de tests d'acceptation▲
Dans le monde Scrum idéal, un sprint produit une version de votre système potentiellement déployable. Alors il n'y a qu'à le déployer, n'est-ce pas ?
Faux.
D'après notre expérience, cela ne fonctionne généralement pas. Il y aura de méchants bugs. Si la qualité a une valeur quelconque pour vous, il faut une sorte de phase de test d'acceptation manuelle. C'est le moment où des testeurs dédiés, qui ne font pas partie de l'équipe, martèlent le système avec ces types de tests que l'équipe Scrum n'avait pas imaginés, ou n'avait pas eu le temps de faire, ou pour lesquels elle n'avait pas le matériel nécessaire. Les testeurs accèdent au système exactement comme les utilisateurs finaux, ce qui signifie qu'ils doivent le faire manuellement (en supposant que votre système est destiné à des utilisateurs humains).
L'équipe de test va trouver des bugs, l'équipe Scrum va devoir faire des releases de corrections de bugs, et tôt ou tard (j'espère tôt) vous pourrez livrer aux utilisateurs finaux une version corrigée 1.0.1, au lieu de la version instable 1.0.0.
Quand je dis « phase de tests d'acceptation », je fais référence à la période complète de tests, débogage, et nouvelles releases jusqu'à ce qu'il y ait une version suffisamment bonne pour la production.
14-2. Minimisez la phase de tests d'acceptation▲
La phase de tests d'acceptation fait mal. On sent clairement qu'elle n'est pas agile. Bien qu'il ne soit pas possible de l'éliminer, nous pouvons (et nous y parvenons) essayer de la minimiser. Plus précisément, de minimiser la quantité de temps nécessaire pour la phase de tests d'acceptation. Ce résultat est obtenu en :
- Maximisant la qualité du code produit par l'équipe Scrum
- Maximisant l'efficacité du travail de test manuel (c'est-à-dire trouver les meilleurs testeurs, leur donner les meilleurs outils, s'assurer qu'ils rapportent les tâches consommatrices de temps qui pourraient être automatisées)
Alors comment maximisons-nous la qualité du code produit par l'équipe Scrum ? Eh bien, il y a plein de manières. En voici deux qui marchent très bien d'après nous :
- Mettre des testeurs dans l'équipe Scrum
- En faire moins par sprint
14-3. Augmenter la qualité en mettant des testeurs dans l'équipe Scrum▲
Oui, j'entends bien les deux objections :
- « Mais c'est évident ! Les équipes Scrum sont supposées être multifonctions. »
- « Les équipes Scrum sont supposées être sans rôle. On ne peut pas avoir quelqu'un qui serait uniquement un testeur ! »
Laissez-moi clarifier. Ce que je veux dire par « testeur » dans ce cas est « une personne dont le talent principal est le test », plutôt que « une personne dont le rôle est seulement de tester ».
Les développeurs sont souvent d'assez mauvais testeurs. Surtout les développeurs testant leur propre code.
14-3-1. Le testeur est le « gars qui signe officiellement »▲
En plus d'être « juste » un membre de l'équipe, le testeur a un boulot important. C'est le gars qui décide quand c'est terminé. Rien n'est considéré comme « terminé » dans un sprint tant que lui n'a pas dit que c'était terminé. J'ai découvert que les développeurs disent souvent que quelque chose est terminé alors que ce ne l'est pas réellement. Même si vous avez une définition de « terminé » très claire (et vous devriez vraiment en avoir une, voir page 40 « la définition de 'terminé' »), les développeurs vont l'oublier fréquemment. Nous programmeurs sommes des gens impatients et nous désirons passer à la tâche suivante dès que possible.
Mais alors comment M. T (notre testeur) sait-il que quelque chose est terminé ? Eh bien, avant tout, il devrait (surprise) le tester ! Dans beaucoup de cas, il s'avère que quelque chose considéré comme « terminé » par un développeur n'est même pas testable. Parce que son travail n'a pas été enregistré dans le système de gestion de sources, parce qu'il n'a pas été déployé sur le serveur de tests, ou parce qu'il n'est pas possible de l'exécuter, etc. Une fois que M. T a testé la fonctionnalité, il devrait parcourir la check-list définissant « terminé » (si vous en avez une) avec le développeur. Par exemple si la définition de « terminé » exige qu'il devrait y avoir une note de release, alors M. T vérifie qu'il y a bien une note de release. S'il existe une sorte de spécification plus formelle pour la fonctionnalité (c'est rare dans notre cas) alors M. T vérifie cela également. Etc.
Un effet de bord positif de tout cela est que l'équipe a maintenant un gars qui est parfaitement au point pour organiser la démonstration du sprint.
14-3-2. Que fait le testeur quand il n'y a rien à tester ?▲
Cette question est posée sans arrêt. M. T : « Hé Scrum master, il n'y a rien à tester en ce moment, alors qu'est-ce que je dois faire ? » Il peut falloir une semaine avant que l'équipe ne termine la première histoire, donc que devrait faire le testeur pendant ce temps ?
Eh bien, tout d'abord, il devrait préparer les tests. C'est-à-dire écrire les spécifications de test, préparer un environnement de test, etc. Donc quand un développeur a quelque chose de prêt à tester, il ne devrait pas y avoir d'attente, M. T devrait commencer à tester immédiatement.
Si l'équipe pratique le DDT alors des gens passent du temps à écrire du code de test depuis le premier jour. Le testeur devrait programmer en duo avec les développeurs qui écrivent du code de test. Si le testeur ne sait pas programmer, alors il devrait tout de même programmer en duo avec les développeurs, sauf qu'il devrait seulement jouer le rôle du navigateur et laisser le clavier au développeur. Un bon testeur imagine généralement des types de test différents de ceux d'un bon développeur, si bien qu'ils sont complémentaires l'un de l'autre.
Si l'équipe ne pratique pas le DDT, ou s'il n'y a pas assez d'écriture de cas de tests pour occuper tout le temps du testeur, il devrait simplement faire ce qu'il peut pour aider l'équipe à atteindre le but du sprint. Tout comme n'importe quel autre membre de l'équipe. Si le testeur peut programmer c'est super. Sinon, votre équipe devra identifier toutes les tâches hors programmation qui doivent être faites dans le sprint.
Durant la décomposition des histoires en tâches pendant la réunion de planning de sprint, l'équipe a tendance à se focaliser sur les tâches de programmation. Toutefois, habituellement il y a beaucoup de tâches hors programmation qui doivent être faites dans le sprint. Si vous passez du temps à essayer d'identifier les tâches hors programmation durant la phase de planning du sprint, il y a des chances pour que M. T soit capable de contribuer pas mal, même s'il ne sait pas programmer et s'il n'y a pas de tests à faire tout de suite.
Exemples de tâches hors programmation qui doivent souvent être faites dans un sprint :
- Mettre en place un environnement de test.
- Eclaircir les spécifications.
- Discuter les détails de déploiement avec le service Opérations.
- Ecrire les documents de déploiement (notes de release, demandes de commentaires, ou quoi que ce soit que votre organisation fasse).
- Gérer les contacts avec des ressources externes (concepteurs d'IHM par exemple).
- Améliorer les scripts de build.
- Raffiner la décomposition des histoires en tâches.
- Identifier les questions clés posées par les développeurs et obtenir des réponses.
D'un autre côté, que faisons-nous si M. T devient un goulet d'étranglement ? Disons que nous sommes au dernier jour du sprint et que soudainement beaucoup de choses sont faites et que M. T n'a aucune chance de tout tester. Que faisons-nous ? Eh bien nous pourrions transformer tout le monde dans l'équipe en assistants de M. T. Il décide ce qu'il doit faire lui-même, et il délègue le travail de base au reste de l'équipe. Voilà en quoi consiste une équipe multifonctionnelle !
Donc oui, M. T joue un rôle spécial dans l'équipe, mais il est tout de même autorisé à faire d'autres travaux, et les autres membres de l'équipe sont tout de même autorisés à faire son travail.
14-4. Augmenter la qualité en en faisant moins par sprint▲
On en revient à la réunion de planning de sprint. Pour faire court, n'essayez pas de faire rentrer trop d'histoires dans le sprint. Si vous avez des problèmes de qualité, ou de longs cycles de test d'acceptation, faites en moins par sprint ! Cela va presque automatiquement conduire à une qualité plus élevée, des cycles de test d'acceptation plus courts, moins de bugs affectant les utilisateurs finaux, et une productivité plus élevée dans le long terme puisque l'équipe peut se focaliser tout le temps sur de nouveaux trucs au lieu de corriger de vieux trucs qui cassent sans arrêt.
C'est presque toujours plus rentable de construire moins, mais de le construire stable, plutôt que de construire beaucoup de choses et d'ensuite avoir à faire des hot-fix dans la panique.
14-5. Est-ce que les tests d'acceptation devraient faire partie du sprint ?▲
Nous hésitons beaucoup ici. Certaines de nos équipes incluent les tests d'acceptation dans le sprint. Toutefois la plupart de nos équipes ne le font pas, pour deux raisons :
- Un sprint est à durée limitée. Le test d'acceptation (selon ma définition qui inclut le débogage et les nouvelles releases) est très difficile à limiter dans le temps. Que faire si le délai est dépassé et que vous avez toujours un bug critique ? Allez-vous livrer le produit en production avec un bug critique ? Allez-vous attendre jusqu'au sprint suivant ? Dans la plupart des cas les deux solutions sont inacceptables. Donc nous n'y incluons pas le test d'acceptation manuel.
- Si vous avez plusieurs équipes Scrum travaillant sur le même produit, le test d'acceptation manuel doit être effectué sur le résultat combiné des deux équipes. Si les deux équipes ont fait l'acceptation manuelle durant le sprint, vous avez quand même besoin d'une équipe pour tester la release finale, qui est le build intégrant le travail des deux équipes.
Cela n'est en aucune façon une solution parfaite mais elle est suffisamment bonne pour nous dans la plupart des cas.
14-6. Des cycles de sprints vs. des cycles de test d'acceptation▲
Dans un monde McScrum parfait vous n'avez pas besoin de phases de test d'acceptation puisque chaque équipe Scrum livre une nouvelle version de votre système prête pour la production après chaque sprint.
Eh bien voici une image plus réaliste :
Après le sprint 1, une version 1.0.0 buggée est livrée. Durant le sprint 2, des rapports de bugs commencent à arriver et l'équipe passe la majeure partie de son temps à débugger et est forcée de faire à mi-sprint une release 1.0.1 de correction de bugs. Ensuite à la fin du sprint 2 ils livrent une nouvelle version 1.1.0 avec de nouvelles fonctionnalités, qui est bien sûr encore plus buggée puisqu'ils ont eu encore moins de temps pour la faire correctement cette fois-ci étant donné toutes les perturbations venant de la release précédente. Etc etc.
Les hachures rouges dans le sprint 2 symbolisent le chaos.
Pas très joli n'est-ce pas ? Eh bien, ce qui est triste c'est que le problème perdure même si vous avez une équipe de test d'acceptation. La seule différence est que la plupart des rapports de bugs vont venir de l'équipe de test au lieu de clients finaux mécontents. C'est une énorme différence sur le plan commercial, mais pour les développeurs cela revient à peu près à la même chose. Sauf que les testeurs sont habituellement moins agressifs que les utilisateurs finaux. Habituellement.
Nous n'avons trouvé aucune solution simple à ce problème. Cependant nous avons beaucoup expérimenté avec différents modèles.
Avant tout, à nouveau, il faut maximiser la qualité du code que l'équipe Scrum délivre. Le coût de trouver et corriger les bugs très tôt, durant un sprint, est bien plus faible en comparaison du coût de les trouver et corriger après.
Mais il reste le fait que, même si on peut minimiser le nombre de bugs, il y aura toujours des rapports de bugs qui arriveront après qu'un sprint soit terminé. Comment gérons-nous cela ?
Approche 1 : « Ne commencez pas à construire de nouvelles choses avant que les anciennes ne soient en production »
Ca a l'air bien n'est-ce pas ? Avez-vous ressenti vous aussi ce sentiment de satisfaction ?
Nous avons été proches d'adopter cette approche plusieurs fois, et avons conçu de beaux modèles sur la manière de le faire. Toutefois nous avons toujours changé d'avis quand nous avons réalisé l'inconvénient. Il nous faudrait ajouter une période de release sans limite de temps entre les sprints, pendant laquelle nous ferions seulement du test et du débogage jusqu'à ce que nous puissions faire une release de production.
Nous n'avons pas aimé l'idée d'avoir des périodes sans limite de temps entre les sprints, principalement parce que cela casserait le rythme régulier des sprints. Il ne serait plus possible de dire « toutes les 3 semaines nous démarrons un nouveau sprint ». De plus, cela ne résout pas complètement le problème. Même si nous avons une période de release, il y aura toujours des rapports de bugs urgents qui arriveront de temps en temps, et il nous faut être prêt à les gérer.
Approche 2 : « OK pour commencer à construire de nouvelles choses, mais priorisez la mise en production des anciennes »
C'est notre approche préférée. En tout cas pour le moment.
Fondamentalement, quand nous finissons un sprint nous commençons le suivant. Mais nous nous attendons à passer un certain temps dans le sprint suivant à corriger des bugs du dernier sprint. Si le sprint suivant est sérieusement endommagé à cause du temps qu'il a fallu pour corriger des bugs du sprint précédent, nous évaluons pourquoi cela est arrivé et comment nous pouvons améliorer la qualité. Nous nous assurons que les sprints sont suffisamment longs pour survivre à une bonne période de correction de bugs du sprint précédent.
Progressivement, sur une période de pas mal de mois, la quantité de temps passée à corriger des bugs des sprints précédents a diminué. De plus nous avons pu impliquer moins de gens quand des bugs arrivaient, si bien qu'il n'était pas nécessaire de perturber l'ensemble de l'équipe à chaque fois. Maintenant nous sommes à un niveau plus acceptable.
Durant les réunions de planning de sprint nous fixons le facteur de focalisation à une valeur suffisamment basse pour prendre en compte le temps que nous nous attendons à passer à corriger des bugs du sprint dernier. Avec le temps les équipes sont devenues assez bonnes à cette estimation. La métrique de vélocité aide beaucoup (voir page 31 « Comment l'équipe décide quelles histoires inclure dans le sprint ? »).
Mauvaise approche - « se focaliser sur la construction de nouvelles choses »
Cela signifie en effet «se focaliser sur la construction de nouvelles choses plutôt que d'arriver à mettre les anciennes en production». Qui voudrait faire ça ? Pourtant nous avons souvent fait cette erreur au début, et je suis sûr que beaucoup d'autres entreprises l'ont faite aussi. C'est une maladie liée au stress. Beaucoup de managers ne comprennent pas que, quand tout le codage est fini, vous êtes généralement encore loin de la release de production. Du moins pour les systèmes complexes. Donc le manager (ou le directeur de produit) demande à l'équipe de continuer à ajouter de nouvelles choses alors que le fardeau de vieux code presque-prêt-pour-la-release devient de plus en plus lourd, et ralentit tout.
14-7. Ne distancez pas le maillon le plus lent de votre chaîne▲
Disons que le test d'acceptation est votre maillon le plus lent. Vous n'avez pas assez de testeurs, ou la période de test d'acceptation dure longtemps à cause la qualité lamentable du code.
Disons que votre équipe de test d'acceptation peut tester au plus 3 fonctionnalités par semaine (non, nous n'utilisons pas les « fonctionnalités par semaine » comme métrique ; j'utilise le terme juste pour cet exemple). Et disons que vos développeurs peuvent développer 6 nouvelles fonctionnalités par semaine.
Il va être tentant pour les managers ou directeurs de produit (ou peut être même pour l'équipe) de planifier le développement de 6 nouvelles fonctionnalités par semaine.
Ne le faites surtout pas ! La réalité va vous rattraper d'une manière ou d'une autre, et ca va faire mal.
Plutôt, planifiez 3 nouvelles fonctionnalités par semaine, et passez le reste du temps à réduire le goulet d'étranglement du test. Par exemple :
- Faire travailler quelques développeurs comme testeurs (oh ils vont vous adorer pour cela...).
- Implémenter des outils et scripts qui rendent le test plus facile.
- Ajouter plus de code de test automatisé.
- Augmenter la longueur des sprints et inclure le test d'acceptation dans les sprints.
- Définir certains sprints comme des «sprints de test» pendant lesquels l'équipe complète travaille comme une équipe de test d'acceptation.
- Embaucher plus de testeurs (même si cela signifie supprimer des postes de développeurs)
Nous avons essayé toutes ces solutions (sauf la dernière). La meilleure solution à long terme est bien sûr les points 2 et 3, c'est-à-dire de meilleurs outils et scripts ainsi que l'automatisation des tests.
Les rétrospectives sont un bon forum pour identifier le maillon le plus lent dans la chaîne.
14-8. Retour à la réalité▲
Je vous ai probablement donné l'impression que nous avons des testeurs dans toutes les équipes Scrum, que nous avons de grosses équipes de test d'acceptation pour chaque produit que nous livrons après chaque sprint, etc.
Eh bien, nous ne les avons pas.
Nous avons quelquefois réussi à faire tout cela, et nous en avons vu les effets positifs. Mais nous sommes encore loin d'un processus d'assurance qualité acceptable, et nous avons encore beaucoup à apprendre dans ce domaine.