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”
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)
vers des exigences d’ergonomie…
Ceci est le dernier volet de ma série consacrée au traitement de cette exigence “L’interface doit être conviviale” avec un focus sur les exigences ergonomiques, le test I.H.M. et le test d’utilisabilité (”user testing” ou “usability testing” en anglais).
Une exigence (”ce que le système doit faire”) doit, dans sa forme, être non ambigue, mesurable et vérifiable. Dans mon précédent billet, je vous présentais la stratégie à adopter pour préciser et requalifier une exigence imprécise en d’autres types d’exigences, dont les exigences d’ergonomie. Voici donc quelques exemples d’exigences d’ergonomie, accompagnées de leur mode de vérification:
L’application devra se conformer à la nouvelle charte graphique ABC (Test I.H.M.)
L’interface doit prévenir l’accès de l’application par des automates (logiciels dits robots) (Test I.H.M.)
La nature hiérarchique des informations doit être présentée aux utilisateurs (Test I.H.M. / Test d’utilisabilité)
Le tunnel de conversion une fois entamé ne doit pas avoir plus de 15% d’abandon (Test d’utilisabilité)
L’application devra proposer sur tous les écrans un accès permanent aux principales rubriques et aux utilitaires (Test I.H.M.)
Le temps pour effectuer la tâche A doit être inférieur à celui sur la version précédente (Test d’utilisabilité)
L’application devra proposer des écrans et moyens d’interaction cohérents (Test I.H.M.)
Les utilisateurs devront donner à l’application une note de satisfaction supérieure à celle de la version existante (Test d’utilisabilité)
90% des utilisateurs devront réussir la tâche A sans erreur (Test d’utilisabilité)
Je distingue pour ma part (Watkins ne parle quant à lui que de “Test de convivialité” - tiens tiens “convivial”) deux modes de vérification de ces exigences: Test I.H.M. et Test d’utilisabilité. Pourquoi cette distinction ?
Disons déjà qu’on ne teste pas forcément la même chose et qu’on ne couvre pas les mêmes exigences. Ensuite, les coûts, techniques et moyens à mettre en oeuvre sont différents. Enfin le test d’utilisabilité nécessite la présence d’un ergonome pour préparer, conduire et analyser ce type de test bien particulier.
Les Tests I.H.M. ont pour but de vérifier entre autres la bonne application des régles, principes définis dans une charte d’ergonomie ou dans tout autre livrable d’ergonomie (écrans, cinématique). Plus précisément, ils vont donc vérifier la présentation visuelle (menus, paramètres d’affichage, propriètés des fenêtres, résolutions d’écran, effets de bord, position des éléments, format des tableaux, des objets…), la navigation et les interactions (par saisie, menus, claviers, déplacements dans l’écran, touches Tab, raccourcis, liens, breadcrumb, enchaînement des écrans…)
Ces tests peuvent être réalisés par un testeur (ou mieux un ergonome) sur la base d’une documentation précise.
Les tests d’utilisabilité consistent à observer en situation quasi réelle l’utilisation de l’application par des utilisateurs représentatifs. Je glisse dans cette catégorie les interviews des utilisateurs à propos du produit à concevoir ou évaluer. Plus précisément, ces tests ont pour but de valider l’acceptation, de vérifier la perception et la compréhension des contenus et fonctionnalités, des moyens de navigation, et la facilité d’utilisation. Ils cherchent aussi à vérifier le respect de certaines exigences d’ergonomie plus précises sur la base de métriques (nombre d’erreurs, temps de réalisation d’une tâche, satisfaction exprimée) relatives à la facilité d’utilisation, de compréhension ou d’apprentissage.
Ces tests doivent être menés par des ergonomes, à tout moment du cycle de vie logiciel (itératif, c’est mieux ou en cascade). Ces tests sont au coeur de la norme ISO 13407 (Conception Centrée sur l’Homme).
Le choix entre ces deux types de test sera fonction notamment de l’exigence à tester et de la stratégie de test avancée.
Actualiser ses connaissances, envisager d’autres points de vue, me paraît primordial. Aujourd’hui marquait le début de deux formations que je vais suivre : Stratégie des Tests (sur 3 jours) et Test & Validation du logiciel (l’UE du CNAM en cours du soir jusqu’au mois de juin).
Dans les deux cas, je n’échapperai pas à des choses connues, déjà vues et revues: ce fut le cas pour l’essentiel de cette première “grande” journée (11 heures de formation au total!); même s’il n’est pas toujours inintéressant de se voir présenter les choses sous un angle différent.
Toutefois la suite s’annonce meilleure… Pour le première formation, focus sur l’intégration du test dans le processus itératif avec études de cas (qui répondront peut être à certaines questions que je me pose) et retours d’expèrience sur les problématiques offshore. Pour la seconde, celle du CNAM, l’étude plus détaillée des techniques de test et des aspects propres au développement : tests unitaires, intégration, automatisation.
Bref, une belle complémentarité.
(Conference private joke)
