Introduction
Depuis plusieurs années je travaille constamment dans de grandes organisations qui sont en Agile à l’échelle (ou en transformation à l’agile à l’échelle).
Le sujet de la gestion des tests et plus particulièrement de la stratégie de test est une question qui revient régulièrement.
Parmi les sujets les plus courants il y a les tests bout en bout. Qui est en charge de ces tests ? Quand sont-ils effectués ? Comment s’assurer de ne pas refaire ces tests et de ne pas en oublier ?
Les tests bout en bout dans un cycle « traditionnel »
Dans les cycles de développements traditionnels (généralement cycle en V) les tests bout en bout ont le droit à leur propre phase.
La stratégie de test dans ce contexte définit:
- des personnes (une équipe) en charge de gérer ces tests au niveau de la conception et de l’exécution.
- un environnement dédié est mis à disposition
- quand la phase a lieu (en général à la fin des développement)
Dans des organisations matures le transformation en Agile à l’échelle est très complexe de ce point de vue. En effet, elles passent d’une organisation structurée avec une répartition claire des rôles. La complémentarité des tests est expliquée avec les niveaux de test.
Les tests bout en bout son souvent liés aux niveaux « système » ou « intégration système ».
Pour ces équipes il y a souvent une vraie souffrance lorsqu’elles sont amenées à faire les tests bout en bout dans une organisation qui transforme son cycle de développement pour adopter l’agile à l’échelle.
Les problèmes de « la vraie vie »
Le titre de cette section est une phrase que l’on m’a dite plusieurs fois et qui m’a marquée. Elle m’a été dite aussi bien par des tests manager (en charge de l’approche de test globale) que par des tests lead en charge du bout en bout.
Leurs interrogations sont:
- Qu’est-ce que je dois tester maintenant que les tests sont censés être faits dans les équipes agiles ?
- Comment m’assurer de ne pas trop (ou trop peu) faire au niveau des tests ?
- Sur quelle base concevoir mes tests (épiques, user storys, expression de besoin, scénarios ATDD…) ?
- Combien de temps dédier aux tests de bout en bout ? Que font les équipes pendant ce temps ?
- Qui exécute les tests bout en bout ?
- Quand fait-on les tests bout en bout ?…
Comme vous vous en doutez il n’y a pas une réponse unique à chaque question… Et comme vous vous en doutez, je n’ai pas non plus de réponse immédiate à donner à ces équipes.
Néanmoins, avoir la réponse à ces questions est essentiel si l’on veut s’assurer d’avoir un bon processus qualité.
Je vais donc vous proposer dans cet article quelques réponses usuelles à ces problèmes dans des organisations d’agile à l’échelle.
1 – La complémentarité des tests bout en bout avec les tests des équipes agiles
Pendant les itérations les équipes agiles font, en général, du test bouchonné sur la partie de leur produit. La validation de ces tests est très souvent un élément de la définition of done.
Néanmoins, la partie du produit sur laquelle travaille l’équipe se doit d’être intégrée au produit dans son ensemble. Les tests « bout en bout » sont alors nécessaires.
On est ici en plein dans le principe des niveaux de tests avec des couches de tests qui se complètent.
- Du point de vue de l’équipe agile, les tests « bout en bout » sont l’équivalent de la couche « intégration système »: leur « morceau » du produit global s’intègre t-il bien avec les autres ?
- Du point de vue produit global, on est plutôt sur du test « système »
Dans tous les cas la phase de bout en bout reste importante.
2 – Comment m’assurer de ne pas trop (ou trop peu) faire au niveau des tests ?
En agile à l’échelle tout est plus décentralisé.
En général, ce que j’observe c’est des équipes agiles qui disent bien « tout » tester et des équipes de test bout en bout qui « préfèrent tout retester par précaution ».
Cela peut engendre du « sur-test » avec des tests exécutés à plusieurs niveaux alors qu’un seul aurait suffit. Vous noterez que je ne parle pas de sur-qualité car sur-test n’est pas forcément lié à sur-qualité!
Mon expérience terrain est celle-ci:
- Les équipes agiles n’ont pas toujours les compétences suffisantes en test ce qui engendre parfois un manque de qualité et régulièrement un manque d’industrialisation et de traçabilité/
- un niveau de qualité hétérogène entre les équipes (la stratégie de test agile aide aussi à homogénéiser ce niveau de qualité)
- une équipe bout en bout qui est souvent ciblée comme responsable s’il y a des bugs en production… Et qui préfère se couvrir en « testant plus »
Afin de savoir que les tests de bout en bout test ce qu’il y a à tester il faut:
- une communication régulière entre les équipes agiles et les personnes responsable du test de bout en bout
- un partage et une traçabilité des tests qui va dans les 2 sens (les équipes connaissent les tests bout en bout et le bout en bout sait ce qui a été testé dans les équipes)
3 – Sur quelle base concevoir mes tests (épiques, user storys, expression de besoin, scénarios ATDD…) ?
C’est un sujet épineux… d’autant plus pour des organisations qui sont en transformation agile.
Sur le papier, les tests bout en bout devrait pouvoir utiliser les « épiques » qui font office de macro fonctionnalités pouvant impacter plusieurs équipes agiles.
Dans les faits, ces épiques ne sont pas toujours des fonctionnalités transverses… Voir même pas toujours des fonctionnalités… Ou encore simplement des coquilles vides.
La vision globale du produit est quelque chose qui manque souvent.
Les personnes en charge des tests de bout en bout se retrouvent à se baser sur des user storys… Qui sont souvent à un niveau trop élémentaires… Quand elles sont bien écrites et INVEST car, malheureusement, en phase de transformation les user storys peuvent vitre être des tickets de conception, de développement ou de test.
Lorsque ni les équipes ni les storys ne sont suffisantes il est possible de revenir au « besoin initial ». Mais cela veut dire partir d’un besoin pour imaginer des scénarios… Ce qui peut vite amener à viser à côté.
Une autre solution est la mise en place d’ateliers pour concevoir des scénarios. Un peu sous la forme d’un ATDD (un BDD mais pour un besoin ou une épique) qui pourrait alors servir de base pour les tests bout en bout.
4 – Combien de temps dédier aux tests de bout en bout ? Que font les équipes pendant ce temps ?
Voici un sujet épineux!
Lorsque l’on pense tests bout en bout, on pense à des tests en fin de développement avant une release. Cette phase, surtout pour les produits complexes, peut durer très longtemps en cycle en V.
Cette durée est en général incompatible avec l’agile.
J’observe régulièrement dans les organisations en transformation des phases de bout en bout à durée variable. Elle sont faites en parallèle des itérations des équipes agiles. Ces phases de tests sont faites sur des livraisons antérieures des équipes qui doivent alors « réserver » une partie de leur vélocité pour la correction de bugs trouvés pendant la campagne de bout en bout.
Cette organisation ne fonctionne, en général, pas trop mal mais elle oblige beaucoup d’estimations et peuvent impacter les équipes agiles en fonction de ce qui est détecté.
En fonction des bugs trouvés on peut aussi se retrouver à devoir décaler toute la release!
Une autre organisation, plus agile, est de réussir à intégrer les tests bout en bout (ou au moins une partie de ces tests) dans les Definition of done des équipes agiles en mettant à disposition un environnement partagé entre les équipes et des tests bout en bout automatiques permettant d’identifier de grosses régressions rapidement. Cela nécessite alors beaucoup de communication et d’organisation.
Le partage de tests bout en bout aux équipes agiles est également un plus.
5 – Qui exécute les tests bout en bout ?
Ici il y a 2 écoles.
Dans les organisations en transformation celle privilégiée est une équipe dédiée. Cette solution a fait ses preuves et reste une valeur sûre pour atteindre un niveau de qualité satisfaisant.
L’autre école est de laisser les équipes agiles gérer totalement le bout en bout. Je pense que cela fonctionne bien sur des « petits » produits où il y a entre 3 et 5 équipes. Au delà, l’effort de synchronisation me semble vraiment important.
D’un point de vue personnel j’aime l’idée d’avoir une équipe restreinte totalement dédiée au bout en bout qui est renforcée ponctuellement par des acteurs des différentes équipes. Il est important pour moi de donner du sens au travail des équipes. Ce sens peut vite se perdre lorsque l’on ne travaille que sur un bout de produit. Les tests bout en bout permettent de redonner ce sens… tout en comprenant mieux le produit et le travail (ainsi que les contraintes) des autres équipes.
6 – Quand fait-on les tests bout en bout ?
Je pense que les points 4 et 5 ont répondu à cette question.
La réponse évidente est aussi tôt que possible.
Dans les faits il faut les faire avant les release… Et si possible en intégrer une aussi grosse partie que possible lors des itérations.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
