La taverne du testeur

La communication visuelle pour le test (mais pas que !)

« Un bon dessin vaut mieux qu’un long discours » comme dit l’adage : et bien oui, nous en sommes convaincus et nous voulons vous le faire découvrir.

Vous avez peut être suivi le webinar : disponible ICI

Que cela soit le cas ou non, cet article a pour objectif de vous faire découvrir ou redécouvrir comment les supports visuels peuvent vous aider dans les différentes étapes de vos projets.

Pour vous présenter notre démarche, nous avons choisi l’exemple de la construction d’une application de gestion de déplacements professionnels qui doit:

  • Permettre aux employés de réaliser des demandes de déplacements;
  • Permettre aux managers de valider ou invalider des demandes de déplacements;
  • Permettre au service RH d’intervenir pour la gestion du remboursement des frais liés au déplacement. 

Pour nos visuels, nous avons utilisé les outils Klaxoon pour la réalisation de différents tableaux et Yest pour la représentation du parcours applicatif. 

L’approche présentée dans cet article est indépendante de ces outils et peut être réalisée avec d’autres solutions offrant des fonctionnalités d’expression visuelle.

1. Exprimer un besoin métier

L’introduction de supports visuels peut se faire dès le début d’un projet, même quand il s’agit encore que d’une idée, d’une ébauche.

A ce stade, l’objectif est de clarifier quel est notre problème/besoin en répondant aux questions : pourquoi ?, quoi ?, qui ?, comment ? et dans quel objectif ?. L’image ci-dessous illustre un exemple de représentation visuelle construite pour répondre à ces questions. 

Chaque idée reprend les questions posées ainsi que les réponses obtenues. Ainsi chaque question est liée à un ensemble de réponses et permet de clarifier quels sont les besoins, même si à ce stade ils sont peu voire pas détaillés. 

Pour apporter du détail, il est possible d’utiliser un second support visuel (qui suivra le projet dans chacune de ces phases) : le parcours applicatif.

Il permet de poser une première réflexion sur l’enchaînement métier qui va être réalisée.

Dans la représentation ici, on peut comprendre que le processus de gestion des déplacements commence par l’émission d’une demande de déplacement par un employé. Celle-ci sera suivie par la validation ou non du déplacement par le manager. Si la demande est validée, l’employé peut demander le remboursement de ses frais et le service RH est impliqué sinon le processus s’arrête. 

Dans cette phase initiale d’expression du besoin, les supports visuels permettent de clarifier les besoins et répondre aux questions d’ordre général sur la solution souhaitée. 

L’intérêt d’utiliser des supports visuels est d’avoir une vision transverse sur les différentes questions qui ont été émises et les réponses obtenues. En termes de bonne pratique, introduire des légendes basées sur les couleurs permet une identification précise de certains aspects. Par exemple, dans le parcours applicatif, les couleurs ont été choisies en fonction des personas qui interviennent. 

2. Modifier les Users Stories

Une fois le cadre du besoin posé, un atelier de brainstorming peut aider à construire les différents blocs qui vont constituer la future application. Ici, nous avons fait le choix d’utiliser les supports visuels pour définir les User Stories (US) à implémenter. 

Ci-dessus, nous avons repris le parcours applicatif initié lors de la phase précédente et étudié comment nous pouvions le découper en différentes US. L’atelier se déroule de la manière suivante : 

  • Chaque acteur est invité à poser les questions (à l’aide d’une idée en rouge) qu’il a vis-à-vis du parcours initialement pensé.  L’idée étant de s’assurer qu’aucun point n’a été oublié. Ici on voit notamment que les séries de questions/réponses ont mené à la création de 2 US en amont du parcours initialement imaginé (L’ajout des utilisateurs dans le backoffice et la gestion de l’authentification).
  • Une fois les questions posées et les réponses apportées, il est possible de définir un découpage comme cela a été proposé dans la capture. Chaque groupe de questions ainsi que les éléments de parcours ont été regroupés (en jaune) pour former des US.

Dans ce brainstorming, le fait de poursuivre avec l’utilisation du support visuel initié lors d’un précédent atelier permet d’assurer une continuité. Chaque acteur voit le parcours se développer et le met à jour pour intégrer les éléments qui ont été omis dans la 1ère version.

Les supports visuels sont voués à évoluer ou non selon leur nature avec l’avancement du projet. S’ils ne sont pas modifiés, ils permettent de donner une vision à un instant T sur les décisions qui ont été prises. Dans cet exemple, une personne qui n’a pas participé à l’atelier peut comprendre les réflexions qui ont mené au découpage des US à travers les questions et réponses. 

3. Détailler les US

