Introduction à l'exemple de mappage

Avant de commencer à travailler sur une user story, il est très important de déterminer vos critères d'acceptation. Cela peut être fait lorsque vous détaillez le backlog ou planifiez le prochain sprint. Pour cela, certaines équipes organisent des réunions spéciales appelées 3 Amigo (plus à leur sujet dans le dernier article ), des rassemblements, des coups d'envoi selon les spécifications ou des réunions-études.

Ne l'appelez pas, pour la plupart des équipes, c'est difficile. La principale difficulté est que ces réunions ne sont pas structurées et que leurs résultats sont incompréhensibles. Ils prennent du temps et sont simplement ennuyeux. En conséquence, les sessions deviennent irrégulières ou complètement abandonnées.

Mais il existe un moyen facile de rendre ces réunions courtes et très productives. Et cette méthode est appelée exemple de mappage ou mappage de cas de test.

Comment ça marche

Des cas de test spécifiques (exemples) sont un excellent moyen d'explorer un sujet. Ils peuvent constituer une bonne base pour vos tests d'acceptation. Lorsque nous discutons des cas de test, d'autres aspects apparaissent qui doivent également être abordés.

• Les règles qui résument différents cas ou vice versa limitent l'applicabilité du cas de test.
• Questions sur les scénarios où personne ne sait ce qui est réellement vrai. Ou des hypothèses que nous proposons pour avancer en quelque sorte dans le développement des exigences.
• Nouvelle histoire d'utilisateur révélée lors de la discussion.

Exemple La cartographie utilise un jeu de cartes de quatre couleurs différentes et des stylos à bille pour enregistrer de nouvelles informations pendant que vous parlez. Pendant la réunion, les informations sont enregistrées sur les cartes et placées sur le tableau, comme dans l'image ci-dessus.

Tout d'abord, sur l'autocollant jaune, vous devez écrire l'histoire elle - même et la placer sur le dessus du tableau. Ensuite, sur les autocollants bleus, indiquez chacun des critères ou règles d'acceptation que nous avons développés précédemment. Nous plaçons des cartes bleues sous jaune.

Chaque règle peut généralement être illustrée par plusieurs cas de test . Chaque test élémentaire a son propre autocollant vert, qui est placé sous la règle correspondante.

Pendant que nous établissons une carte et discutons des cas, des questions peuvent survenir auxquelles aucune des personnes présentes ne peut répondre. Nous les fixons sur des autocollants rouges et continuons la discussion.

La réunion se poursuit jusqu'à ce que tout le monde soit convaincu que l'histoire est bien comprise ou que le temps qui lui est alloué se termine.

Rétroaction instantanée

Au cours d'une telle conversation, une représentation visuelle de la compréhension actuelle de l'histoire se construit facilement et rapidement.

• Un tableau recouvert d'autocollants rouges (questions) indique qu'il reste beaucoup à voir.
• Un tableau recouvert d'autocollants bleus (règles) indique que l'histoire est grande et complexe. Vous devrez peut-être le décomposer. Vous devrez peut-être prendre un autre autocollant jaune (histoires) et mettre une partie des histoires dans l'arriéré.
• Si une règle contient trop de cas de test, elle est peut-être trop compliquée et vous devez mettre en évidence plusieurs règles qui peuvent être décrites plus en détail séparément.

Vous constaterez peut-être que certaines règles sont si évidentes qu'elles n'ont pas besoin de cas de test. Par exemple, si tout le monde comprend la règle de la même manière, vous n'avez pas besoin de perdre du temps et de torturer un nombre fixe de cas de test.

Pensez pour un temps limité

Un groupe de plusieurs amigo devrait faire une histoire décente et décente en environ 25 minutes .

Si vous ne parvenez pas à respecter le temps imparti, plusieurs options sont possibles:

