Note de lecture : User Acceptance Testing, par Brian Hambling & Pauline Van Goethem

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.

Lire la suite

Publicités

Note de lecture : Agile Testing, par Lisa Crispin & Janet Gregory

Note : 3 ; Un complément indispensable aux projets agiles, mais bien lourd à digérer !

Les ouvrages traitant des projets en mode agile évoquent le plus souvent les tests d’acceptation d’une manière un peu globale en évoquant d’une part qu’il faut les faire et d’autre part qu’il est pertinent de commencer par les écrire afin de travailler en mode « ATDD ». C’est bien mais un peu succinct.

Ce livre prend une toute autre optique : prenez un testeur, un vrai, avec beaucoup d’expérience dans des contextes classiques. Plongez-le (ou « la » en l’occurrence ici, ici) au sein d’une équipe agile, avec pour mission d’adapter ses pratiques à l’esprit et à la façon de travailler de cette équipe. Tirer de ce travail de nouvelles pratiques et de nouveaux savoir-faire est l’objet de cet ouvrage !

Si l’idée est bonne, avec un texte ciblé vers le testeur, j’y trouve beaucoup de redondances avec ce que l’on connaît ou est déjà écrit ailleurs dans la littérature agile. Toute la première partie est consacrée à ces généralités. Bref, mauvaise pioche pour les 35 premières pages.

Lire la suite

Note de lecture : Executable Specifications with Scrum, par Mario Cardinal

Note : 3 ; Du Scrum de base sans surprise, à part celle de décevoir sur son titre !

Bien entendu, c’est l’aspect « spécifications exécutables » qui m’a conduit vers ce livre ! Le fait qu’il soit plutôt bref, avec ses 150 pages était un bonus. Au final, c’est une déception, la note est peut-être sévère à cet égard mais c’est ainsi, car il s’agit plutôt d’un nième « Scrum Shū ». L’ouvrage manque dans ses grandes largeurs d’originalité et le peu qu’il y en a ne m’a guère convaincu. Heureusement, il faut avouer qu’il est bien écrit. Voyons donc ce que nous réservent ses 9 chapitres.

Le premier d’entre eux couvre une douzaine de pages au sein desquelles on retrouve les poncifs habituels sur la justification des projets en agile : incertitude, complexité etc. En fait, j’ai même l’impression de relire l’introduction du premier bouquin sur Scrum, celui du début des années 2000. Le second chapitre, lui aussi fort d’une douzaine de pages, est un peu moins bateau. Il évoque les prérequis au démarrage de projet. Rien de neuf sous le soleil si ce n’est une bonne vue synthétique et l’usage de l’euristique de nommage de Gause et Weinberg.

Le chapitre 3 ne compte que 10 pages et sert principalement d’introduction à l’un des concepts originaux de l’auteur, celui de « desirement », contraction de « desire » et « requirements ». L’aspect « desire » étant inspiré de nouveau par Gerald Weinberg (are you ligh on ?). Disons le tout net : c’est très peu convainquant. Le tarif est d’une dizaine de pages également pour le chapitre 4 « expressing desirements through user stories ». On nous ressasse une nouvelle fois le template de Mike Cohn et le INVEST. La partie sur les rôles et bénéfices parvient à être intéressante, tandis que l’introduction au backlog reprenant la prose de Mike Cohn est parfaitement insipide.

Lire la suite

Note de lecture : The Cucumber for Java Book, par Seb Rose, Matt Wynne & Aslak Hellesoy

Note 7 ; Mieux qu’un simple livre sur l’outil !

Voilà un livre qui trainait depuis bien trop longtemps sur ma pile de livres à lire ! C’est une bonne surprise à plus d’un titre. D’abord parce qu’il aborde bien ce qu’il est sensé aborder, à savoir l’outil Cucumber. Il faut dire que l’un des auteurs, Aslak Hellesoy est l’un des comitters initiaux. Mais surtout parce qu’il aborde le sujet de la bonne façon, à savoir par son usage. Les auteurs s’efforcent ainsi de mettre l’accent sur l’expressivité des tests au fil des chapitres. L’ouvrage a même droit à un traitement de faveur, il est imprimé en couleur.