Une fois les US créées, les supports visuels peuvent être utilisés pour les raffiner en définissant les critères qui vont les composer. Pour cela, il est possible de mener un atelier appelé Example Mapping qui aura pour objectif de lister les règles de gestion/exigences d’une US accompagnées d’exemples concrets.

Example mapping de l’US5 – Faire une demande de remboursement

Les idées en bleu représentent les règles métier à traiter, les idées vertes claires clarifient les règles avec des exemples concrets, les questions sont en rouge et les réponses en vert foncé.

Nous avons une vision globale du travail de raffinement qui a été réalisé. Cette vision est intéressante, car elle apporte de nombreuses indications uniquement basées sur de l’interprétation visuelle, sans lire le contenu des cartes.  

Zoom sur la première règle avec ses exemples, questions et réponses

L’information principale de l’image ci-dessus est de percevoir rapidement la « santé » de notre US. Nous pouvons remarquer que:

  • Nous avons défini 8 règles métier ( bleues) : ce nombre reste acceptable. Mais attention, s’il vient à augmenter, il faudra peut-être envisager un découpage de l’US. Le nombre d’idées bleues sur les règles métier nous permet donc d’évaluer la granularité de notre US.
  • Nous pouvons aussi évaluer la complexité des règles et de l’US grâce aux exemples et questions/réponses. Un nombre élevé d’exemples peut impliquer une complexité forte d’une règle et il faudra se poser la question de découper cette dernière en plusieurs règles. Cette complexité est corrélée au nombre de questions qui ont été émises. Dans notre représentation, le nombre d’exemples reste correct et chaque question a obtenu une réponse ce qui est un bon point. Certaines règles peuvent rester sans exemple : cela signifie qu’il n’y a pas d’ambiguïté et que la règle est triviale.
  • A gauche, nous zoomons sur une règle métier.

Ces exemples serviront de base pour concevoir les cas de test.

Nous pouvons aussi en parallèle modéliser ces tests sous une autre forme visuelle.

Dans le parcours ci-dessous, nous avons représenté les enchaînements métier pour le test de l’US traitée ici, nous y avons fait figurer une partie des règles à tester notamment la 1ère qui concerne la possibilité ou non de pouvoir réaliser une demande de remboursement. Le parcours nous montre que certains cas (listés dans le tableau, appartenant au parcours) mènent ou non à la saisie des frais. Le tableau suivant liste les différents exemples qui feront l’objet de test.

Les supports visuels utilisés ici se complètent. Ils permettent d’obtenir une vision globale à travers le tableau ou le parcours applicatif et aussi une vision plus détaillée grâce à la description des exemples, qu’elles soient réalisées à travers des cartes ou à l’aide de tableaux dans le parcours.

4. Tester les US

Une fois que les règles métier sont assez détaillées, nous pouvons entrer dans la phase de conception des tests. Dans le cas d’usage de parcours, il est possible de le réutiliser directement pour la conception de scénario de test. En effet, chaque brique du parcours contient une table comme présentée dans la section précédente et la concaténation de chacune des étapes de test du parcours permet de former un scénario fonctionnel. (comme ci dessous)

Ces scénarios dans notre exemple peuvent être publiés dans un outil comme Xray pour obtenir directement un suivi de la couverture de la conception des tests sur le parcours applicatif. La visualisation de la couverture des règles métier sur le parcours applicatif offre une nouvelle manière plus visuelle de gérer la couverture des exigences, plutôt que le suivi d’un listing traditionnel de couverture. (pour plus détail sur la couverture visuelle, rendez-vous à la section suivante)

Cette vision avec une granularité très fine, orientée sur les tests fonctionnels, peut être combinée avec une vision plus transverse telle que cela est fait dans ci-dessous.

L’état des tests fonctionnels, de sécurité , de performance, etc… y est représenté, chaque couleur d’idée indiquant un statut. Si on fait un focus sur les tests fonctionnels, on peut notamment voir qu’un test a échoué avec le détail de l’échec. Regarder le tableau dans son ensemble donne un état de santé du projet : si le tableau est majoritairement coloré en vert, cela indique un bon niveau de confiance sur les tests. Au contraire, si le rouge est dominant, alors cela signifie qu’une majorité des tests est en échec et la version actuelle doit être probablement retravaillée et intégrer des corrections de bugs.

En complément, les supports visuels ici ont toujours une cohérence vis-à-vis des supports déjà créés. Dans le tableau, on réutilise les idées traitant des règles métier initiées précédemment en faisant évoluer leur statut vis-à-vis des résultats de tests. Pour le parcours, même démarche : il évolue en même temps que les phases du projet.

5. Gérer l’avancement du projet

