Être Agile

Les tests ? Cela n'existe pas en Scrum + XP

Le premier point à bien comprendre, à mon sens, est que les tests au sens habituel (et oui, des années de bourrage de crâne "waterfall", cela laisse des traces...) n'existent pas en agiliité au sens Scrum + XP.
Autrement dit, un test d'acceptance (automatisé ou pas) n'est pas exactement un test de recette au sens habituel.

• Les tests ne sont pas uniquement des tests : ce sont des spécifications
• Il n'y a pas d'un côté celui qui écrit un test (automatisé ou non) et de l'autre ceux qui réalisent le produit : le principe agile de travail collaboratif quotidien n'est pas simplement une déclaration d'intention
• Il n'y a pas dans XP à proprement parler d'activité de conception, de programmation, de tests... Il y a une activité de développement qui englobe tout cela

En d'autres termes, je préfère parler de Pilotage par Spécifications Exécutables, même si le sous-titre de "Maîtriser les projets avec l'Extreme Programming" était "Pilotage par les Tests-Clients".

Spécification, Tests... et Tutti Quanti !

Dire qu'un test d'acceptance est une spécification ne signifie pas que toutes les spécifications passent par des tests !
Je suis régulièrement sidéré par la non-agilité de certaines pratiques pourtant estampillées agiles comme TDD ou ATDD et qui évoquent des problèmes de confiance ou encore l'obligation de tout tester.
La première valeur agile Les personnes et leurs interactions plus importantes que les processus et les outils s'appliquent aussi aux pratiques agiles, y compris ATTD.
En d'autres termes, il s'agit d'être agile et habile. Pour cela, revenons à l'expression de besoins par stories.

• Features : ce sont les caractéristiques du produit, les "thèmes" ou "catégories" tels que fonctionnels, non-fonctionnels, réglementaires...
• Stories : ce sont les unités qui vont permettre à la fois la planification et l'expression de besoins
• Commentaires : rédigés (sous forme de notes associées au stories) ou non, ils viennent compléter l'expression de besoins. Notez que dans une approche agile de flot continu un détail de spécifications est implémenté quasiment dès qu'il est exprimé. Le produit lui-même devient en quelque sorte une documentation de spécifications
• Tests d'acceptance manuels ou automatisés : ils viennent eux aussi préciser la story, en particulier lorsque le Product Owner/Manager souhaite se forger une opinion quant au produit. L'important ici n'est pas tant que le PO rédige lui-même ses tests, l'important est le passage d'information via les tests. Un test est donc un moyen de communication et d'ailleurs les outils d'automatisation (Fitnesse, GreenPepper) sont basés sur des wikis qui sont avant tout des outils collaboratifs.

Nous voyons donc qu'il n'est pas question systématiquement de tout spécifier par tests et encore moins de tout automatiser. Cela dépend de l'équipe.

Les personnes et leurs interactions
sont plus importantes
que les processus et outils de tests.

Trois activités essentielles au quotidien

Pour que les choses soient bien claires, la fabrication du produit repose sur trois activités qui se pratiquent au quotidien sur des cycles très courts via intégration continue.

• Expression de besoins, telle que précisée au dessus
• Développement au sens activité unique qui englobe conception programmation tests-développeurs
• Validation par le Product Owner/Manager.

Intérêts de l'automatisation des tests

A ce point, revenons à l'intérêt d'automatiser des tests.

• Éviter le côté répétitif et laborieux... ennuyeux pour un être humain
• Éviter le côté subjectif du test manuel
• Permettre le passage d'un plus grand nombre de tests

Récemment, l'une des équipes avec lesquelles je travaille automatisait un test qui contenait une quarantaine de paramètres. Imaginez-vous passer ce test manuellement, ne serait qu'une fois par jour ?

Le test automatisé est au Développeur
ce que le fil à plomb est au maçon.

Ce qui m'avait frappé lorsque j'avais commencé - il y a 10 ans - à pratiquer ce pilotage par les tests, c'est le confort en tant que Développeur. Si la première réaction était "Pffff.. Programmer un test alors que je pourrais directement programmer !". Pourtant lorsque j'avais commencé à programmer pour faire passer le test, le résultat d'abord négatif puis positif m'avait donné une certaine sérénité, un confort inconnu jusqu'alors. La métaphore qui m'était apparue est celle du fil à plomb. Imaginez un maçon qui construit un mur et qui décide de tester son mur une fois qu'il est monté en inventant à ce moment-là le moyen de le tester...

Prévention... Oui bien sûr

Alors, face à une pseudo défaite des tests, certains évoquent des pratiques préventives. Évidemment. Nous pourrions dire que l'agilité est par nature préventive. Si nous considérons que notre métier (les trois activités essentielles du dessus) est trop complexe pour être modélisé dans un grand plan qualité, alors nous sommes empiriques c'est à dire que nous mettons en place des pratiques telles que

• Feedback concret et rapide à tous les étages (auto-similarité du feedback)
• Travail d'équipe
• Amélioration continue.

Mais être préventif ne dispense pas de tester.

La question du maintien des tests automatisés

Une vraie question demeure : le maintien des tests automatisés. Si cet ensemble de tests forme les spécifications (parmi d'autres moyens) du produit, alors ce "document" est maintenu à jour au fur et à mesure des évolutions (c'est à dire des nouvelles stories).
Là encore, aucune règle gravée dans le marbre n'oblige à tout maintenir tout le temps.
De même qu'un Dévelppeur XP a le courage de "jeter du code qui pue", de même certains tests n'ont pas à être maintenus et peuvent être supprimés ou remplacés plutôt que modifiés. Là encore, c'est affaire d'habileté de la part de l'équipe.

En conclusion

Etant donné que mon retour d'expérience ne corrobore pas du tout ce qui est décrit dans ces articles incendiaires, j'ai tenu à le partager, ce qui, encore une fois, n'est pas une déclaration d'amour inconditionnelle envers ATDD. L'amélioration continue n'est pas non plus un vœu pieu et s'applique aussi à cette pratique qui englobe expression de besoins et validation.

Pilotage par Spécifications Exécutables :
ne jetons pas le bébé avec l'eau du bain !
Soyons agile et habiles.

• Demande d'information
• Crédit photo : http://www.sxc.hu