Seconde journée des Agile Testing Days au Seminaris Center de Berlin, et encore des interventions de haute volée.
Keynote de Mickael Bolton « Testers : get out of the quality assurance business »
Mickael Bolton, une grosse pointure dans la communauté des testeurs, se proclame « Agile skeptic » (dans le bon sens du terme).
“Pourquoi tester ? ” “Qu’est-ce que la qualité?” : ces deux questions clés vont lui permettre de revenir sur l’activité de testeur, centrée avant tout sur l‘adaptabilité et la valeur et non pas sur l’assurance qualité.
Mickael Bolton- Keynote
Le rôle du testeur est donc plutôt d’aider les personnes à considérer les différentes possibilités pour résoudre des problèmes :
“Testers are skilled investigators … we are sensory instruments”
“Testing is an on-going, continuously, re-optimizing process of exploration, discovery, investigation and learning”
Mickael prit ensuite position sur les débats récurrents : tests d’acceptation (selon lui plutôt des « rejection checks »), non regression, tests exploratoires, l’automatisation ( « only a tool »). Trés intéressant, et des positions bien tranchées !
Gojko, c’est de la dynamite !
Au depart, une session« Top 10 reasons team fail with ATDD and how to avoid them » et une salle remplie…
Gojko Adzic Session
La suite, c’est Gojko Adzic qui entre dans l’arène maniant avec dextérité ironie et second degré dans un show de 30 minutes tonitruant. Pas grand chose à ajouter : regarder plutôt ces morceaux choisis!
Anko Tijman, plus en retenue, y parvient néanmoins. Une bonne session « Mitigating Agile Pitfalls ». Après s’être attardé sur les valeurs de l’agilité, Anko a commenté les 5 pièges du Testing Agile, et les options pour les atténuer.
Anko Tijman - Agile values
Piège 1 : Ne pas tester avec le Client
Piège 2 : Ne pas tester en équipe
Piège 3 : Stratégie de test non équilibrée
Piège 4 : Exigences incomprises (avec comme actions d’atténuation:
Bon, pas forcément nouveau mais les choses sont posées. En conclusion, il nous livre ce qui permet au test agile de réussir : construire des relations solides, se concentrer sur le travail d’équipe et la collaboration, partager la connaissance. On est d’accord !
Keynote de début d’après midi : Agile Testing Certification - How could that be useful ? (par Stuart Reid, qui fut le fondateur de l’ISTQB).
Un sujet qui fait débat dans la communauté Agile Testing ; les certifications de test ont en effet de farouches opposants, pointant du doigt leur profonde inutilité … Un avis que je partage pour beaucoup. Dans la salle, pourtant, quasiment la moitié de l’assistance s’est déclarée, en levant la main, certifiée en test ! La certification semble trés populaire en Allemagne …
Stuart Reid - Keynote - Answer to Gojko (Conference private joke)
Stuart rappelle que le titre de sa session est une question : il souhaite avant tout ouvrir les débats. Le panorama des certifications existantes (agile et test) est dressé et les certifs. de l’ l’Agile Alliance en prennent un coup … Ensuite, c’est 45 minutes sur le qui, quand, pourquoi, comment d’une certification de testeur agile (et son syllabus) …
Bref, je ne suis convaincu ni par le discours ni par la potentielle certif…
Deux sessions pour lesquelles j’attendais mieux..
Celle de Cirilo Wortel « The secret sauce of agile testing in distributed teams » et d’Eric Jimminck « Implementing collective test ownership » qui sur le papier m’avaient accrochées.
Pour la première présentation, le cœur du sujet « le test agile en offshore » a mis du temps à arriver, sans pour autant être détaillé.
Cirilo Wortel
Sur la base d’un projet qui Agile-Offshore qui a marché, Cirilo nous propose les challenges à relever (compétences, culture, communication niveau people mais aussi distance, infrastructure et langage). Rien de bien nouveau mais le retour est toujours intéressant, puis il nous donne sa conclusion :
“Now for the sauce …
Testers make a killer proxy !
Testers speak the functional language
They know the domain
They have a user view
The have a birds view”
“It boosts communication !”
Bof…
La présentation d’Eric Jimminck m’a laissé un peu perplexe. Ca commençait bien avec des rappels très pertinents sur l’ATDD, et les principes de base de cette approche.
Eric Jimmink - ATDD process
La propriété collective du test consiste principalement à maintenir des tests en équipe, tout au long du process dans une approche crossfonctionnelle…
“Learning more about each other’s work and speciality”
L’impact organisationnel d’une telle approche me sembalit aussi assez juste, en revanche les trois exmples, projets décrits par Eric ne m’ont pas convaincu. Je n’ai pas du tout compris où il voulait en venir. Les bénéfices ? points saillants ? OK sur la nécessité de transformer la façon dont on aborde les besoins, les exigences sur un projet, de tendre vers l’ATDD mais pour le reste ?
Une bonne note pour terminer, Janet Gregory « About Learning » (for testers)
Le keynote de fin de journée a tenu toutes ses promesses. Plus en douceur mais tout aussi précis et efficace, Janet fait d’abord le parallèle avec l’enfance, là où apprentissage et curiosité sont ROIS !
“The motivation (to learn) that kids have is pure”
“Testers need curiosity”
Janet Gregory Keynote (you see Lisa Crispin and Linda Rising)
Pourquoi apprendre ? De quelles competences a -t-on besoin ? Janet insista sur ces compétences générales mais cruciales comme le problem solving ou le system thinking sans oublier ses valeurs clés de l’agilité : Feedback et la Communication.
“If it’s constructive the feedback is received so much better”
Sur l’imporatnce de ces deux éléments au sein des equips agiles, je la rejoins complètement
Quand, comment et où apprendre , voilà à quoi s’est efforcée de répondre Janet Gregory avec quelques idées fortes :
“Learning by doing”
“Lots of tools in your toolkit makes you prepared to solve any problem appropriately, not always use the hammer”
“Sharing the knoledge to learn… teaching is the best way to learn”
Première journée de conférence des Agile Testing days au Seminaris Center de Berlin. Quelques centaines de participants, 26 nationalités : une conférence anglophone même si dans les couloirs l’allemand se laissait facilement entendre.
Les plus grands experts du Test Agile se sont donnés RDV pour échanger sur un sujet désormais incontournable des projets SCRUM, et plus largement Agiles : le TEST.
Des Keynotes de très Haut Niveau
Pas moins de 3 Keynotes, et non des moindres, pour cette première journée avec 3 femmes à l’honneur : Lisa Crispin, Linda Rising et Elisabeth Hendrickson.
Keynote d'ouverture
Lisa Crispin s’est chargée du keynote d’ouverture : “Limbo Lower now : an agile approach to defect management”. Une ouverture en fanfare sur une question de fond et récurrente dans le cadre de nos missions de coaching : Outil de gestion des anomalies, OUI ou NON ? avantages ou inconvénients ? pour quels contextes ?
Limbo Dancing from Lisa Crispin
Après avoir présenté la vision traditionnelle des défauts, Lisa présenta les autres perspectives, agile et lean:
“Defect queues are waste. It’s inventory”
“You find a defect, fix it because bugs are technical debt”
La prévention des défauts est donc le cœur et doit constituer l’unique but de l’équipe :
« make it a Team problem »
Pour le reste c’est une affaire de contexte, et la capacité d’expérimenter plusieurs options (commencer sans DTS, fixer des règles simples comme pas plus de 10 défauts à la fois, utiliser le taskboard …) pour au final, aprés retrospective (”Inspect & Adapt”) trouver celle qui colle le mieux …
« Do that works for your team »
Second keynote avec Linda Rising en début d’après midi « Deception and estimation : how we fool oursevelves”.
Dans un style rempli d’humour et de finesse, mais sur fond de psychologie cognitive, Linda Rising démontra à quel point l’être humain est mauvais dans ses estimations. Des exemples du quotidien, et la capacité jouer avec son auditoire ont mis l’ambiance tout en assurant une démonstration efficace…
Le lien avec les projets IT : de mauvaise estimations tout simplement:
“We tend to believe we’re better than we are”
et on aurait tendance à sur estimer notre capacité de faire (analyse, dév, test…).
“Agile to the rescue”
Et c’est là que l’agilité nous sauve avec son découpage en petites étapes, son juste ce qu’il faut, son ouverture, son travail collectif et la possibilité d’expérimenter et d’apprendre de ses erreurs. Bref, être Agile permet d’atténuer, seulement, ce défaut tellement humain !
Dernier keynote de la journée avec Elisabeth Hendrickson « Lessons learned from 100+ Simulated agile transition ».
Un dynamisme hors du commun pour relater ses observations et exposer conclusions obtenues suite à la passation, plus d’une centaine de fois de sa simulation de transition agile, WordCount. Ce qui ressort de ses données: pas mal de choses à commencer par ce qui caractérise une équipe qui marche de celle qui ne marche pas, mais aussi quelques invariants : les personnes ajoutent leur propre complexité et se mettent la pression du temps, toute transition conduit au CHAOS (pour une période de temps seulement … heureusement !), les tests servent d’outil d’ajustement et permettent de s’aligner (Business / IT).
Ou encore, en version originale :
“Don’t use communication solutions for visibility problems”
(c’est parce que tu ne sais pas ce qui se passe que tu en parles !! ) A vrai dire, C’est assez juste
Dernier conseil aux coachs et facilitateurs que nous sommes : Faire confiance à l’équipe ! Lui donner l’info dont elle a besoin et savoir prendre du recul (« sortir du cercle ») sans lui dicter ce qu’elle a à faire!
“Trust the group”
Côté sessions : des confirmations
Une matinée orientée ATDD (Acceptance Test Driven Development) avec un focus sur Robot Framework, outil d’automatisation des tests, au travers des sessions de Thomas Jaspers (« Testing web applications in practice… ») puis de Pekka Klarck (« ATDD using Robot Framework »).
ATDD using Robot Framework avec Pekka Klarck
Au programme : la volonté de montrer l’excellente intégration de Robot Framework avec Hudson et Selenium pour le premier, et de bons exemples de cas de test (syntaxe BDD ou non) pour le second.
Intéressant donc … RobotFramework semble être l’outil qu’un grande partie de la communauté des testeurs semble pousser, un outil sur lequel Valtech Technology (avec Maxime, Laurent et Yannick) a beaucoup communiqué, afterwork , tutoriel, blogs ou conférence..
L’après midi, des confirmations sans plus, avec la session de Geneva Murphy « Requirements in the agile world » surtout (et un peu trop) centrée sur les outils de sa socièté HP !
Agile Requirements - Image ou Texte
Les 4 axes de la session:
“Be lean, Iterate, Visualize, Collaborate “
… on est d’accord ! Cela dit, on est resté en surface sans toucher l’essentiel et sans creuser les attentes des équipes agiles que je peux coacher…
Plus intéressante, la session de Ray Arell, « Waterfall to an agile testing Culture » avec une attention toute particulière sur la place de la dimension « Culturelle » dans un chantier de transformation Agile.
Ray aborde le sujet au travers d’une comparaison tout à fait pertinente avec le « Thru-Hiker » (”randonneur de l’extrême ?” celui qui par exemple se fait une rando du Mexique au Canada à 20 miles /jour).
Agile Testing Culture - Ray Arell
Même plan, même préparation, même but, même rythme, l’équipe Agile et le « Thru-Hiker » cherchent tous deux à éviter le danger et vont avancer en s’appuyant sur des succès incrémentaux.
Bref, sans la culture Agile (représentée selon Ray entre autres par un rythme soutenable, un environnement de confiance, un espace ouvert et de collaboration, la motivation…), ça ne marche pas ; un point dont je suis intimement convaincu.
Trop d’organisations veulent aujourd’hui « faire de l’agile » pour en récolter les bénéfices mais surtout sans efforts et sans remise en cause de la culture organisationnelle. Mon message : « Dégrader l’agilité et vous obtiendrez des résultats … dégradés ! ».
Seuls les efforts paient ; pour avoir des résultats, il faut travailler encore et encore et … faire des efforts !
L’agilité entre aujourd’hui en force dans les organisations (qui n’y sont pas toujours prêtes) et modifie notre façon de concevoir des produits, et de mener un projet informatique. De ce fait, le test agile est un sujet plus que jamais d’actualité ; une vraie problématique à laquelle les équipes Agile, et donc moi-même en tant que coach Agile, sommes inévitablement confrontés.
C’est pourquoi je suis trés impatient de participer, pour Valtech, la semaine prochaine aux Agile Testing Days de Berlin. Cette conférence: c’est 4 jours (4-7 octobre) d’intenses échanges au cours desquels se succéderont présentations, ateliers de travail et discussions informelles avec des praticiens passionnés par l’Agilité, la qualité et les tests logiciels.
On y retrouvera aussi les plus grands experts internationaux du Test Agile avec entre autres Lisa Crispin, Michael Bolton, Janet Gregory, Linda Rising, Elisabeth Hendrickson ou encore Gojko Adzic …
On dit toujours que l’agilité met l’accent sur la qualité. C’est vrai :
des pratiques telles que l’intégration continue, les tests unitaires, les tests de recette, le pair programming mais aussi une volonté évidente d’automatisation jouent indéniablement sur la qualité du produit logiciel…
le client sur site et de courtes itérations, pour plus de collaboration et de feedback permettent de s’assurer que le “bon produit” est développé…
Avec l’ajout d’un regard Lean et d’une approche ergonomique, le compte est souvent bon…
ET POURTANT dans les faits, stratégie de test et testeurs ont du mal à se retrouver dans les projets Agiles, comme si toute une approche qualité était occultée, menée de manière anarchique, sans ligne directrice… ça doit changer; ça va changer !
VERS UNE NOUVELLE VISION DES TESTS DANS LES PROJETS AGILES… trois éléments déterminants
Intégrer les testeurs dans l’équipe Agile et enrichir leur rôle (à la fois plus proches et au service de l’équipe mais aussi en soutien fort du Product Owner, du Métier). Cette alerte Agile (Où sont les testeurs) allait dans ce sens, et les résultats sont le plus souvent probants.
Donner un nouvel élan à la stratégie de test dans une dynamique agile. La stratégie de test se doit d’abord d’être envisagée dans une dimension high level en Sprint 0 pour l’ensemble de la version (une version, c’est entre 3 et 6 mois). Ensuite, le challenge du testeur est de l’ajuster en contexte à chaque début de sprint, en fonction du contenu du sprint à venir et de ce qui a été qualifié de Done au sprint précédent. A ce niveau, on va à l’essentiel : la stratégie de test, niveau sprint a la particularité d’être à la fois synthétique et trés précise !
S’appuyer sur le génialissime modéle de Brian Marick (signataire de l’Agile Manifesto et Star de la qualité logiciel) pour formaliser cette stratégie de tests. A chaque sprint, piocher son type de tests dans tel ou tel quadrant. Un modèle, trés visuel, instantanément compréhensible et trés parlant non seulement par le spécialiste QA qui sommeille en vous, mais aussi par toute personne impliquée dans un projet informatique.
4 quadrants (initiés par Brian Marick, repris par Lisa Crispin & Janet Gregory dans l’excellent ouvrage Agile Testing) qui à eux seuls guideront l’ensemble de votre stratégie:
Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
Tests orientés Business en soutien de l’équipe (ex: les tests sur storyboard, les tests fonctionnels pour vérifier les critères d’acceptation du Product Owner: l’approche de conception centrée utilisateurs et l’ergonome y trouvent leu compte)
Tests orientés Business pour critiquer le produit (c’est avant tout du manuel, à tout moment ou en End Game pour le systéme complet en test d’acceptation. L’approche ergonomique ressort encore : quand on vous dit qu’il faut faire des Tests Utilisateurs !)
Tests orientés Technologie pour critiquer le produit (des tests essentiels qui se doivent d’être outillés et qui peuvent nécessiter la présence de spécialistes, perf / sécurité; souvent en End Game hormis simulations)
(Conference private joke)
