Note : 1 ; Une approche des tests à l’ancienne pour un texte récent et une cible complètement ratée.

Tests d’acceptation et User Acceptance Tests n’adressent pas pour moi la même finalité : Le premier est destiné à valider la conformité de ce qui a été réalisé par rapport à la spécification, tandis que le second se doit d’évaluer dans quelle mesure ce qui a été spécifié puis réalisé adresse l’expression de besoin initiale de l’utilisateur. Bref, l’UAT est là pour tester (indirectement) la spécification.

Il y a vraiment très peu de livres consacrés aux UATs. Celui-ci est en fait pratiquement le seul que j’ai pu identifier à ce seul thème. J’avais deux craintes avant même d’avoir ouvert ce livre : avais-je la même vu sur les UATs que les auteurs ? Et , étant donné l’origine très « corporate » du texte, n’allais-je pas rencontrer une approche très processus à l’ancienne ? Comme nous allons le voir, la réponse est hélas « oui » aux deux questions.

L’ouvrage n’est guère long, moins de 180 pages si l’on ne compte pas les inénarrables check-lists ou templates. Le tout est découpé en 10 chapitres pour reprendre son souffle. Moins de 20 pages en moyenne par chapitre, il n’en faudrait pas plus, car le style d’écriture n’est pas pensé pour être une partie de plaisir. Le premier chapitre n’a que peu à offrir, mais je m’arrête quand même sur deux points : d’abord le contexte considéré est bel et bien du cycle en V. Ensuite la définition du rôle de l’UAT semble correspondre à la mienne. Le second chapitre « the importance of UAT » en rajoute une couche sans apporter grand chose : toujours plus de processus, la contribution des différents rôles… tout cela est un peu creux. On revient sur la définition des UATs et cela deviens moins clair, entre la validation des spécifications et la satisfaction du besoin utilisateur. A ce stade, je doute que la distinction soit même claire pour les auteurs.

Le 3ème chapitre nous promène au cœur des trucs les plus sordides : test cases à l’ancienne, processus conçus à l’aide de diagrammes et de tables de décision et enfin scénarios de tests avec des étapes. On est au cœur des tests de validation à l’ancienne, oubliés les UATs. Au milieu de cela se trouve l’unique pépite du livre : l’équivalence partitionning et le boundary value analysis. La première technique que je rencontre pour aider à dresser une couverture de test. Le chapitre 4 traite de la formation d’une équipe. On le dirait tout droit sorti d’un gros classeur de référence sur les processus. J’ai juste envie de passer à autre chose.

Evidemment, comme c’est avant tout de cycle en cascade dont on parle, il était logique d’aborder la phase de transition, objet du chapitre 5. L’UAT y est vu comme un passage formel en production. Tout cela est démodé. Le chapitre 6 évoque la planification (en fait le chapitre 5 aussi). Il y est aussi question de Use Cases, je ne vois pas trop le rapport. Le clou est probablement le diagramme valeur / temps lié aux tests : il faut tester, mais pas trop car les test excédentaires perdent en valeur. Je vous laisse juge.

L’écriture des cas de test eux-mêmes est l’objet du chapitre 7 : test design for UAT. Il ravira les amateurs de Quality Center et tout autre outils surannés du même genre. Le processus lui-même (car il y a un processus à l’intérieur du processus) est décrit sous forme d’un pyramide à 4 étages. Au chapitre 8, « implementing UAT », on pourrait croire qu’il va être question d’automatisation. C’est bien le cas en quelque sorte, car on voit comment transformer des humains en machines ! Retour aux années 80. Bien sûr il est question de formulaires de campagne de test, de fiche d’incidents.

On voit le bout du tunnel avec le chapitre 9 « evaluating the system ». On pourrait résumer le propos de ce chapitre ainsi : « bon, y’a pas trop de bugs. Alleeeez, on y va ! ». Dire que cela heurte l’agiliste en moi est pratiquement une litote. L’ouvrage se referme sur le chapitre 10 qui se demande s’il y a une vie après la mort, pardon : une vie après l’UAT. Assurément. Toutes les cochonneries que l’on a laissé en partant en production, il faut bien les corriger ! Qualité, on vous dit !

J’avais pris un risque avec cet ouvrage. Cela sentait fort le processus à l’ancienne. C’est bien le cas. Le texte est court, mais réellement pénible à lire. A part les « EP / BVA » du chapitre 3, il n’y a pas grand chose à garder. Je ne vois pas comment insérer cela ou des parties dans mes pratiques actuelles. A éviter.

Référence complète : User Acceptance Testing, a step-by-step guide – Brian Hambling & Pauline Van Goethem – BCS 2013 – ISBN : 9781780171678