Les 12 principes du testeur Agile

Après ma proposition de « Manifeste du testeur« , je vous propose une autre analogie avec l’agilité avec les 12 principes du testeur agile. Attention, l’idée ici n’est pas de remettre en cause les 7 principes du test, qui sont et resteront, mais bien de proposer 12 principes auxquels les testeurs dans les environnements doivent adhérer afin de s’adapter à ces nouvelles méthodologies.

Tout comme pour l’agilité, il n’y a pas de hiérarchie dans les principes proposés.

1. Tester ensemble

   Un testeur agile peut se retrouver seul « testeur » dans son équipe. Néanmoins il est inconcevable de ne laisser qu’une personne s’occuper des tests. Les « testeurs » c’est, au minimum, l’ensemble des membres de l’équipe. Idéalement on peut inclure des utilisateurs (phase de bêta test) ou des représentants métier. Plus de personnes différentes testent plus la vision d’ensemble sur la qualité du produit est bonne.
   
   

2. Limiter le nombre de tests

   Les méthodes agiles sont des méthodes incrémentales. A force d’ajouter des tests sans en enlever on a des campagnes qui deviennent chronophage (à l’exécution, l’analyse et la maintenance), difficilement maintenable et donc fatalement ignorées! Afin d’avoir de bonnes campagne il faut donc trier ses tests, c’est à dire supprimer régulièrement une partie des tests de régression afin de limiter leur nombre. La manière la plus efficace pour diminuer le temps passé sur ses tests c’est de diminuer son nombre de test. Supprimer des tests de ses campagnes engendre évidemment un travail important consistant à bien sélectionner les tests conservés.
   
   

3. Connaitre le produit

   Un testeur agile c’est avant tout un membre d’une équipe agile. Il travaille donc sur un produit (et non sur un projet avec du travail sur des spécifications exhaustives en amont). La connaissance de ce produit est primordial afin de bien connaitre ses possibilités, ses failles potentielles et son utilisation. Il n’y a pas de stratégie de test correcte sans connaissance du produit.
   
   

4. Connaitre les utilisateurs

   Un testeur agile doit, avec son équipe, délivre de la valeur… pour les clients. Pour cela il doit savoir comment le produit est utilisé par les clients, quelles sont les fonctionnalités qu’ils souhaitent et comment ils veulent utiliser ces fonctionnalités. Le représentant du client (le PO ou Product Owner en Scrum) priorise les besoins en fonction de la valeurs, il est néanmoins vital de savoir comment la fonctionnalité sera utilisée pour adopter une stratégie de test pertinente.
   
   

5. Automatiser

   Qui dit agilité dit méthode de développement incrémentale. Qui dit méthode de développement incrémental dit tests de régression fréquents. Qui dit exécution fréquente de test dit automatisation des tests! Qui est capable d’exécuter tous les jours la même campagne de test pendant des mois? Personnellement je ne connais personne qui le soit et même si c’était le cas je déplorerai le temps perdu et devrait également dire adieu au déploiement continu.
   
   

6. Faire des mesures en production

   Un testeur agile travaille au développement d’un produit. Ce produit est utilisé par des clients qui attendent régulièrement de nouvelles fonctionnalités et la corrections de diverses anomalies. Il devient alors vital pour le testeur d’avoir accès à diverses mesures en production. Ces mesures ont pour but de:
   1. comprendre le comportement des utilisateurs. Comment le produit est utilisé. Les utilisateurs trouvent-ils ce qu’ils cherchent?
   2. détecter des anomalies.
   3. connaitre les pics de charge
      
      

7. Aider son équipe

   Cela peut sembler évident mais c’est toujours bon de la rappeler. Le testeur agile est dans une équipe agile. Il lui arrive de devoir demander de l’aide à des membres de l’équipe pour des tâches de test. Il est donc amener à faire de même. Dans une équipe agile, tout le monde est dans le même bateau. Chaque membre de l’équipe se doit de faire ce pour quoi il est le plus utile à l’équipe à l’instant t. Un testeur agile se retrouvera donc essentiellement à faire des tâches de test mais pourra être amené à travailler sur des tâches de développement ou d’écriture de documentation.
   
   

