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

Note de lecture : Specification by Example, par Gojko Adzic

Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !

Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.

Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.

L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).

Lire la suite

Agile France 2014, Bonus Track

Comme chaque année, il y a de nombreuses sessions que je n’ai pu voir. Je vais tenter d’y remédier en partie dans ce post.

Pour rappel les autres présentations, celles auxquelles j’ai assisté, sont couvertes ici et ici pour la journée du Jeudi. Elles sont ici et ici pour le Vendredi.

Projets Agiles, arrêtez les dérives

Cyrille Deruelle, en plus de sa présentation sur l’amélioration continue, a proposé ce sujet sur les projets agiles. Quelques clés et rappels pour ne pas pervertir nos pratiques et garder le cap sur ce qui est important.

Patrick Bobo a par ailleurs développé le contenu de cette session dans un post.

Lire la suite

Carnet de route : Agile France 2014 (3/4)

Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.

De bon matin…

De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.

image

Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…

image

Assez plaisanté ! La journée va commencer, place à la keynote !

Coaching Teams Through Change

Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.

Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !

image

Le début d’un changement

Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.

Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.

Lone rangers et development owners

Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.

L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé.
Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !

Gold card

A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.

Ce que j’en ai pensé

Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :

  • Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
  • Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !

Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !

Le mythe du framework agile

Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !

Le framework maison

Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !

image

Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain !
Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !

Citons dans le désordre :

  • Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
  • Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
  • pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…

Qu’en est-il des « full stack » reconnus ?

Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !

Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.

Ce biais a des conséquences, on va le voir bientôt.

D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.

Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.

En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !

Bref nous obtenons :

  • Des architectures monolithiques.
  • Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
  • Des couplages forts avec la représentation et la base de données.
  • De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
  • Une testabilité rarement au rendez-vous.

Mais alors, c’est quoi un framework agile ?

Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.

  • Elle doit nous permettre de retarder les décisions
  • Elle minimise les couplages.
  • Elle est facile à changer.Elle est testable (via TDD et ATDD)

Une proposition et des inspirations

Pour Jean-Baptiste Dusseault, une telle architecture c’est :

  • Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
  • Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
  • Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.

Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…

La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.

Ce que j’en ai pensé

Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !

Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses

Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !

Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !

image

Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :

Les gens se foutent de la manière dont nous résolvons les problèmes.

Au hasard des améliorations, on va trouver :

  • « t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
  • Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
  • Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
  • Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
  • Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !

Les conclusions de Cyrille

  • Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
  • Il n’y a pas de choses simples : l’amélioration continue est une quête !
  • Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
  • Mesurer l’impact d’un problème, c’est déjà 50% de la résolution

Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !

Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !

Ce que j’en ai pensé

Une très bonne session : amusante et instructive. Bravo !

Refactorer du Legacy

Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».

image

Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :

  • On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
  • On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
  • On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
  • On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
  • Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
image

Ce que j’en ai pensé

Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.

J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.

Pause déjeuner

Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.

  • Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
  • Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
  • Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
  • Ils ont beaucoup d’autonomie et sont entreprenant.
  • Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.

Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !