Last update: 22/03/2016 21:18

Tester en mode agile; testing chaotique

Non, le titre de ce billet n'est pas de prétendre que les tests menés en mode agile sont des tests chaotiques! Il s'agit plutôt de méthodes complémentaires déjà mises en oeuvre dans de très nombreux cas et qui a présidé à la création de produits bancaires ambitieux, notamment pour des fusions de banques (Italie), la création d'un Compliance Filter (Suisse), ou enfin la mise au point d'un EAI financier, labellisé Gold par Swift en 2005. Ces modes de testing ont aussi été mis à profit dans le cadre de la société FastWrite pour la mise au point d'une collection de logiciels, la collection « Je Gre… », entre les années 1989 et 1995. Ces références donnent tout le poids nécessaire aux techniques présentées.

Testing Chaotique

Commençons par cette notion que nous avons utilisée chez FastWrite entre 1989 et 1995 sans en connaître le nom qui ne nous est venu que bien plus tard lorsqu'un article nous est apparu dans lequel on se reconnassait entièrement: tiens, c'est exactement comme ça qu'on fait!

Éclairons immédiatement le contexte. Entre 1989 et 1995, en tant que directeur technique de la société FastWrite, j'ai été amené à gérer l'ensemble du développement de la collection « Je Gre… », une collection de 23 produits dont des « Je Gre… Mes Factures », « Je Gre… Mes Rappels », « Je Gre… Mon Stock », « Je Gre… Mes Clients & Fournisseurs », …

FastWrite a vendu environ 300000 logiciels de cette collection avec — à titre d'exemple — plus de 20000 logiciels de gestion de facture [1] et au final la société n'a dédié une personne au support technique qu'à raison d'un cinquième de son temps. Entendons-nous bien! 300000 logiciels = 0.2 FTE [2] … voilà la formule.

Comment était-ce Dieu possible? La réponse est immédiate: parce qu'aucun bug (PAS UN SEUL BUG, vous avez bien lu) ne nous est jamais parvenu. La seule occupation du support technique était de répondre à des questions (notamment des questions relatives à des crashs disque) ou à expliquer aux utilisateurs (utilisateurs grand public, sans expérience PC) des notions de base comme créer un répertoire, effacer un fichier, etc.

Voilà qui plaide pour la méthode: le testing chaotique. Mais, au fond, quelle était cette méthode?

La méthode était simple et dès ce moment-là nous faisions de l'agile sans le savoir [3] : nous utilisions nos propres softs! On ne parle PAS de les tester! On parle de les utiliser!

Ainsi, pas de plans de tests! Pas de test cases (cas de test)! Pas de rapport formel d'exécution des tests, pas de … MAIS à la place, nous étions en tests continus AVEC les utilisateurs (nous- mêmes dans ce cas précis). Par exemple, nous gérions notre propre entreprise avec « Je Gre… Mon Budget{{{»}}}, notre gestion de clients se faisait avec « Je Gre… Mes Clients & Fournisseurs », pareil pour nos fournisseurs, nos factures étaient établies avec « Je Gre… Mes Factures », etc.

