Livre CFTL – Le rôle des testeurs dans les projets/équipes agiles

Avec l’agilité, le cycle de développement est bouleversé. Le logiciel n’est plus livré en une fois mais en de multiples versions embarquant chacune une ou plusieurs nouvelles fonctionnalités. Les tests se font donc à tout moment du projet, il n’y a plus de « période » spécifique dédiée aux tests ou à certains types de tests.

Nous étudierons dans ce chapitre les changements apportés par l’agilité pour les tests notamment en s’attachant au fait que l’agilité regroupe un ensemble de méthode qui ont toutes quelques points communs éloignés d’un cycle en V traditionnel comme :

• La construction d’un logiciel orientée sur la valeur produit
• La construction itérative d’un logiciel
• La mise en relation, au sein d’une même équipe, de plusieurs « métiers » différents

Nous aborderons ensuite les impacts de ces changements dans le travail de testeur en étudiant les nouveaux rôles des testeurs en agilité. Ces rôles sont :

• Garant de l’esprit de la qualité logicielle
• « Chef de projet test »
• Apporter son aide là où il est le plus utile à l’équipe même si ce n’est pas du test

Les spécificités d’un développement avec une méthodologie Agile

La construction d’un logiciel orientée sur la valeur produit

Par construction d’un logiciel orienté sur la valeur produit il faut comprendre que toute la construction du logiciel est basée sur ce que la fonctionnalité ajoutée peut apporter.

Le produit est donc :

• Un produit/logiciel est une agglomération de fonctionnalités… Ces fonctionnalités pouvant évoluer, changer au cours de la vie du projet.

Le produit est développé par fonctionnalité. Chaque fonctionnalité est une « brique » qui s’ajoute au produit déjà existant. L’accumulation de ces briques forme un ensemble qui est le produit. Ce produit évolue et voit son nombre de briques augmenter tout au long de son développement.

On a donc un produit qui grandit ce qui peut se résumer avec les images ci-dessous :

• Un produit/logiciel est construit en fonction des retours clients

Un produit n’est pas totalement défini à l’avance avec les méthodes agiles. Pire, des fonctionnalités prévues comme importantes à un moment peuvent ne jamais voir le jour alors que d’autres auxquelles personne n’avait pensé au début du projet s’avèrent être essentielles.

Il n’est pas rare d’avoir une différence entre ce à quoi l’on pensait et ce qui sera finalement développé.

Par exemple, entre 2 itérations il est possible d’ajouter une fonctionnalité ou alors

Ce type de projet débouche généralement à une grande différence entre le produit initialement pensé et le produit finalement conçu.

Les raisons de ces différences peuvent être multiples. Il y a par exemple la modification des besoins car il y a eu modification de l’environnement ou encore des demandes, utilisations ou retours des utilisateurs importants sur certaines fonctionnalités.

Un des points forts de l’agilité est justement de pouvoir évoluer plus facilement que le cycle en V, particulièrement si l’on ne sait pas exactement ce qui est attendu, souhaité ou même apprécié.

• Présenté/Utilisé par des clients faisant des retours qui impactent la suite de son développement

En agilité on n’attend pas que l’ensemble des développements soient finis pour permettre aux utilisateurs finaux de travailler ou utiliser le logiciel. Une bonne pratique est de définir un « produit minimal » regroupant une partie des principales fonctionnalités. Ce « produit minimal » est alors considéré comme le produit utilisable regroupant le moins de fonctionnalités… Et donc la première version du produit utilisable par des clients.

Donner accès à cette version permet d’avoir rapidement des retours par rapport à l’accueil du produit, son utilisation et les demandes d’évolutions.

Les clients/utilisateurs agissent donc directement sur le produit et ses évolutions.

Certaines méthodes agiles proposent même des présentations du produit avant la finalisation de « produit minimal ». C’est le cas de la méthode agile la plus connue qui est la méthode Scrum. Dans ce cas, le produit est régulièrement présenté ce qui permet d’avoir des retours des futurs utilisateurs au plus tôt, de savoir très tôt si le produit correspond effectivement au besoin ou s’il faut modifier certaines fonctionnalités ou même orienter les développements dans une direction différente.

