Vis ma vie de responsable QA (Part II) – Test Cases, ATDD et BDD

Chose promise chose due, voici la seconde partie de mon retour d’expérience QA sur l’ATDD, la BDD et les Tests Cases.

Selon moi une bonne US se doit d’être INVEST dans son descriptif:

I – Independent – La User Story ne doit pas être relative à une autre
N – Negotiable – Elle peut être négociée avec l’équipe
V – Valuable – Elle apporte de la valeur pour le client
E – Estimable – Elle est estimable par l’équipe (point ou jour homme)
S – Small – La tâche doit être la plus petite possible
T – Testable – Elle doit être testable et disposer de critères d’acceptation

Elle doit disposer de règles de gestion claires et si possible (est-ce possible?) exhaustives.
Enfin autant de cas de tests possible pour permettre au développeur de connaître et envisager tous les tenants et aboutissants de son développement.

Test Cases et ATDD

Chaque User Story est définie au départ en mode Acceptance Test Driven Development (ATDD), le développement piloté par des Tests d’Acceptance

« En tant qu’utilisateur, lorsque je clique sur ce lien je dois être redirigé sur cette page qui doit contenir X et Y… ».

Toute l’US tourne autour de cette phrase ou d’une série de Tests d’Acceptance comme celui-ci. Le principe d’ATDD est de les utiliser comme critère de validation, « Definition of Done » de la User Story

En partant de ces scénarios d’acceptance, nous avons écrit les Tests Cases (TC) de façon à ce qu’ils servent aux développeurs sans qu’ils aient besoin d’interpréter le parcours, être le plus précis possible à base de parcours pas à pas:

« En tant que client xxx@ggg.com avec le mot de passe xxxx ayant une commande en cours, cliquer ici puis ici, vérifier ça puis cliquer là, vérifier ça et ça… »

Le parcours étant plus ou moins long en fonction de la granularité de la User Story. Ces Tests Cases étaient écrits avant le planning poker, le but étant d’améliorer la qualité des développements.

Feedback

Décrire la User Story en ATDD permet de la structurer et ne prend pas beaucoup de temps étant donné que l’écriture se substitue à une description plus verbeuse.
Ecrire les Tests Cases est une tâche fastidieuse et longue mais si au final cela permet au développeur de mieux connaître son produit, d’envisager plus de cas de figures et de pouvoir faire une première validation avant de la mettre dans nos mains, nous pouvons supposer que le ROI sera fort.

Qui utilise?

Comme vous l’aurez compris, le but était de donner plus de précision aux développeurs avant la phase de développement, piloter le développement par l’expérience utilisateur. Si le contenu de l’US, c’est à dire les Tests d’Acceptance étaient bien lus par tous et le sont toujours, les Tests Cases, eux, ne servaient qu’à la QA.

ROI du combo ATDD + TC

Les Tests Cases sont un bon aide-mémoire pour l’équipe test mais ont un effet fourbe qui est de penser qu’ils couvrent tout. Le travail de la QA est de tester tous les cas de figure même les plus étranges, faire des aller-retour entre les pages d’un formulaire, rafraichir la page, utiliser le backnav… or écrire tous ces cas dans un test case serait anti-productif, imaginez le temps nécessaire pour décrire la totalité des cas.
Nous sommes probablement, en tant que QA, les personnes ayant la meilleure connaissance produit et nous avons remarqué que les tests étaient effectués par reflexe au fur et à mesure de l’appropriation du produit.

Le ROI de l’ATDD est indéniable: clair et rapide à écrire, le gain est indéniable. Il offre une structure à la description du besoin par le PO, une mécanisation de la pensée par une reproduction du schéma en fonction des profils d’utilisation. On évite ainsi des descriptifs verbeux où on se perd ou à l’inverse lacunaire qui pousse à l’interprétation

Le ROI des Tests Cases est plus limité. Peut-être est-ce dû à la taille de notre équipe QA (nous sommes 2) ou la difficulté de les visualiser dans Rally (voir partie I de la suite d’articles) mais depuis que nous les détaillons, outre l’utilisation pense-bête, ils n’ont aucun apport en termes de qualité du développement.

Sur une équipe projet (Dev+QA+Chef de projet+Créas…) réduite comme la nôtre (tout est relatif, nous sommes tout de même une petite quinzaine) mais surtout dans un projet agile, l’écriture de test cases dont les seuls clients sont la QA offre un ROI quasi nul.
L’ATDD est une excellente méthode mais il manque quelque chose dans ce schéma « en tant que… je fais… j’obtiens… » qui est la notion de contexte. En résulte une interprétation en fonction des cas multiples de départ (d’où viens-je? comment suis-je configuré? ai-je ou non une commande existante?…), souvent ces différents cas sont découverts au moment du test et nécessite autant de correctifs que de cas non pris en compte.

Il nous manque donc dans la syntaxe un « étant donné… » et ce « étant donné » est défini dans le BDD

Test Cases et BDD