Un dernier aspect où les représentations visuelles peuvent être un support fort est l’avancement du projet. Dans les sections précédentes, nous avons montré quelques exemples d’indicateurs visuels et nous allons ici en détailler d’autres, propres à la gestion de projet globale.

Par exemple, il est possible de construire un tableau tel que celui présenté ci-dessous pour évaluer l’avancement des différentes US. 

La roadmap donne un avancement sur les différentes US avec en vert celles qui ont été validées et sont prêtes à être livrées, en bleu celles qui sont en cours et jaunes celles qui sont à faire. Ici aussi, la dominance d’une couleur ou d’une autre est importante : sur le haut du tableau, on voit peu d’éléments et majoritairement du vert ce qui indique une bonne santé des US 1,2 et 3. Par contre, le rouge sur les feedbacks de l’US4 tend à penser que du retravail sera sans doute à faire. Et les US 5 et 6 étant majoritairement jaunes ont encore beaucoup d’activités non démarrées.

D’un seul regard, on voit clairement que l’effort va se trouver sur les US 4,5 et 6 sans forcément connaître le détail des activités à réaliser.

Un autre indicateur visuel qui va aider à la prise de décision et l’identification de point de peine est le suivi de l’exécution sur un parcours applicatif.

Nous avons plutôt l’habitude de suivre les résultats d’exécution des campagnes à travers des tableaux avec les tests exécutés et leur statut d’exécution ou à travers des graphiques. 

Le fait de les suivre sur un parcours métier offre une autre vision. 

Ici nous avons le résultat d’une exécution de test en échec. 

Si nous regardons à quoi correspond cet échec sur le parcours, nous pouvons constater que c’est l’US 5 , concernant la demande de remboursement de frais qui contient un cas en erreur, qui de ce fait, impacte la validation cotée RH. Le fait de voir l’impact de l’échec sur le parcours invite à la réflexion. S’agit-il d’un cas isolé, les autres cas de l’US sont-ils impactés, doit-on refaire des tests, etc. Sans un support visuel adapté, ces potentiels points de peine sont plus complexes à mettre en avant.

Le mot de la fin 

Nous vous avons présenté ici comment utiliser différents supports visuels pour vous accompagner durant les différentes phases de votre projet.

Si cet article vous a donné envie d’utiliser des supports visuels, voici quelques conseils avant de vous lancer : 

1. Utiliser ce dont on a besoin :

Quand on commence à utiliser des supports visuels pour travailler de manière collaborative, on a souvent tendance à vouloir utiliser toute la palette d’outils et d’éléments que nous offrent les différents outils.
Ce n’est pas forcément une bonne idée que de vouloir tout montrer sur une même représentation. Cela devient vite illisible, difficile à utiliser et finalement contre-productif.

2. Structurer et organiser vos différents visuels

C’est la technique du diviser pour mieux régner. 
Dès que vous vous rendez compte que vos représentations sont trop complexes, réfléchissez à l’utilité d’avoir tous ces éléments devant vous
Ne pourraient-ils pas être séparés dans différents tableaux, parcours, ou autres ?

3. Adapter vos visuels à vos interlocuteurs   

On ne fait pas un même visuel si on est entre testeurs, développeurs, analystes métier et que l’on veut discuter d’un point particulier,  que si on produit un visuel pour toute l’équipe et que chacun devrait pouvoir facilement se l’approprier. Donc avant d’initier un support visuel, identifiez bien les interlocuteurs avec lesquels vous allez le partager.

Article co-écrit par Elodie Bernard et Benjamin Butel

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Automatisation

Outil de Test : Automatisation avec Cerberus Testing

Cerberus Testing en Bref Cerberus Testing est un framework d’automatisation de test 100% open source né en France. Son nom évoque le Cerbère, gardien des enfers et  “chien à trois têtes”. Le projet a démarré en 2010 à La Redoute pour adresser l’automatisation de tests. À l’époque, son objectif était

Lire la suite »
Agilité

PO et testeur… C’est possible?

La réponse peut paraître simple… Surtout lorsque l’on regarde ma mission actuelle chez Orange ! Néanmoins cumuler ces 2 casquettes soulève au moins 1 problème majeur . Problématique : Le PO représente le métier et est responsable des tests d’acceptance (Niveau 4) alors que le testeur s’occupe (et généralement exécute) les tests systèmes

Lire la suite »
Agilité

2- Définir une user story selon la théorie

Ce sujet pourrait paraître évident. En réalité, il ne l’est pas. Il y a, en fait, une grande  incompréhension sur le terrain, de la définition de ce terme au regard de la théorie. Revenons sur ce sujet avant d’avancer sur les spécifications et les tests. Dans l’esprit des personnes qui

Lire la suite »