La construction itérative d’un logiciel

La construction d’un logiciel dans les méthodes agiles est itérative. En agilité on pense plus en terme de produit que de projet ce qui conduit à avoir :

• Un produit utilisable le plus tôt possible
• Un produit qui évolue régulièrement avec des versions fonctionnelles fréquentes.

Le logiciel est construit brique par brique, les briques sont les fonctionnalités du produit qui apportent de la valeur à ce dernier.

Chaque itération peut regrouper entre 1 et plusieurs fonctionnalités, ces itérations pouvant être plus ou moins longues.

La durée des itérations varie énormément selon les méthodes agiles et les outils disponibles sur le projet. Cela peut varier de 1 itération avec plusieurs fonctionnalités toutes les 2 à 4 semaines (méthode Scrum) à 1 itération à intervalles irréguliers car itéré dès qu’une fonctionnalité est prête à être déployée. Ces intervalles peuvent être inférieurs à la minute grâce à l’utilisation d’outils permettant le déploiement continu.

Dans tous les cas, chaque itération a pour livrable un produit utilisable. Attention, « utilisable » ne veut pas forcément dire mis en production. Utilisable veut dire que les fonctionnalités développées depuis le début du projet sont bien implémentées et se comportent comme prévu.

Le principe de l’agilité est de permettre à l’équipe d’être réactif par rapport aux retours des utilisateurs. Dès lors il est impossible de tout prévoir des mois à l’avance. Le produit est ajusté en fonction des retours afin qu’il corresponde le plus possible aux souhaits des utilisateurs.

La mise en relation, au sein d’une même équipe, de plusieurs « métiers » différents.

Cette différence de répartition traduit un changement majeur dans la manière de penser entre les projets agiles et les projets en cycle en V. La de philosophie de travail des membres de l’équipe s’en trouve totalement changée.

Le testeur, le développeur, l’analyste métier (et parfois l’exploitant) ne sont plus au sein d’une équipe composée uniquement de personnes faisant le même métier qu’eux mais au sein d’une équipe pluridisciplinaire et entouré d’au moins des développeurs et d’analystes métiers.

Dès lors les membres de l’équipe doivent apprendre à travailler ensemble et à communiquer de manière encore plus étroite. Ils se retrouvent devoir/pouvoir mieux échanger et sont amenés à tester tôt, présenter régulièrement leur travail. Ils apportent nécessairement leurs expertises respectives mais doivent aussi exécuter des tâches autres que leurs tâches de prédilection. Le développeur pouvant se retrouver à faire des tâches de test, le testeur du développement ou des spécifications…

« L’équipe agile » forme une entité à part entière qui est responsable d’un produit (ou d’une part d’un produit). La responsabilité est commune, la réussite également. Travailler dans une équipe pluridisciplinaire encourage la collaboration entre les membres de l’équipe, permet de bien faire comprendre le rôle des différentes phases du projet tout en cassant les silos, les frontières entre les différentes « phases » d’un projet (spécifications, développement, test… Et exploitation).

Le rôle des testeurs dans les équipes/projets agiles

• Le testeur fait partie de l’équipe il participe donc à toutes les cérémonies

Un testeur dans une équipe agile est avant tout un membre de l’équipe. Cela signifie qu’il doit participer à toutes les cérémonies, toutes les réunions d’équipes.

Dans la méthode Scrum cela revient à participer aux 4 cérémonies principales :

Les daily meeting où le testeur présente ce qu’il a fait la veille, sur quoi il va travailler le jour même et indique s’il est bloqué sur un point

Les Planning poker dans lesquels son expertise et sa connaissance des tests est particulièrement importante afin d’estimer le coût d’une User Story et plus particulièrement les tests relatifs à cette dernière