Au total, le texte compte 290 pages sur 6 chapitres. L’ensemble est structuré en 3 parties. La première d’entre-elle a trait aux fondamentaux de Cucumber et couvre 6 chapitres soit 115 pages. Le premier d’entre-eux est vraiment très succinct et donne juste quelques clés sur Gherkin (le langage d’expression de Cucumber) et la façon dont Cucumber l’interprète et sur la nature des tests d’acceptation. Les 18 pages du second chapitre vont directement dans le concret : comment écrire une feature et l’implémenter par l’exemple. Par contre le partie « build » est franchement bricolée. Il faudra attendre un moment pour voir les auteurs mettre cela dans Maven. Mais l’intro est bien réussie.

Le chapitre 3 est un approfondissement : on voit les éléments de syntaxe de Gherkin, à l’exception des tableaux. Il clarifie certainement les éléments d’écriture, mais c’est plutôt un chapitre de transition. Le chapitre suivant aborde un élément essentiel : la syntaxe d’expression régulière et surtout les groupes de capture. Très bon boulot !

Lire la suite

Note de lecture : How Google Test Software, par James Whittaker, Jason Arbon & Jeff Carollo

Note : 4 ; Plutôt déçu.

Le livre m’avait été chaudement recommandé, je m’attendais donc à un texte que allait quelque peu bouleverser mon mode de pensée. De ce côté-là, on est loin du compte. Le texte n’est pas médiocre pour autant. Il compte 235 pages dans sa partie principale auxquelles il faut ajouter les 30 pages d’annexes. Il ne compte que 5 chapitres, ces derniers sont donc chacun très volumineux. J’avoue que cela rend la lecture peu plaisante, surtout que le texte est très dense. Les 3 chapitres du milieu sont organisés selon les rôles de l’organisation Google, une articulation que je trouve fort peu heureuse. Voyons cela.

Le premier chapitre est, avec le dernier, le plus court du livre car il ne compte que 12 pages. Cette introduction nous décrit comment l’organisation fonctionne, avec ses 3 rôles au niveau des tests et la philosophie générale : pas de phase de tests en aval et des testeurs délibérément en sous effectifs.

Lire la suite

Note de lecture : Fifty Quick Ideas to Improve your Tests, par Gojko Adzic, David Evans & Tom Roden

Note : 7 ; D’excellents conseils dans la lignée du titre éponyme sur les user stories

Gojko Adzic et ses co-auteurs ont gardé la recette qui marche avec ce nouveau titre. Celui-ci ne compte que 117 pages, et comme le titre le suggère : 50 conseils chacun occupant 2 pages avec une illustration quelque peu décalée. Ces conseils sont répartis en 4 sections.

La première partie « generating testing ideas » regroupe 12 conseils. Je citerais en particulier parmi ceux-ci la « big picture view of quality », un pendant pour les tests de la pyramide de Maslow. Un concept bien plus intéressant que la classique pyramide des tests rassemblant des choux et des carottes ! Le « tap into your emotions » nous donne un truc de plus pour explorer les tests à construire. « monitor trends in log & console » est une excellente idée pour chercher des éléments à inspecter. Enfin le « mob your test sessions » est une nouvelle variante du workshop des 3 amis, étendu à plus de personne et qui ne se limite pas à l’écriture des cas de test !

Lire la suite

Note de lecture : Explore It ! par Elisabeth Hendrickson

Note : 9 ; L’approche agile appliquée aux tests exploratoires : brillamment et efficacement exposé par une pionnière de l’agilité !

Me voilà réconcilié avec les tests exploratoires ! Les fameux tests du 4ème quadrant du framework de Brian Marrick, ceux qui servent à critiquer le produit « après coup » ! Il est vrai qu’Elisabeth Hendrickson n’est pas n’importe qui. Et force est d’avouer que les 150 pages de cet ouvrage couvrent bien la question et donnent des réponses efficaces à mes doutes.

Le texte est découpé en 13 chapitres regroupés en 3 parties. La première d’entre-elles « Establishing Foundations » comprend les 5 premiers et compte 55 pages. Le premier d’entre-eux traite sur 6 pages le plaidoyer pour le test exploratoire que l’auteur considère complémentaire à l’exploration.

Le second chapitre est sans doute le plus important du livre car il présente « l’exploration charter » qui est au test exploratoire ce que la User Story est à la spécification agile ! L’auteur y présente de manière claire et détaillée comment créer des charters à la fois focalisés mais gardant assez de liberté pour permettre l’exploration. 13 pages très bien utilisées.

Lire la suite

Note de lecture : ATDD By Example, par Markus Gärtner

Note : 3 ; Mélange des genres…