Chaque User Story est définie au départ en mode Behavior Driven Development (BDD), le développement piloté par le comportement:

GivenWhenThen
« Etant donné que ma première facture n’a pas été payé, lorsque je vais dans mon compte alors je vois affiché une alerte de paiement »

Ce schéma s’apparente explicitement à la notion de cas de gestion, avec un contexte, une action, un résultat. L’écriture est plus courte qu’en ATDD et encore moins verbeuse, d’ailleurs l’écriture BDD peut se faire parfaitement sous forme tableau

 

Given When Then
Première facture non payée Accès à mon compte Affichage d’une alerte paiement

Je ne reviendrai pas sur l’écriture des Tests Cases qui n’a pas changé mais on remarque bien dans l’exemple exposé en amont « En tant que client xxx@ggg.com avec le mot de passe xxxx ayant une commande en cours, cliquer ici puis ici, vérifier ça puis cliquer là, vérifier ça et ça… » que le contexte est bien exposé « ayant une commande en cours »

Feedback

Le BDD ne peut pas se substituer à l’ATDD, même s’il s’avère très efficace pour écrire des cas de gestion, il n’explique en rien les tenants et aboutissants d’une fonctionnalité. L’explication doit passer par un minimum de verbalisation de la fonctionnalité.
Cependant le mode d’écriture de BDD s’apparente, par sa réduction syntaxique, à un langage de développement (d’ailleurs le BDD est un portail donnant sur le codage automatique des test, sujet que je traiterai dans un futur article), à la mécanique de réflexion du développement et rien que pour ça c’est un excellent outil de définition des cas de gestion.

Qui utilise?

Idem que pour l’ATDD+TC

ROI du combo BDD + TC

Lorsque nous avons commencé à mettre en place le BDD, nous nous sommes aperçu qu’écrire BDD et TC pour une même US relevait de la double saisie, une personne extérieure au projet nous a d’ailleurs proposer d’écrire les tests cases sous la forme de… je vous le donne en mille… Given, When, Then

Roi du BDD: le coût est très faible en termes d’écriture et se limite d’ailleurs au fait de penser les cas de gestion différents. Les bénéfices sont importants car ils évitent au maximum l’interprétation de la part de l’équipe de développement.
Cependant, comme je disais plus haut, se limiter à l’écriture de User Story en BDD ne permet pas de se projeter totalement dans le besoin initial, il explique comment doit réagir la fonctionnalité mais ne la décrit pas
Roi du Test Case: Je vous laisse deviner

Conclusion

L’ATDD et le BDD ne semble pas offrir à eux seuls l’écriture ultime de User Stories, c’est en les combinant qu’ils permettent la résolution des problèmes de description et d’interprétation du fonctionnement. J’ai vu cette fusion se faire naturellement et inconsciemment pour le product owner après avoir vu (sans le savoir) ces deux méthodes.

Les User Stories se sont transformées en « En tant qu’utilisateur ayant passé une commande en plusieurs fois, lorsque je clique sur le lien mon compte je dois arriver sur ma page avec un message de confirmation… ».

En me renseignant sur ATDD et BDD, j’ai d’ailleurs eu beaucoup de mal à caractériser réellement leurs différences (outre le choix des termes), ce que j’ai écrit tout au long de cet article résulte d’ailleurs de ma vision et je me doute que, dans l’analyse de la théorie, certain ne voient pas forcément la même chose.

Nous avons donc combiné le En tant que et le Given pour obtenir un contexte complet qui se décline par la personnification et par le contexte dans lequel on doit se trouver, nous avons donc une description un peu plus « humaine » que ce que propose le BDD seul.
Cependant, pour lister très rapidement tous les cas à prendre en compte, comme nous l’avons vu, le BDD est un excellent mode d’écriture. Nous avons donc écrits nos user stories sous la forme ATDD+BDD puis BDD seul

Pour ce qui est des test cases, par rapport au contexte projet, je pense qu’ils ne doivent pas être négligés dès lors qu’on est dans un contexte cycle en V, notamment comme aide-mémoire. Ils sont aussi obligatoires pour constituer le cahier de test que demande le client.
Ici, projet agile avec itération de 2 semaines, notre mémoire ne nous ayant pas encore fait défaut, il nous suffit de lire la user story pour savoir exactement ce qu’il faut regarder. Nous n’avons pas de cahier de test non plus donc nous ne pouvons pas rentabiliser l’écriture des tests cases.

L’écriture de cas de test devient totalement antiproductif une fois mis en place le combo ATDD + BDD dans un contexte agile car il n’offre aucun apport en terme de qualité des développements. On pourra arguer que l’écriture d’US est à la charge des PO et que les tests cases à la charge de la QA.

Pourquoi ne pas laisser la définition des règles de gestion à la QA? Pourquoi ne pas intégrérer la QA à la réflexion sur les fonctionnalités et ainsi piloter clairement l’écriture d’US par le test?

Prochain billet

La prochaine fois, je parlerai de communication entre QA et développeurs

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s