Les utilisateurs de nos propres solutions étaient assis juste à côté des développeurs (vous retrouvez cela aujourd'hui dans les principes exposés dans les méthodes agiles, cfr. Agile Manifesto). Dès qu'une fonctionnalité avait été développée, on compilait le programme, on mettait le tout sur une disquette (nous n'avions pas de réseau à cette époque!), on copiait le programme sur le disque dur de l'utilisateur, on lui expliquait la nouvelle fonctionnalité (laquelle pouvait soit venir de l'équipe de développement, soit des utilisateurs [4] ) et en avant pour les tests [5] ! Cette méthode a été pratiquée par Jean-Marc Simon, Fanny Sadouni, Pascale Picard, Bernard Rosenberg pour les utilisateurs. Par Bernard Feuillen, Jean-Pol Lintelo, Pierre-André Damas, et moi-même pour les développeurs.

Vous pouvez penser qu'une telle méthode ne peut s'appliquer qu'à des produits d'une simplicité extrême mais, en fait, pas du tout car tous ces programmes interagissaient les uns avec les autres. Ainsi, si on disposait de « Je Gre… Mes Clients & Fournisseurs », alors « Je Gre… Mes Factures » pouvait tenir compte des données des clients et des fournisseurs, si ce n'était pas le cas, peut-être que « Je Gre… Mes Adresses » était installé ou alors « Je Gre… Mes Contacts », etc. Comme nous avions comme cela 23 logiciels, la complexité de maintenir tous ces systèmes alignés les uns avec les autres s'accroissait très vite. Et jamais nous n'avons mis au point d'autre méthode de testing avec, pour résultat, 1/5 d'un équivalent temps plein dédié au support technique!

Pourquoi chaotique?

En quoi cette méthode peut-elle être qualifiée de chaotique? Elle est chaotique parce qu'elle parait non organisée, parce qu'elle ne suit pas un plan préétabli, parce qu'elle est contraire à l'entendement: ce sont les utilisateurs qui décident quoi tester et comment le tester. Le parcours de test se fait au feeling, mais TRÈS rapidement (dès la disponibilité de la fonctionnalité), tout au long de la conception. TOUT AU LONG DE LA CONCEPTION. J'insiste.

Et la couverture des tests dans tout cela?

Cela génère des questions biens légitimes. La première est de savoir si la méthode permet de s'assurer que tout a été testé. Dans la foulée on se pose aussi la question de savoir si tout a été testé à fond. Enfin, on se pose la question de savoir si toutes les variations ont été éprouvées, si les cas positifs ET les les cas négatifs ont été passés en revue, si les utilisateurs se sont penchés sur des tests plus techniques (le non fonctionnel comme la taille des DBs, la purge des fichiers de log, la performance, …). Voilà, je le répète toutes des questions qui nous taraudent et auxquelles on est en peine de répondre.

Le temps et le hasard à la rescousse

Malgré la justesse de ces questions, nous sommes bien forcés de reconnaître la puissance et la force du concept jusque dans ses fondements les plus scientifiques. Nous savons que la Nature fonctionne de cette manière; nous mettons au point des algorithmes génétiques basés sur ce même principe et nous OBSERVONS que ces algorithmes, après plusieurs générations, battent les algorithmes dits intelligents. Nous voyons dans nos jardins mêmes le principe à l'oeuvre avec ces tondeuses robot qui parcourent la surface à tondre quasiment au hasard et qui au final auront tout tondu. La réponse est simple et élégante: le temps et le hasard! C'est parce que le mécanisme est au travail pendant suffisamment longtemps qu'il assure qu'effectivement tout a été ratissé. C'est aussi parce qu'il y a une forme de hasard qui est à l'oeuvre qu'on s'assure que le chemin parcouru possède les variations nécessaires.

C'est parce que Pascale Picard n'utilisait pas « Je Gre… Mes Factures » de la même manière que Jean-Marc Simon que de subtiles variations faisaient leur apparition. C'est parce que Pascale utilisait davantage « Je Gre… Mon Budget{{{»}}} (mis en relation avec « Je Gre… Mes Factures ») qu'on découvrait des manquements dans « Je Gre… Mes Clients & Fournisseurs »! C'est donc surtout grâce à l'absence de plan que le hasard pouvait s'inviter. Par les plans de test, par les test cases on tue justement le hasard, on ne lui permet plus de s'exprimer, d'être à l'oeuvre. Évidemment, on fait cela par pur cartésianisme, par pure volonté de déterminisme. Wrong!

Et vous étiez sûrs de votre coup?

Chaque produit de la collection « Je Gre… » était vendu en grande surface, sur disquette. Pensez seulement à toute la logistique impliquée dans un release: acheter des milliers de disquettes (à l'époque on ne trouvait même pas à acheter des disquettes en quantités suffisantes), les faire livrer chez le duplicateur (dont les machines, rares, coûtaient des fortunes), amener le master chez le duplicateur (la notion même de master n'existe quasi plus), effectuer un contrôle de qualité de la duplication, faire livrer les disquettes dans un atelier protégé qui allait s'occuper de rassembler les différentes pièces (la jaquette de plastique, les fiches d'enregistrement des produits, la disquette, coller les étiquettes produit sur les disquettes, …), conditionner les produits par boîte / présentoir, et enfin, s'occuper du réassort des produits dans les grandes surfaces (c'est Jean-Marc Simon et Marc Germann qui prenaient leur petite voiture et s'en allaient visiter les points de vente pour y mettre les nouveaux produits et compléter les autres déjà partiellement vendus). Vous pensez réellement que nous avions envie de recommencer tout cela pour un stupide bug? Voilà qui nous encouragait à être extrêmement prudents avant de prendre la décision de release, vous pouvez me croire! Oui, nous étions sûrs de notre coup [6] !

Alors du testing chaotique et basta?

Non et surtout pas! Nous avons besoin de nous rassurer. C'est primordial. Essentiel.

Mais nous pouvons utiliser le Testing chaotique en combinaison avec un testing plus formel, surtout dans les organisations dont l'écosystème est un peu plus rigide.

Ainsi, dans des organisations plus waterfall je suggère de se donner les moyens d'un testing chaotique en permettant par exemple au personnel interne d'utiliser les applications le plus rapidement possible. Dans de grandes organisations, on peut facilement s'adjoindre des dizaines de "testeurs" qui ne sont pas sur le budget du projet. Une sacrée manne. À méditer!

Le testing chaotique consiste à permettre aux utilisateurs d'utiliser le produit dès le début de sa conception, fonctionnalité par fonctionnalité, avec une boucle de feedback ultrarapide entre les utilisateurs et les développeurs. Les utilisateurs testent les fonctionnalités sans aucun plan, sans rapportage formel. La période de testing est étendue à l'ensemble de la période de construction du produit, une période singulièrement plus longue que ce qu'il est communément entendu. Ce sont les utilisateurs qui décident du moment où le produit est prêt.

Testing en mode agile

Maintenant que nous avons vu rapidement en quoi consiste le testing chaotique et que nous avons vu qu'en définitive on est déjà en mode agile, voyons justement en quoi consiste un mode agile pour le testing.

Une petite mise en garde ici! il existe quantités de méthodes agiles. Nous restons ici sur les principes généraux des méthodes agiles: nous n'entrons pas dans le débat de SCRUM, de Extreme Programming, de DSDM, … Par ailleurs ce que je vais vous présenter ici c'est finalement une articulation entre testing agile et waterfall. Voyons-en les principes de base.

En méthode agile, le scope du produit à construire évolue constamment [7] : on ajoute des choses, on retire des choses, on change les choses … tout au long du projet [8] . Ce paradigme ne permet pas de finaliser un cahier des charges au début de la phase de construction et dès lors cela ne permet pas non plus d'établir les cas de tests. Il y a donc lieu de trouver un processus qui permet d'établir les cas de test au fur et à mesure de la construction, ce qui, soit dit en passant, permet de minimiser le travail d'élaboration des cas de tests aux seules fonctionnalités réellement développées.

Nous retenons de ce que nous venons de voir que les cas de tests sont élaborés PENDANT les itérations.

La méthode chaotique exposée plus haut donne une indication précieuse sur le rythme des tests: dès qu'une fonctionnalité est prête elle est mise en test! Oui, certes … mais SANS test case! Ce sont vos utilisateurs qui testent, pas des testeurs patentés. Ceux-là préparent effectivent des test cases durant toutes les itérations et à des intervalles réguliers on organise une démo de ce qui a été développé jusque là: c'est le cycle d'une itération (un sprint en SCRUM) et qui correspond au principe #3 de l'Agile Manifesto … Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Lorsque la construction commence, on sait grosso modo ce par quoi on va commencer. C'est l'itération #1. Celle-ci se ponctue par une démo de tout ce qui a été développé pendant cette période. Pendant toute l'itération les testeurs préparent les cas de tests qui seront, du moins partiellement, utilisés lors de la démonstration qui ponctue l'itération. Ils préparent aussi le scénario de la démo sur base des choses qui ont été développées. C'est un ajustement constant avec les développeurs. Il est donc impératif d'avoir des testeurs très proches de l'équipe de développement et comme les développeurs doivent être proches des utilisateurs on en déduit très aisément un principe d'unicité de lieu (ce qui n'empêche pas pour autant le travail near-shore ou off-shore, mais c'est un autre débat qui dépasse ce petit billet). Les test cases qui sont ainsi élaborés durant l'itération servent à la démo … mais on les exécutera de manière formelle pendant l'itération suivante.

En résumé, pendant l'itération n, les testeurs préparent les test cases de l'itération n; ils utilisent ces test cases pour la démo de l'itération n, démo dont ils ont préparé le scénario sur base des fonctionnalités réellement développées par les programmeurs. Durant l'itération n + 1, ils exécutent les cas de test de l'itération n de manière formelle. Les anomalies détectées servent à alimenter au fur et à mesure les choses à faire durant l'itération n + 1 sans grand formalisme (pas de QC, pas de Defect Management Meeting, …). L'itération 1 est un peu spéciale. Puisqu'il n'y a pas vraiment d'itération qui la précède il n'y a donc pas non plus de cas de tests à exécuter.

Fin d'itération

La fin d'une itération est, d'un point de vue "testing", particulièrement intéressante. Les instigateurs des méthodes agiles disposent de tout un arsenal de méthodes. SCRUM propose ainsi qu'à la fin de chaque itération on dispose d'un produit partiel potentiellement livrable; on trouve aussi un phrasé légèrement différent par produit partiel potentiellement utilisable. eXtreme Programming parle de releases, chacun ponctué de tests. La Business Practice 3 dit At the end of each iteration, after the software passes all acceptance tests, release the software to the customer. Ceci suggère donc que des tests d'acceptance soient pris en compte ET que le release soit amené au client. Cependant, le chapitre 10 d'Extreme Programming dit Releasing software is special, especially if it doesn't happen at the end of every iteration, as in the case of shrink-wrapped software development. Et ceci suggère une autre voie, à savoir qu'à la fin d'une itération il se pourrait bien que tous les tests d'acceptance n'aient PAS été suivis ET que les activités de release officiel, si elles sont trop lourdes à réaliser à chaque itération (c'est le cas évident des software shrink-wrapped) n'aient PAS lieu non plus. C'est la voie que je suggère! ce qui ne remet pas en cause le moins du monde le principe de la démonstration afin de recueillir le plus tôt possible le feedback du client. Si on conjugue cela avec le testing chaotique, alors nous venons de mettre au point une méthode qui respecte à la lettre les principes agiles tout en simplifiant encore la méthode (au sens LEAN du terme).

La fin de toutes les itérations

À la fin des itérations (moment finalement décidé par les utilisateurs) on est en possession d'un produit. Faisons l'hypothèse que le produit est exploitable. C'est ici qu'on peut enchaîner avec des cycles de tests plus conventionnels, plus formels comme l'établissement d'une période de FAT et d'une période UAT. C'est exactement là qu'on quitte le mode agile pour retomber en waterfall. C'est ce que je suggère, au moins pour la phase FAT. En effet, nous avons fait l'économie de phases plus formelles telles que préconisées par SCRUM ou eXtreme Programming (quoique dans une moindre mesure) et il est maintenant temps de réinvestir un peu de notre épargne passée. Par ailleurs, la phase FAT contribue aussi à rassurer tout le monde … en se concentrant sur des tests de non régression.

À la fin de la période de tests agiles on peut passer à des revues plus formelles comme des périodes de FAT, UAT, et/ou BAT …). En période de FAT on consolide tous les cas de tests développés durant les itérations et on se focalse sur du regression testing (puisque le produit a été testé tout au long du cycle de construction/développement). On réinvestit dans ces phases un peu de notre épargne passée.

