Objectif de l’atelier
Vous souhaitez provoquer des discussions de fond sur le thème de la qualité logicielle, entre des personnes qui travaillent ensemble mais n’ont peut-être jamais eu l’occasion d’en parler directement ? Cet atelier est fait pour vous !
Lors de cet atelier, les personnes vont :
- Exprimer des représentations, besoins, ressentis et autres visions subjectives de la qualité logicielle
- Apprendre à mieux se connaître les unes les autres
- Prendre conscience des différences de points de vue, pour mieux travailler ensemble au quotidien
- Eventuellement corriger des idées reçues, en bonne intelligence
Avertissement important : c’est un atelier qui est là avant tout pour que les membres d’une équipe se connaissent mieux professionnellement, pas pour juger dans l’absolu « qui a raison » !
Cet atelier n’est pas forcément recommandé aux équipes qui traversent de fortes tensions. Dans tous les cas, sa facilitation nécessite un soin particulier. Votre équipe en ressortira grandie.
Préparation de l’atelier
Pour mener à bien cet atelier en présentiel, il vous faudra :
- 3 personnes + 1 guide de jeu. S’il y a plus de 3 personnes, compter 3 équipes de N personnes + 1 guide de jeu.
- Des cartes « Visions de la qualité », faites maison c’est mieux ! Le principe : chaque carte contient une phrase plus ou moins clivante sur le thème de la qualité logicielle.
- Une salle avec une table centrale, pour y poser les cartes « Visions de la qualité »
La posture de guide de jeu
La personne qui endosse le rôle de guide de jeu se prépare à :
- Faciliter les échanges en établissant un cadre d’ouverture et de respect
- Faire en sorte que la parole soit équitablement répartie
- Prendre des notes pendant l’atelier
- Faire une synthèse de ce qui a été exprimé pendant l’atelier
Déroulement de l’atelier
Les cartes « Visions de la qualité » sont réparties en tas thématiques au milieu de la table, face cachée.
Lors de la première session, l’équipe 1 pioche une carte sur la pile de son choix et la lit à voix haute. L’équipe se concerte rapidement pour choisir de défendre ou contredire ce qui est écrit, puis se lance. En fonction du temps dont vous disposez, cette prise de parole peut être limitée, à 2 minutes par exemple.
A la fin de ce « plaidoyer », l’équipe 2 doit tenter de défendre l’avis contraire à l’équipe 1.
L’équipe 3 doit ensuite synthétiser le débat et attribuer le point à l’équipe qui, selon elle, a été la plus convaincante.
Pendant tout cet échange, la personne qui endosse le rôle de guide de jeu prend des notes. Elle pourra ensuite envoyer une synthèse des résultats de l’atelier.
Ensuite, ça tourne ! Ainsi, lors de la deuxième session, l’équipe 2 tire une carte et fait son plaidoyer, l’équipe 3 contredit et l’équipe 1 arbitre.
Autant de sessions que de cartes peuvent avoir lieu, mais en pratique les débats peuvent prendre un peu de temps et ce n’est pas forcément possible de tout parcourir en une fois. Pas grave : conservez les paquets de cartes et proposez un nouvel atelier quelques mois plus tard !
Exemples de cartes
Pour confectionner vos carte « Visions de la qualité », vous pouvez noter des phrases que vous avez entendues au fil du temps ; des phrases auxquelles vous adhérez mais aussi des phrases avec lesquelles vous n’êtes pas d’accord. Vous pouvez bien sûr créer d’autres catégories ou remanier celles présentes ci-dessous.
Gestion de projet
- « Le test représente souvent un goulet d’étranglement dans un projet. »
- « Pour un projet donné, on ira plus vite avec 5 personnes qui développent, plutôt que 4 qui développent et une qui teste. »
- « Le test est à un projet ce qu’un complément alimentaire est à un corps humain : sympa, mais pas essentiel. »
- « Le nombre de cas de test joués est un bon indicateur de performances. »
- « La véritable mission des tests est de prévenir les bugs, plutôt que simplement les trouver. »
Pratiques de test
- « Les tests d’une fonctionnalité commencent quand elle a été développée. »
- « Il est important de suivre strictement les scénarios de test sans dévier. »
- « Les tests sont déduits logiquement des spécifications fonctionnelles. »
- « Vérifier et valider, c’est la même chose, ce sont des synonymes. »
- « Le test ne peut avoir lieu que si les spécifications sont complètes. »
Rôles et responsabilités
- « Comme les devs connaissent bien le produit, ce sont ces personnes qui sont les plus à même de trouver des tests pertinents à faire. »
- « Dans un projet agile, c’est à l’équipe de test de rédiger les tests d’acceptation d’une User Story. »
- « Dans un esprit d’agilité, c’est plutôt l’équipe de développement qui fait les tests. »
- « Les tests fonctionnels sont du ressort du métier, et les tests techniques sont du ressort des profils techniques. »
- « L’équipe de test est garante de la qualité logicielle. »
- « Pour bien tester, il faut avoir accès à la base de données de l’appli. »
Tech
- « Les tests à automatiser sont ceux qui couvrent les fonctionnalités les plus critiques. »
- « L’automatisation des tests doit démarrer juste après la première mise en production d’une application donnée. »
- « L’objectif premier des tests automatisés est de réduire la durée des campagnes de test. »
- « C’est à la fin du projet qu’il est le plus pertinent de procéder à des tests de charge. »
- « Les tests manuels deviennent peu à peu obsolètes à l’ère de l’automatisation. »
- « Les tests de sécurité constituent un domaine à part et ne concernent pas les profils de test lambda. »
- « Une bonne qualité de code suffit à éliminer la plupart des bugs. »
Bonne session de jeu ! Envoyez-nous votre feedback, et aussi si vous le souhaitez, les phrases que vous avez rajoutées !
