Les conférences NCrafts ont été marquées cette année par des présentations moins orientées vers la pratique et plus vers l’esprit Craftsmanship lui-même. L’une de ces présentations concernait le sujet du « Mob Testing » par Maaret Pyhäjärvi, informaticienne spécialisée dans le test depuis 10 ans, qui travaille chez Granlund Oy, et Altom Consulting Oy en tant que consultante.
Le but de ce billet est de présenter brièvement ce style de travail.
Mob Testing : Kézako ? Principes ?
Le rôle de testeur (QA, testeur…) nécessite beaucoup de connaissances implicites, souvent acquises sur une longue période de temps au fil de nombreuses expériences. Les testeurs eux-mêmes ont parfois des difficultés à expliquer le fonctionnement de leur méthode, par exemple ils pourront avoir du mal à décrire simplement comment réaliser un test exploratoire dans l’intention de trouver des informations utiles pour les utilisateurs.
L’idée du Mob Testing est notamment de s’attaquer à un problème en profitant des perspectives différentes de chaque personne du groupe, ce qui permet d’une part d’atténuer le biais induit par chaque individu face à un problème, et d’autre part d’éviter les difficultés de concentration qu’une personne seule peut rencontrer au cours du traitement d’une tâche exploratoire.
L’autre mécanisme mis en avant par le Mob Testing est de mixer les équipes avec des profils divers (métiers, techniques, juniors, seniors, etc) afin que des testeurs/développeurs chevronnés puissent bénéficier de la vision de nouveaux utilisateurs sur la manière d’utiliser l’application, ce qui les aide à déterminer plus facilement ce qui est améliorable.
Vous avez surement déjà vécu une situation où une équipe entière s’est réunie autour d’un problème et a pu le résoudre efficacement en travaillant ensemble. Une fois le problème résolu, la plupart des équipes disent « ok ce problème est réglé, reprenons comme d’habitude ». Ici, il s’agît plutôt de dire « Nous avons été très performants ensemble, comment faire cela plus souvent ? ».
Évidemment un travail en groupe de ce genre ne peut fonctionner que si l’ensemble du process se fait dans une attitude constructive de considération et de respect envers l’autre, afin que tous les membres du groupe puissent s’exprimer sans peur.
Rôles
Dans une session de Mob Testing, on distribue les rôles suivants :
- un conducteur (la personne sur l’ordinateur), c’est le « scribe ». Le conducteur n’est pas supposé intervenir durant les échanges. - un navigateur, il écoute les idées du groupe, et prend la décision finale de l’action à faire. - un facilitateur, il est là pour s’assurer que tout le process du Mob Testing se déroule bien :
timing de la rotation des personnes en tant que conducteur, conducteur devenant navigateur)…
Interrompre une discussion pour émettre de nouvelles idées ….
Aider le navigateur et le conducteur en surveillant que les échanges se font dans un cadre respectueux pour tous les intervenants.
- le reste de l’équipe
Rotation
Une session de travail de Mob Testing se fait par « tour », une rotation est faite à chaque tour entre l’ensemble des participants. Chaque personne se décale d’une place, la personne à côté du conducteur devient conducteur, le conducteur devient navigateur, et le navigateur redevient un simple participant. Seul le facilitateur ne change pas de rôle.
Petit outil indispensable : un chronomètre bien audible (mais plaisant) pour sonner la fin du tour.
Organisation
L’écran doit être facilement visible par tous, les chaises tournées vers lui, et l’espace suffisant pour que les membres du mob puissent se lever régulièrement et bouger selon le sens de rotation.
Une session ne doit pas durer plus de 2h, en tout cas sur les premières sessions de Mob Testing d’un groupe, et ne pas dépasser le temps imparti. En effet rien de pire qu’une session qui dure trop longtemps et déborde sur d’autres activités pour ne plus leur donner envie de revenir ! L’un des objectifs du facilitateur est de faire en sorte que tout le monde finisse la session sans être épuisé et satisfait du travail accompli.
Contenu
Un des premiers pièges à éviter est de travailler sur une thématique trop large.
Ainsi un thème doit être prédéfini avant la session, avec quelques lignes directrices sur un tableau blanc, pour aider à orienter un test exploratoire.
Une session doit également contenir une phase de rétrospective de 15 minutes afin de synthétiser ce qui a été fait et ce qu’il reste à faire le cas échéant.
Exemple schématique :
Cas concret fictif d’un tour sur un cas de test exploratoire :
Le premier tour commence, un groupe de testeur teste l’application Powerpoint.
Un utilisateur propose de tester l’application en chargeant un template pré-établi, un autre de commencer par une page blanche. Le navigateur décide de commencer par une page blanche et demande au conducteur de créer de commencer le test par cliquer sur « blank presentation ».
Un utilisateur demande de commencer à tester la barre du bas qui semble représenter une feature de zoom. Un autre de commencer par tester la navigation du menu, le navigateur décide de commencer par tester la navigation du menu.
Il demande au conducteur de cliquer successivement sur différents menu « Home », « Insert » etc.
En passant au-dessus du premier élément, le contour d’ « Insert » s’illumine, mais en passant au-dessus de « Design » avec la souris, rien ne se passe, un bug est relevé, le navigateur demande au conducteur de noter ce bug.
Le facilitateur intervient pour dire que le tour est terminé, les personnes du Mob Testing effectuent une rotation.
Nombre de participants
Le nombre de participants peut dépasser la dizaine, mais plus le nombre de participant augmente et plus il est conseillé que le facilitateur et le groupe soit habitué à ce style d’échange.
Le temps de chaque tour diminue proportionnellement au nombre de participants, afin que tous puissent être conducteur-navigateur à tour de rôle au moins 2 à 3 fois pendant la séance).
Une autre façon de définir un tour : Tour défini par événement
Pour une tâche très précise (tester, définir des tests pour une classe,…) il est parfois préférable de définir la fin d’un tour par un événements précis (tant que le délai entre chaque tour ne dépasse pas les 4-5 min).
Voici quelques idées d’événements potentiellement utilisables pour marquer la fin d’un tour :
Test unitaire écrit
Ligne de code d’un test fonctionnel passant
…finir sur un accomplissement est plus gratifiant 😊
Pour aller plus loin
Cette méthodologie de travail ne s’applique pas seulement pour le test, elle peut également s’appliquer à la programmation en général, permettant une montée en connaissance plus rapide pour un junior sur un framework/librairie existant ou pour donner une vision neuve à un senior sur du legacy code.
Pour plus d’informations et des cas pratiques, voici quelques liens :
- Ebook de Maaret Pyhäjärvi and Llewellyn Falco sur le Mob Programming