Les product backlog afin de déterminer, avec l’équipe, quelles seront les fonctionnalités à développer dans le sprint à venir.

Les rétrospectives afin d’apporter son point de vue sur le sprint qui vient de se finir, identifier de possibles défauts ou encore proposer des améliorations des processus afin d’améliorer la qualité si cette dernière est problématique, diminuer le coût de la qualité, améliorer le temps nécessaire aux tests ou toute autre proposition. Le testeur est, dans cette réunion, la personne la mieux placer pour proposer des solutions aux problèmes de qualités détectés sur le produit.

• Le testeur agile peut être amené à faire autre chose que du test, l’important est de faire ce pour quoi il est le plus utile à l’équipe à l’instant t

Comme dit précédemment, le testeur dans une équipe agile est avant tout un membre de l’équipe agile.

Le testeur, comme tout autre membre, doit faire de son mieux afin que le produit soit de la qualité souhaitée, contiennent les fonctionnalités demandées, que les engagements de l’équipe soient respectés…

Dans cette optique le testeur doit faire de son mieux pour le produit, pour l’équipe. Il doit faire ce pour quoi il est le plus utile à l’équipe à l’instant t… Et ce pour quoi il est le plus utile à l’équipe n’est pas forcément du test. Les raisons peuvent être diverses comme l’obligation du retard de l’équipe sur de la documentation, du retard sur le développement ou même de l’avance sur les activités de tests. Dans ce cas le testeur peut être amené à développer, écrire de la documentation ou toute autre chose tant que cela est utile à l’équipe. On parle d’ailleurs souvent de compétences en « T » pour les membres d’une équipe agile. Le « T » signifie que le membre de l’équipe agile a une expertise (la barre du « T ») mais aussi des connaissances de base sur d’autres sujets.

• Equipe responsable de la qualité mais testeur oriente l’équipe afin d’assurer que cette dernière fait attention à la qualité, adopte et utilise des bonnes pratiques, des processus adaptés

Dans les équipes agiles il n’y a pas de responsabilité individuelle mais une responsabilité collective. S’il y a un problème c’est la faute de l’équipe, si tout va bien c’est également grâce à l’équipe… Le testeur agile n’est donc pas responsable de la qualité de l’application, c’est l’équipe qui l’est.

Néanmoins, s’il y a un (ou plusieurs) testeurs dans une équipe agile c’est justement pour assurer l’atteinte de la juste qualité sur le produit. Le testeur, bien que non responsable de la qualité à un grand rôle à jouer par rapport à cette dernière !

Le rôle du testeur va être d’apporter son expertise des tests, de l’évaluation et de communication autour de la qualité. En cela le testeur agile aura pour rôle la responsabilité d’insuffler à l’équipe le bon état d’esprit sur la qualité afin d’éviter des comportements engendrant une qualité trop mauvaise ou même de la sur-qualité.

En cela le testeur agile sera là pour assurer que l’équipe adopte de bonnes pratiques mais aussi des processus adaptés à l’équipe… Ces processus ne seront pas forcément ceux auxquels il avait pensé initialement. En effet, ces processus et même les bonnes pratiques adoptées pourront évoluer au fur et à mesure de l’expérience de l’équipe afin qu’ils soient de mieux en mieux adaptés à l’équipe.

• Le testeur agile a également une casquette proche de cette de chef de projet test

Une équipe agile est autogérée. L’autogestion ne signifie pas la non gestion. Dans ce cadre, le testeur agile est amené à prendre certaines responsabilités qui étaient habituellement réservées au chef de projet test. Ces responsabilités sont par exemple :

Estimer les coûts des tests pour chaque User Story en apportant notamment sa vision sur l’effort de test nécessaire pour ces dernières lors du planning poker

Gérer une équipe de test en considérant que l’équipe de test est en fait l’équipe agile. Ce parallèle est logique lorsque l’on convient que c’est bien l’équipe agile qui est responsable de la qualité du projet.

Implémenter et travailler sur la stratégie de test en collaboration avec les autres membres de l’équipe

