A quoi sert d’avoir un testeur agile en scrum ou en agile ? Comment va-t-il intégrer ce rôle qui n’est pas un rôle clé du « scrum guide » ? Nous allons focaliser cet article sur ces testeurs agiles qui apportent beaucoup aux équipes scrum et agiles.
Nous avions traité le sujet en vidéo sur La Minute Agile, n’hésitez pas à la regarder.
Le testeur en agile
Dans une équipe scrum, nous parlons de 3 rôles clés :
Bien que le test soit recommandé et est souvent un rôle pris par défaut par le product owner (si on ne parle que de tests classiques), rajouter un testeur (aussi appelé QA ou homologateur) comme 4ème rôle clé va apporter des compétences complémentaires pour maximiser la qualité finale du produit. Cependant si nous parlons de « test », cet expert apporte beaucoup plus à une équipe que juste le fait de faire des tests ; le testeur n’est pas qu’un simple pisseur de tests.
Le testeur en scrum peut avoir comme tâches principales :
- écrire les tests en amont des développements
- valider les tests (et comportements) avant la validation finale de la user-storie
- s’assurer que la Definition of Done est bien respectée par l’équipe de réalisation
- renforcer l’aspect user-centric en amenant l’équipe à plus travailler avec les utilisateurs
Le rôle des testeurs peuvent différer légèrement selon les contextes. Cet article fait un état des lieus des tâches qui sont souvent attribués à ces experts. A vos équipes de définir les tâches que prendra en charge le testeur.
Il va donc en général intervenir à deux niveaux différents de maturité des demandes dans les cas les plus généraux.
Le testeur agile peut aider le product owner dans l’écriture des user-stories sur la partie test si l’équipe fonctionne par exemple en BDD (Behavior Driven Development). Il aura la lourde tâche d’écrire des tests qui correspondent au mieux à la vision des utilisateurs.
Dans le cas idéal de la mise en place de cette pratique, il pourra même écrire ces tests directement avec les utilisateurs pour s’assurer que le résultat attendu est 100% celui attendu par les utilisateurs. Il apporte beaucoup à cet aspect user-centric très important en agilité. Il saura d’ailleurs faire la distinction entre les envies personnelles d’un utilisateur et les véritables besoins de l’ensemble des utilisateurs ; cela lui imposera d’explorer certains sujets plus en profondeur.
Certaines équipes vont même bénéficier du testeur agile pour mettre en place une cérémonie de maturation de user-stories très intéressante : Les 3 amigos en agile.
En général quand le testeur agile fait parti de cette équipe agile, cela permet de compléter le rôle du product owner avec des compétences fortes autour du test et de l’aspect user-centric. Le fait d’avoir ces deux rôles dans une équipe agile permet d’avoir un meilleur travail global sur l’affinage du backlog ; et donc d’avoir une meilleure fluidité dans les développements et une meilleure qualité sur le produit.
Son travail sera essentiel car un product owner n’a pas forcément cette affinité du test et n’aura pas forcément le temps de monter en maturité sur les compétences attendues pour un testeur de qualité.
Il peut participer au Product Backlog Refinement
L’affinage des user-stories est essentiel dans la qualité du produit. Un bon affinage assurera une meilleure qualité finale du produit. Le testeur pourra profiter de cette séance d’affinage pour s’assurer que les attendus des utilisateurs sont bien compris et que les tests soient clairs pour l’ensemble de l’équipe.
Il participe aux estimations ?
Quand les tests d’acceptances ne sont pas automatisés, il va souvent réaliser les tests définis précédemment. Dans certains contextes où les socles techniques sont anciens, où la maturité de test n’est pas encore présente, les tests peuvent demander plus ou moins d’effort.
Dans ce type de contexte, je recommande vivement de faire participer le testeur aux estimations des user-stories pour indiquer si il est nécessaire ou non d’augmenter les points d’effort car les tests en exigeront.
Donc oui, si nécessaire, le testeur pourra participer aux séances d’estimation des user-stories.
Le testeur agile, un atout majeur pour l’équipe
Le testeur dans une équipe agile peut apporter énormément à l’équipe et n’est pas un investissement perdu. Il permettra potentiellement :
- d’assurer une meilleure qualité du produit
- de compléter les compétences du product owner
- d’amener des compétences complémentaires souvent sous-estimées de testeur
- de driver les développements par le test
Ne pas prendre de testeur parce que nous pensons qu’il coûte cher et que son rôle peut-être pris par un autre membre de l’équipe… C’est comme donner le rôle de scrum master à un développeur qui ne passera au mieux que 10% de son temps en temps que scrum master. Ce sont de fausses économies qui vont directement impacter la qualité finale des increments réalisés.
Il faut bien comprendre que le testeur n’est pas qu’une personne qui « écrit » des tests mais qu’il peut apporter beaucoup plus à l’équipe et au produit lui même.
est ce que le testeur est la meme chose que le QA ?
Oui le terme de QA peut-être également utilisé.
Bonjour,
merci pour votre vidéo. Je suis étonnée par cette « super position » du testeur qui efface ou déborde sur la partie du scrum master. J’espère que vous pourrez répondre à mes questions même si la publication commence à dater un peu.
Vous parlez d’intégrer le QA au sein de l’équipe de développement, mais en soi il ne produit rien d’un point de vue fonctionnalité.
Intégrer un QA dans une équipe de dev ça veut dire considérer que le QA fait partie intégrante de l’équipe et impacte sa vélocité.
Comment peut on intégrer un QA dans les chiffrages d’une équipe qui produit du code avec quelqu’un qui n’a pas de compétence de développement et qui ne produira pas de nouvelle fonctionnalité?
Personne ne pourra le challenger sur son chiffrage, jamais il ne pourra améliorer sa propre vélocité si elle est séparée des devs et s’il doit monter en compétence au sein de l’équipe, ça veut dire que l’équipe doit diminuer sa vélocité?
S’il n’est pas là, est ce que ça sous-entend que les devs vont le remplacer pendant ses vacances?
ça serait vraiment bien d’avoir le détail de la mise en place d’une telle personne au sein de l’équipe.
Je vous remercie pour votre retour
En scrum, un QA est un developer. Developer (anciennement équipe de développement) signifient toute personne qui participe à la réalisation. Ce n’est pas dans le sens « programmeur ».
Le QA participe au chiffrage car le chiffrage ne contient pas que « la programmation ». Le test selon les contextes prend plus ou moins d’effort. Il ne faut surtout pas faire une vélocité par corp de métier, cela amènerait à es calculs chronophages pour des résultats pas plus juste.
Oui, si un membre de l’équipe est absent peu importe la raison, cela ne doit pas empêcher la chaine de production de continuer d’avancer. La technique qu’un membre qui n’est pas un expert mais capable de remplacer un autre en cas d’absence est une technique acceptable ; cela implique évidemment que cette autre personne ait été un minimum formé.
Je t’en prie 🙂