8. Prioriser

   La priorisation est un des fondements de l’agilité et un des piliers du test. Lorsque l’on teste il faut savoir quoi tester en premier. Il est également bon de savoir ce qu’il est obligatoire de tester et ce qui ne l’est pas. Cela permet d’adapter sa campagne et donc de gagner du temps en perdant un minimum de visibilité sur la qualité.
   1. On peut par exemple avoir 3 niveaux de priorité dans ses tests de régression (P1, P2 et P3) chaque test étant relié à une « épique ».
   2. Les P1 sont toujours exécutés (même lors de l’intégration continue).
   3. Par défaut on peut considérer qu’avant une mise en production on exécute les P1, P2.
   4. Lors de la mise en service d’une fonctionnalité on peut définir un niveau de risque associé aux diverses « épiques ».
      1. Imaginons une application mail avec les épiques « envoi de mail », « gestion des dossiers », « lecture de mails », « gestion des options », « connexion ». Lors de l’ajout d’une fonctionnalité envoie de pièces jointes on peut imaginer que les principales chances de régression sont sur l’épique « envoi de mail ». De même la « lecture de mails » peut également être impactée lorsque l’on va dans les mails envoyés. Par contre, les autres épiques ont peu de chances d’être impactées. On peut donc décider, pour la campagne de régression d’exécuter les P1, P2 et P3 pour l’épique « envoi de mail », P1 et P2 pour la partie « lecture des mails » et uniquement P1 pour les autres épiques. On a alors une campagne avec des efforts de test mieux cibler grâce à la priorisation.
         
         

9. Adapter sa stratégie au contexte

   Les tests dépendent toujours du contexte. Le testeur agile doit donc, de préférence pour chaque User Story, construire avec les membres de l’équipe de développement un plan de test permettant de mettre en place une stratégie spécifique à cette fonctionnalité afin d’être le plus efficace possible par rapport au contexte. L’exemple du point précédent est un exemple d’adaptation au contexte. Il existe néanmoins de nombreux autres contextes que les simples contexte fonctionnels. On peut notamment penser à un contexte de sortie obligatoire avant les fêtes de fin d’année ou des contexte d’image de la société qui préfère avoir une très bonne qualité, un contexte lié aux utilisateurs, la concurrence ou encore des contextes non fonctionnels (comme les performances, la fiabilité ou la sécurité…).
   
   

10. Briser les silos

    Briser les silos est avant tout un objectif de la philosophie DevOps. Cela reste néanmoins primordial que l’on adopte une approche DevOps ou non. Un testeur agile, membre d’une équipe agile, se doit de comprendre les besoins des membres de son équipe, des utilisateurs et des représentants métiers. Pour cela il doit discuter avec eux, échanger, connaitre leurs problématiques. Afin de briser ces silos de nombreux outils ont vu le jour, je pense notamment aux approches telles que le BDD ou l’ATDD qui ont pour but de fusionner spécifications et tests. Cette fusion permet de supprimer un silo et donc une barrière d’incompréhension. Les revues sont également des moyens très efficaces pour briser les silos et améliorer les processus de qualité (en détectant plus tôt les anomalies).
    
    

11. Faire du test exploratoire

    Les tests exploratoires sont souvent mal vus. Néanmoins lorsqu’ils sont bien mis en place, et en complément d’autres tests, ces tests s’avèrent particulièrement efficaces. Une utilisation efficace des tests exploratoires se fait grâce à un plan de test bien définis. A l’aide du plan de test et du travail du testeur on identifie les futurs tests de régression (qui seront ré-exécutés) et on peut donc travailler à les automatiser directement. Les tests exploratoires peuvent être utilisés en complément. Toujours d’après le plan de test, des risques ont été identifiés. Il est alors possible de prévoir des sessions de tests exploratoires (au moyen des chartes de test) afin de couvrir certains de ces risques. A noter: afin d’avoir des tests exploratoires efficaces il faut avoir des testeurs qui connaissent bien le produit et qui sont un minimum expérimentés.
    
    

12. Inculquer l’esprit de la qualité

    On peut ici parler de « Coach Agile ». Le testeur n’est pas responsable de la qualité du produit. Néanmoins, de par sa spécialité de testeur, il doit permettre à tous les membres de l’équipe de monter en compétence sur ces concepts. Il doit assurer que la qualité minimales souhaitée est atteinte mais aussi permettre à l’équipe de ne pas faire de sur-qualité. Pour cela il doit convaincre les membres de l’équipe de l’utilité des processus mis en place, de leur efficacité et de la plus-value apportés par ces derniers car oui, à moyen terme les tests permettent d’économiser beaucoup d’argent.

Vous venez donc de lire les 12 principes du testeur agile que je propose avec leurs explications. J’aurai pu également mettre l’adaptation au changement mais ce principe reste sous-entendu avec les principes énoncés et il se rapproche très fortement d’un des principes de l’agile « accepter le changement du besoin ». J’ai également eu de nombreuses autres idées mais l’exercice est justement de savoir prioriser et ne prendre que les plus importants, exactement comme pour la priorisation des tests!

Je vous invite néanmoins à faire vos propositions en commentaire notamment si vous pensez que j’ai oublié des aspects importants.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

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

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.