Coordonner les activités de test. Un testeur agile ne fait pas forcément que du test, ce n’est également pas forcément lui qui s’occupe de tous les tests. Il sera souvent épaulé par d’autres membres de l’équipe. Un développeur peut par exemple être très efficace dans l’automatisation des tests. Le testeur agile restera néanmoins la personne ayant la meilleure visibilité sur les tests

Contribuer à améliorer les processus de test, avec par exemple la mise en place des processus d’automatisation des tests. La cérémonie la plus adaptée à ces améliorations est la rétrospective. Dans ce cadre le testeur est le plus à même, par sa connaissance du métier du test, à proposer des améliorations efficaces des processus. Ses propositions sont alors très importantes… Il ne faut cependant pas négliger les propositions des autres membres de l’équipe, membres qui sont tout autant responsables de la qualité du produit que le testeur agile car membre de l’équipe.

Evaluer la qualité du produit en travaillant en collaboration sur les tests de validation et les critères d’acceptation et en délivrant des bilans de qualité et répondant aux besoins des différents lecteurs de ces derniers.

Participer au projet depuis l’étude préalable jusqu’à la mise en œuvre des applications en intervenant dès la présentation des User Storys par le PO.

• Le testeur agile, peut faire partie d’une tribu afin de partager avec les testeurs d’autres équipes ses expériences et homogénéiser les pratiques

Être un testeur agile ne veut pas dire être « seul testeur » au monde au milieu de non-testeurs. Non, il est tout à fait possible dans des organisations agiles de créer des « tributs » ou de garder des équipes par métier. Si cela est le cas, le testeur agile est alors membre de 2 équipes. La première reste l’équipe agile dans laquelle il passe la grande majorité de son temps, la seconde est l’équipe (ou la tribu) des testeurs.

Cette tribu de testeur regroupe les testeurs de l’entreprise (ou du projet…) afin que ces derniers puissent échanger. Le rôle de ces tribus peut aussi être de mettre en place des outils et méthodes communes.

Les tribus ont beaucoup d’avantages comme :

Elles peuvent permettre une adaptation plus aisée des testeurs lorsqu’ils arrivent dans une nouvelle équipe agile (avec des outils communs).

Elles permettent les échanges et donc de proposer des conseils pour des testeurs en difficultés sur certains processus

Elles permettent l’existence d’une communauté de test et d’une émulation sur ce point.

Il faut néanmoins faire attention que les tribus n’impactent pas trop les équipes agiles au point de ne plus laisser les équipes libres de s’auto-organiser ou de nécessiter trop de temps au détriment du temps passé par le testeur agile dans son équipe agile. On arrive alors à devoir trouver un juste équilibre entre les équipes agiles et l’importance d’avoir une communauté de testeur.

Conclusion :

Les projets en mode agile nécessitent un changement d’état d’esprit pour l’ensemble des personnes impactées par ces projets (analystes métiers, développeurs, testeurs, exploitants, RH, management…). Dans les projets agiles il faut penser différemment, savoir que les changements peuvent être fréquents mais permettent également d’améliorer le produit…

Afin de s’adapter à ces changements, le testeur doit également évoluer. Finit la simple casquette de testeur au sein d’une équipe de testeur avec un travail définit à l’avance sur une phase du projet. Le testeur agile intervient tout au long du projet, se retrouve à collaborer dans une équipe pluridisciplinaire et à tester un produit dont personne ne peut dire exactement à l’avance quel sera le produit final.

Le testeur agile, pour s’adapter, gagne donc en autonomie, en responsabilité, en capacité de communication. Par contre, ce même testeur se retrouve « moins spécialisé » car il lui arrive de devoir faire autre chose que du test et donc de s’intéresser encore plus aux autres métiers indispensables au développement des logiciels.

Pour conclure le testeur agile, plus qu’un testeur dans une équipe agile, peut être vu comme un « coach du test » ou « Coach qualité » au sein de l’équipe dans laquelle il travaille.

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

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.