Je sors assez désappointé de la lecture de ce livre assez succinct de 185 pages. Heureusement la lecture n’en est pas trop longue, d’une part du fait du nombre de pages et d’autre part du fait du format plus réduit que d’habitude. L’ouvrage est découpé en 3 parties, les deux premières sont dévolues à des études de cas tandis que la dernière évoque les principes de l’ATDD.

La première partie est consacrée à la gestion d’un parking d’aéroport. Elle couvre 50 pages environ sur 4 chapitres. Ca commence relativement bien au premier chapitre, sous la forme d’un dialogue entre le développeur et le responsable métier. Bien que cela n’ait rien de grandiose et ne m’ait rien appris, cela m’a même semblé assez basique. Et puis rapidement aux chapitres 2 et 3, on cause outils, Selenium pour être précis. Je ne m’attendais pas vraiment à un cours (pas terrible de surcroit) sur les fixtures Selenium. Tant pis ! Le dernier chapitre évoque la collaboration et le wishful thinking sur 4 pages, c’est assez creux. Cela ira peut-être mieux sur la prochaine partie ?

En fait non, c’est pire ! Cette partie déroule également sur 4 parties, mais sur 75 pages cette fois, la gestion de feux de croisement tricolores. Le chapitre 5 est une description du fonctionnel. Comme tout ça reste assez simple, on va être autonome : on ne va pas s’encombrer d’un spécialiste fonctionnel qui va trainer dans nos pieds pendant qu’on code, n’est-ce pas ? Et hop ! Dès le chapitre 6 on saute à pied joints dans des fixtures Fitness. Un peu de code… un peu de refactoring… c’est franchement brouillon, difficile à suivre mais l’auteur à l’air très fier de lui. On se souvient au chapitre qu’on est sensé écrire des cas de test. On gribouille donc quelques tables et c’est reparti pour une très ennuyeuse tirade de code et de refactoring. Le chapitre 8 conclut cette partie : testez votre « glue code » ! Ah ouais ? OK…

Tous mes espoirs reposent donc sur la 3ème partie. Vais-je y trouver ce que j’étais venu chercher ? Elle compte 5 chapitres sur 60 pages. Au chapitre 9, l’auteur évoque la nécessité de s’appuyer sur des exemples. En résumant (visiblement) tant bien que mal les propos de Gojko Adzic. Au chapitre 10 il parle de la nécessité de spécifier en collaboration en reprenant péniblement la prose de Mike Cohn qui l’a lui même emprunté à Suzanne et James Robertson (je fais référence au « trawling requirements » par exemple). Mais cela l’auteur semble l’ignorer. Sur les deux chapitres suivants (automatisation des tests et « clean tests ») l’auteur est un peu plus chez lui, ça va mieux. Le dernier chapitre ? Ah, bah…

Lire la suite

What is an agile tester ?

Rôle, quel rôle ?

Oui, le tester agile n’a plus la même place qu’avant. Tout d’abord, il n’y a plus d’équipe de test, mais un testeur intégré dans une équipe pluridisciplinaire ! Ce qui signifie aussi par voie de conséquence qu’il n’y a plus de phase de test. En fait, pour aller plus loin, il n’y a plus non plus de rôle de testeur !

La qualité est désormais l’affaire de tous, on passe de la notion d’assurance qualité à celle d’assistance qualité. C’est pourquoi ce n’est plus le rôle de testeur qui primer mais la compétence qu’il véhicule et injecte dans l’équipe. Kniberg nous débarque le concept de « T shape compétences », que personnellement je n’aime pas trop.

S’assurer que le produit marche

L’assistance qualité, dans une équipe agile recouvre un certain nombre d’activité que l’auteur nous énumère. Mais surtout, le testeur agile doit travailler en interaction avec les développeurs et les utilisateurs afin de toujours raccourcir la boucle de feedback, une idée qui s’inscrit bien dans la philosophie du « continuous delivery ».

Lire la suite

Meetup Craftsmanship de Février

Déjà mon deuxième meetup Craftsmanship ! La formule reste inchangée mais le contenu se renouvelle : 3 lightning talk et une partie atelier ! C’est Cyrille qui ouvre le bal.

La progressivité dans le code, par Cyrille Martraire

Cyrille nous invite à prendre conscience de la notion de « progressivité » lors de nos refactorings. Certains remaniements se font en douceur… jusqu’à se heurter à des remaniements qui s’avèrent plus brutaux !

image

Lire la suite