• Vous apprenez toujours à utiliser cette méthode (c'est normal);
• votre histoire est trop grande (ce n'est définitivement plus bon);
• il y a trop d'incertitude dans votre histoire.

Que peut-on faire? Soit essayez de diviser l'histoire en plusieurs, soit donnez des devoirs au propriétaire du produit, de sorte que plus tard vous reviendrez ensemble à cette histoire à la prochaine session en utilisant un exemple de mappage, mais avec des réponses.

Matt Wynne de Cucumber invite les participants à la réunion à voter dans 25 minutes si l'histoire est prête à être soumise pour développement. Même si certains problèmes restent non résolus, l'équipe peut décider qu'il n'y a pas beaucoup d'incertitude et qu'elle peut être développée en cours de route.

Avantage

Un exemple de mappage permet de changer l'échelle et de se concentrer sur les plus petits éléments du comportement de l'historique. En compilant une carte, vous pouvez sélectionner les règles, trouver l'essence du comportement souhaité et reporter le reste pour plus tard. En raison de ces recherches approfondies, la cartographie d'exemple agit comme un filtre, empêchant les grandes histoires audacieuses d'entrer dans le sprint, puis donnant des surprises désagréables à la dernière minute. De plus, cette approche fait gagner du temps et permet de maintenir l'implication des personnes intéressées dans le processus.

Il semble à certains que 3 amigo devraient écrire des tests d'acceptation lors de cette réunion (par exemple, des scripts pour Cucumber). En principe, dans certains cas, cela peut avoir un sens, mais le plus souvent, cette approche ne fera que distraire du véritable objectif de la conversation.

Il est clair d'où vient une telle opinion: l'objectif évident est de prendre une user story, qui a déjà des critères d'acceptation prédéfinis, et de trouver des cas de test qui peuvent être transformés en tests d'acceptation.

Le véritable objectif est de parvenir à une compréhension commune de ce qui est nécessaire pour créer une histoire. Vous pouvez rapidement progresser vers cet objectif sans haute technologie.

Simplifiez l'enregistrement

Par conséquent, au lieu d'utiliser les scripts Gherkin formels, essayez simplement de compiler rapidement une liste de cas de test en utilisant la convention de dénomination.
Par exemple:

• où le client a oublié son reçu;
• où le produit a été acheté il y a 15 jours.

Lorsque l'incertitude est cachée derrière ce nom de cas, vous voulez instinctivement des détails et des détails. Mais même alors, il n'est pas nécessaire d'adhérer à la structure rigide Given When Then.


Si le résultat («alors») n'est pas clair, l'exemple ne fonctionnera pas, mais la question sera.

Connu inconnu

Si la conversation commence à tourner, alors il n'y a pas assez d'informations. Peut-être que la réunion n'a pas la bonne personne, ou vous devez faire des recherches ou utiliser Spike .


Au lieu d'écouter l' opinion de chaque participant sur ce que devrait être le résultat de leur point de vue, écrivez simplement la question sur le carton rouge et continuez. Ainsi, l' inconnu se transformera en un inconnu connu . C'est un gros progrès.

Par expérience, même cet aspect des exemples de cartographie peut transformer 3 réunions Amigo ennuyeuses à rapides et productives.

Qui devrait participer?

Le minimum est votre 3 amigo: développeur, testeur et propriétaire de produit (analyste commercial). C'est juste un minimum. De plus, vous pouvez inviter une personne de l'opération, un spécialiste de l'UX ou toute autre personne liée à l'histoire en discussion. Quiconque peut aider à trouver de nouvelles questions ou à transformer des questions en réponses pendant une conversation sera utile.

Pendant que vous maîtrisez cette technique, il est pratique de trouver quelqu'un pour le rôle d'un facilitateur. Sa tâche officielle sera de s'assurer que tout ce qui est dit est immédiatement enregistré sur des autocollants. Les cas de test et les questions sont rapidement discutés pendant la session, et il faut de la discipline pour les écrire sur des autocollants en temps opportun pour voir ce qui est dit.

Alors, quand écrire sur Gherkin?

Ne vous méprenez pas, l'utilisation de Gherkin est d'une grande valeur, en particulier dans les premiers jours du projet, lorsque vous développez un langage commun. Il est essentiel que les scénarios soient exprimés afin que tous les membres de l'équipe y croient.

Mais pour décrire les cas de test de cette manière, il faut une façon de penser différente. Il est nécessaire non seulement de décider quels cas relèvent du domaine en question et d'établir des règles générales à leur sujet.

Pour une équipe qui travaille avec un langage de domaine suffisamment mature, il est plus rentable pour le propriétaire du produit de consacrer son temps et son énergie à la cartographie et de laisser la tâche d'écrire Gherkin à deux autres amigo. Après avoir développé la spécification Gherkin, le propriétaire du produit pourra donner son avis. Se posant la question: "Est-ce que j'écrirais comme ça?" Vous pouvez vérifier l'efficacité de la cartographie en termes de transfert de la connaissance des produits vers votre amigo.

À quelle fréquence?

En pratique, il est recommandé de se réunir tous les deux jours . Sélectionnez simplement une histoire d'utilisateur et accordez-lui 25 minutes d'attention, puis retournez au travail. Si vous essayez d'en faire plus, gaspillez simplement votre énergie.

Mais j'ai une équipe distribuée!

Pour cela, nous avons déjà trouvé des solutions, par exemple, des listes d'autocollants sur Google Keep ou des tableaux en ligne avec des autocollants colorés. Vous pouvez utiliser la carte mentale. L'essentiel est que vous puissiez travailler simplement et rapidement pour pouvoir vous concentrer sur la conversation .

Quelques derniers conseils

Il est important de distinguer clairement les règles des cas de test avant d'utiliser un exemple de mappage. Il y a un exercice amusant pour cela.

Rappelez-vous, le but ultime d'une telle réunion est de découvrir ce que vous ne savez pas encore . Il n'y a pas de questions stupides, elles aident toutes à vraiment enquêter sur le problème.

En utilisant cette technique, vous constaterez que les règles créent des lignes de développement naturelles pour votre histoire. Essayez de relier calmement les questions, séparez-les et mettez-les de côté. Ensuite, vous pouvez vous concentrer sur la résolution du problème principal. Vous pouvez compliquer et ramener à l'idéal plus tard.

Nous parlerons de la pratique de 3 Amigo pour définir les exigences et créer des fiches de cas de test lors de la conférence QualityConf . De plus, la liste des rapports acceptés contient d'autres approches pratiques extrêmement intéressantes pour créer un produit informatique de haute qualité. La conférence QualityConf se tiendra pour la première fois dans le cadre du festival RIT ++ les 27 et 28 mai, ont le temps de se joindre.