Références

Je ne vais pas établir ici une bibliographie des techniques agiles. Je vais me contenter de vous dresser la liste des projets sur lesquels ces techniques (Agile Testing + Chaotic Testing) ont été appliquées avec un succès indéniable:

Notes de bas de page

[1] … À tel point que « Je Gre… Mes Factures » était de loin le logiciel de facturation le plus vendu à l'époque, loin devant les ténors qu'étaient les Cubic et autres Popsy!

[2] … Fill Time Equivalent

[3] … Nous sommes en 1989, 1990 alors que l'Agile Manifesto est né d'une rencontre organisée entre les 11 et 13 février 2001 dans les montagnes Wasatch de l'Utah, soit une bonne dizaine d'années avant la naissance officielle de l'Agile

[4] … Une autre brèche: les développeurs mettaient dans les produits autant de fonctionnalités qu'ils le souhaitaient, après un bref conciliabule, et par "fonctionnalités", il faut entendre toutes ces fonctionnalités purement techniques que les utilisateurs seuls sont incapables d'imaginer

[5] … Pas vraiment de tests purs, plutôt une utilisation intensive

[6] … Et il le fallait bien parce que GB, Colruyt, Tandy, la FNAC, et tous les autres ne nous auraient pas pardonné l'erreur. Parce que SONY, avec qui nous avons réalisé une action promotionnelle sur « Je Gre… Mes Disquettes{{{»}}} sur 10000 pièces, nous aurait jeté comme des malpropres

[7] … Ce qui en fait aussi le charme, bien apprécié par le business, un peu trop même, jusqu'à parfois confondre agilité et contorsionnisme

[8] … Une discussion récente avec un représentant IT me pousse à souligner ce fait en rappelant pour qui le souhaiterait le principe #2 défendu par le Agile Manifesto: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage"

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X