Last update: 02/06/2016 13:53

Chaotic Testing

Early release

Testing chaotique

Ce papier fait suite à un billet concernant des techniques de tests agiles mêlées à des techniques de tests libres. Dans ce billet, je parlais de Chaotic Testing. Il m'a alors semblé nécessaire de présenter la technique de manière plus détaillée.

Préambule

Le Chaotic Testing est donc né dans les années 1989, 1990 [1] dans la société FastWrite. À cette époque personne n'était conscient de mettre au point une nouvelle méthode de testing. La méthode mise en place nous a simplement paru naturelle. Personne chez FastWrite ne parlait de Chaotic Testing.

Le terme même de Chaotic Testing est sorti d'une discussion avec Didier Vermeersch, Product Manager de la suite Office chez Microsoft. Didier me parlait effectivement d'une nouvelle version de MS-Word dont certaines fonctionnalités allaient me ravir. J'ai déduit de cette discussion que le personnel – pas un petit groupe restreint de testeurs – avait la possibilité d'être au contact d'un nouveau produit très vite dans le processus de construction. J'ai dès lors fait le parallèle entre cette méthode et celle utilisée pour la collection « Je Gre… » chez FastWrite. Je situe cette discussion en 1996.

Depuis lors, j'ai eu l'occasion d'avoir recours à cette technique à de très nombreuses reprises et chaque occasion a permis de l'affiner, d'en déterminer les prérequis et les contextes de situation.

Je n'ai malheureusement pas connaissance d'applications de cette technique à un autre domaine que la création de programmes informatiques. Je lance donc un appel à témoignages.

Objectifs du Chaotic Testing

Le Chaotic Testing a pour objectif de garantir la plus haute qualité d'une application informatique au coût le plus bas possible [2] . La plus haute qualité est obtenue par la détermination la plus précoce possible du plus grand nombre possible d'anomalies, de manquements et d'inadéquations.

Corollaires des objectifs du Chaotic Testing

On comprend des objectifs du Chaotic Testing que la méthode ne vise pas uniquement l'élimination des bugs. Le Chaotic Testing considère en effet que la plus haute qualité de l'application ne s'obtient qu'en en chassant tous les dysfonctionnements [3] . La méthode va même au-delà en favorisant l'émergence de suggestions.

La méthode vise également à la stricte maîtrise des coûts. Puisqu'on sait que le coût de résolution d'un dysfonctionnement croît de manière significative en fonction du moment où il est découvert, la méthode s'emploie donc à essayer de découvrir les dysfonctionnements le plus rapidement possible. Cela coïncide avec les objectifs affirmés des méthodes agiles.

Il est communément admis que le coût de construction d'un système est proportionnel à son niveau de qualité (notamment). Les moyens des entrepises n'étant pas infinis, il y a lieu de rechercher le "zéro défaut" (ou de s'en rapprocher le plus possible) à un coût acceptable. Le Chaotic Testing vise cet objectif mais sans impact sur le coût ou avec un impact négligeable.

Définition du Chaotic Testing

Le Chaotic Testing est une méthode de testing qui multiplie les conditions d'utilisation d'un système jusqu'au point où il pourra être déclaré final par ses utilisateurs. La méthode est non intrusive et ne génère pas (ou très peu) de coût pour le projet qui la met en œuvre.

Chaotic Testing: les prérequis

Prérequis #1: la méthode de Chaotic Testing est une compagne naturelle des méthodes agiles. Pas de méthode agile, pas de Chaotic Testing!

Prérequis #2: la méthode de Chaotic Testing s'applique au Chaotic Testing jusqu'à ce que les utilisateurs puissent déclarer la méthode comme fiable. Tant que l'organisation n'a pas bâti sa confiance en la méthode elle devra compléter le Chaotic Testing par d'autres méthodes plus systématiques.

Prérequis #3: le Chaotic Testing s'applique aux systèmes interactifs. Pas d'opérateur humain, pas de Chaotic Testing.

Chaotic Testing: les règles

Règle #1: les utilisateurs invités à utiliser le système doivent l'être sur base volontaire.

Règle #2: les utilisateurs sont "recrutés" tout au long du projet sans limite ni dans le nombre ni dans le temps.

Règle #3: aucune obligation ne peut être imposée aux utilisateurs.

Règle #4: l'utilisation du système doit être possible dans la plus grande variété de conditions possible.

Règle #5: la multiplication des conditions d'utilisation s'obtient par l'allongement de la période d'utilisation (le temps), par la prolifération des profils d'utilisateurs (la quantité), par la fluctuation des conditions initiales (effet papillon) et par les voies d'exploration (conditions d'utilisation).

Règle #6: une boucle de feedback doit être organisée entre les utilisateurs et l'équipe de projet. Le feedback doit être le plus direct possible. Il est conseillé d'inclure dans le produit à tester les moyens mêmes par lesquels la boucle de feedback est favorisée.

Règle #7: la boucle de feedback doit être possible sans nécessité d'unicité de lieu, ni de simultanéité.

Règle #8: le Chaotic Testing ne doit être soumis à aucun plan (à aucune tentative d'influer sur son déroulement) sous peine d'escamoter le hasard. Le Chaotic Testing peut faire partie d'un plan plus large. En d'autres termes … à l'intérieur du Chaotic Testing, pas de plan; à l'extérieur du Chaotic Testing, tous les plans qu'on veut.

Règle #9: il faut disposer de suffisamment de temps et d'utilisateurs différents pour que le Chaotic Testing puisse exprimer des résultats fiables.

Règle #10: toute variation d'utilisation du système est souhaitable et souhaitée parce que les variations engendrent de nouvelles voies d'exploration. On accueille donc avec bienveillance de nouveaux utilisateurs, de nouvelles conditions, des moyens nouveaux, …

Règle #11: le Chaotic Testing se pratique dans une certaine forme d'isolation dont l'objectif est de protéger l'écosystème du Chaotic Testing d'autres environnements et inversément. Il faut empêcher le Chaotic Testing d'empièter sur les environnements des utilisateurs, des développeurs, des autres testeurs. L'inverse est également vrai.

Règle #12: le Chaotic Testing peut se pratiquer sur des environnements de production tout en veillant à la stricte application de la règle #11. Le Chaotic Testing ne doit pas être mis en œuvre sur des environnements de production AVANT que l'organisation ait bâti une large expérience en Chaotic Testing (prérequis #2).

Pourquoi chaotique?

Le temps, le hasard et les utilisateurs sont les composantes essentielles du système.

Disposer du plus grand nombre d'utilisateurs différents et disposer du temps nécessaire voilà qui favorise une utilisation désordonnée du système à tester. Cela garantit la pleine expression du hasard pour couvrir le maximum de voies d'exploration et explique donc le caractère chaotique du système.

Le temps permet donc l'expression du hasard et la variation des conditions initiales. Au fil du temps les utilisateurs modifient leur comportement et donc l'utilisation qu'ils font du système, en fonction de l'expérience acquise. Le temps peut donc aussi restreindre l'expression du hasard lorsqu'il agit par resserement des conditions d'utilisation. C'est ce qui se passe pour les utilisateurs expérimentés qui perdent ainsi avec le temps leur caractère "néophyte". C'est la raison pour laquelle la règle #2 doit être favorisée.

Le système est dit chaotique parce qu'il s'appuye grandement sur le hasard lequel doit avoir suffisamment d'occasions de se manifester dans des conditions différentes pour garantir une couverture suffisante des domaines d'utilisation de l'application.

Agilité et Chaotic Testing

Le Chaotic Testing est intrinsèquement lié aux méthodes agiles mais ne saurait se confondre avec elles. Un contexte agile est donc indispensable au Chaotic Testing. C'est ce qu'exprime le prérequis #1.

Néanmoins, le Chaotic Testing n'est pas nécessairement synchronisé avec la méthode agile mise en œuvre et plus particulièrement synchronisé avec les fins d'itération. Rappelons encore à cet effet que le Chaotic Testing doit se pratiquer en "isolation".

La boucle de feedback mise en place doit cependant permettre la prise en compte des AMIS [4] tout au long des itérations.

Le Chaotic Testing et la réduction des coûts

L'utilisation du Chaotic Testing se donne pour ambition de (1) réduire les coûts de construction d'un système ET (2) d'obtenir le "zéro défaut".

Decouverte des problèmes le plus tôt possible

Il y a lieu de découvrir les problèmes, le plus vite possible.

Un chapitre entier serait nécessaire à la précision entendue par le terme problème. Cette précision échappe cependant à la portée du présent article. Je me contenterai donc d'inviter le lecteur à considérer le terme problème au sens large (lato sensu) et de ne pas le réduire à la seule anomalie [5] comme il est habituellement considéré dans les autres techniques de testing. Par problème j'entends tout comportement problématique et je définis les comportements problématiques de manière non exhaustive par les anomalies, les manquements et les inadéquations. Mémotechniquement, on peut parler d'AMIS (le S tient pour "Suggestions").

Qu'on veuille bien considérer la différence primordiale entre les techniques traditionnelles de testing et le Chaotic Testing: les méthodes traditionnelles évaluent l'écart entre ce qui est développé et ce qui aurait dû l'être tandis que le Chaotic Testing, de par sa nature même, vise à déterminer l'utilisabilité du système. Cette utilisabilité est verifiée au sens le plus large du terme (lato sensu).

Au plus tôt, dit-on. C'est donc à dire dès que les premières bribes du système peuvent être soumises aux utilisateurs, en isolation. Le Chaotic Testing rejoint là les méthodes agiles et puisqu'il s'agit-là d'un principe connu, je ne vais pas m'y étendre. Qu'il suffise au lecteur de consulter les principes des méthodes agiles pour en connaître la philosophie.

L'exhaustivité de l'exploration

L'exploration exhaustive du système est garantie par la mise en œuvre de nombreux cas d'utilisation. Le foisonnement et la variation des cas d'utilisation s'obtient par le jeu du hasard, du temps et de la variation.

Le hasard s'apparente à la notion d'expérimentation. Expérimenter se fait par mélange d'intuition et d'attraction. Le rôle du hasard est de susciter les cas d'utilisation les plus variés possibles, jusqu'à des confins impossibles à atteindre dans des plans de test formels par le simple jeu de leur variation infinie.

La synchronisation des développements avec la perception de satisfaction

Le principe ici est de faire coïncider l'achévement du produit avec la satisfaction des utilisateurs. Si les utilisateurs considèrent que les fonctionnalités développées sont suffisantes, il est concevable d'envisager la distribution du produit ou du moins le passage de la phase de construction à la phase de transition/déploiement/distribution. Cela doit être vrai même si les fonctionnalités développées ne sont qu'une partie de ce qui avait été prévu.

Le même principe s'applique dans le sens inverse: même si toutes les fonctionnalités prévues ont été développées, il se pourrait que les utilisateurs considèrent que ce n'est pas suffisant. Il y a alors lieu de poursuivre la phase de construction.

Ce qui m'apparaît ici déterminant c'est de pouvoir être amené à finaliser le produit AVANT que l'ensemble de ses fonctionnalités aient été développées, un cas qui sinon n'arrive jamais. Cela permet alors de juguler les coûts de construction et d'envisager un retour sur investissement plus rapide. Dans le cadre de mon expérience auprès de la société FastWrite cela nous est arrivé à de nombreuses reprises avec la collection « Je Gre… » et notamment avec « Je Gre… Mes Factures » qui fut distribué en 1990 avant que l'ensemble des fonctionnalités prévues n'aient été délivrées. Le relicat de fonctionnalités était alors versé dans une version ultérieure du produit.

Une note finale par rapport au sentiment de satisfaction du produit. Les utilisateurs ne livrent pas facilement ce sentiment de satisfaction et on a même tendance à penser qu'ils en veulent toujours davantage, que si on les écoutait, on ne finirait jamais. En fait, le sentiment de satisfaction ne s'exprimera volontiers que lorsque la confiance dans le système est présente. C'est la raison du prérequis #2.

Des ressources qui n'émargent pas au budget du projet

L'un des attraits du Chaotic Testing est de s'adjoindre les services de ressources qui ne pointent pas sur le projet. La participation au Chaotic Testing se fait sur base volontaire et sans aucune obligation, je le rappelle. Dès lors personne ne va venir vous demander une ligne dans le logiciel de booking de tâches. En d'autres termes, vous disposez de ressources qui ne sont pas sur votre payroll, au moins pas sur le payroll du projet [6] .

Absence de plan

Le corollaire immédiat du terme "chaotique" est l'absence de plan préétabli. Si un plan existait, nous aurions banni un des deux éléments fondateurs du testing chaotique: le hasard. Sans hasard, il n'est plus possible d'assurer une couverture suffisante de l'utilisation du système.

Si un plan existait, il faudrait aussi soumettre les utilisateurs du système à des obligations. Ce serait en conflit avec un principe de base du système.

L'absence de plan pose un problème qui peut s'avérer insurmontable dans certaines organisations. Par ailleurs l'absence de plan ne convient pas à certains types de produits: la pharmarcie, l'aéronautique, les chantiers navals, …

Savoir si une approche Chaotic Testing est appropriée au produit à "tester" est donc une question essentielle à résoudre. Nous reviendrons à cette épineuse question un peu plus tard dans cet article.

END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK. THE REST OF THE ARTICLE MUST BE REVIEWED

L'aide au développement du développement

L'équipe de développement doit participer … à son développement. Il s'agit de construire des petits échaffaudages, c'est-à-dire des structures qui aident à construire le bâtiment principal mais qui ne sont, en principe du moins [7] , pas livrées avec le produit fini. Mon propos n'est pas de lister ici l'ensemble des possibilités, mais plutôt de donner chair au principe par le biais de quelques exemples que les sociétés FastWrite et Lato Sensu Management ont inscrits à leur panoplie.

Still To Do

Le Still To Do se décline en deux parties.

La première partie consiste à permettre à des utilisateurs identifiés d'introduire dans le produit des listes de choses qui sont encore à faire à l'endroit précis où elles sont encore à faire, du moins selon eux.

La deuxième partie permet aux autres utilisateurs (dont les développeurs) de visualiser les choses à faire à l'endroit précis où elles sont à réaliser.

Un exemple de visualisation d'un Still To Do pris du site web du Château Jourdain. Ici, c'est le développeur qui s'est permis de rentrer cette liste de choses à faire. La liste n'est valable QUE pour la page web en question. Elle ne se montre QUE sur la page en question. Techniquement, le Still To Do est une île de contenu qui ne se révèle jamais dans des conditions d'utilisation d'un produt fini.

Le formulaire de feedback

Le formulaire de feedback est une formidable opportunité de rechercher les AMIS: anomalies, manquements, inadéquations, suggestions. Voilà typiquement le genre d'échaffaudage qui a l'heureuse tendance à accompagner le produit fini (au lieu d'être éliminé une fois le bâtiment principal construit).

Grâce à lui vous êtes en mesure de capturer les sentiments des utilisateurs qui ont souhaité s'inscrire à votre procédé de Chaotic Testing. Ce genre de formulaire doit idéalement être pré-rempli au maximum: nom de l'utilisateur, module que l'utilisateur est en train d'utiliser/tester, le type de device utilisé par le visiteur (dans les techniques web). Bref, tout ce que vous pouvez pré-remplir doit l'être. Voici un exemple d'un tel formulaire tiré de notre projet Quitus:

Le formulaire de feedback de Quitus, un projet de Lato Sensu Management. Le formulaire permet de choisir parmi toute une série de types de feedback. Les types disponibles permettent de déterminer les AMIS: anomalies, manquements, inadéquations, suggestions.

L'aide dynamique

FastWrite, par le biais de la collection « Je Gre… », a introduit le concept d'aide dynamique dès 1989. Le principe était que l'utilisateur puisse se concocter, zone par zone, sa propre aide, qu'il puisse se laisser ses propres notes si vous voulez.

Dans le cas de la collection « Je Gre… », une aide contextuelle était disponible sur chaque zone. Quand bien même cette aide, nos propres utilisateurs avaient toujours des questions à poser aux développeurs. Quand il ne s'agissait pas d'xpliquer la zone en question, il s'agissait de rappeler les explications antérieures et à repréciser de quoi il s'agissait. Pour ne pas avoir à expliquer, ré-expliquer et encore ré-expliquer, les développeurs de la collection ont proposé aux utilisateurs de se mettre eux-mêmes des petites notes. Le principe d'aide dynamique était né et dès ses premières utilisations, il a connu en interne une belle progression comme par exemple donner la possibilité à l'utilisateur de se rappeler de conventions qu'il pouvait avoir mis au point: par exemple une convention de numérotation dans « Je Gre… Mes Livres{{{»}}}, une manière de nommer les rappels dans « Je Gre… Mes Rappels{{{»}}}, etc.

L'aide dynamique documentée dans les manuels de la collection « Je Gre… » dès 1989: (ici déjà devenue L'Ordinateur facile pubiée avec Hachette / Marabout): voyez sur la page de gauche l'aide utilisateur (Shift-F1).

Une ré-utlisation (un peu abusive) du principe peut servir à des utilisateurs du Chaotic Testing pour se laisser des notes. Exemple:

Cette zone est inutile à mon sens.
Pat, le 17-10-13 à 17:53.

Pas d'accord. Moi je l'utilise pour mentionner le fait que la
facture doit encore être envoyée.
Sylvie, le 18-10-13 à 09:22".

Mais ne penses-tu pas qu'il faudrait alors demander à disposer d'une sorte
de case à cocher?
Pat, 18-10-13 14:28

Je trouve que c'est une bonne idée. Tu rentres une suggestion?
Sylvie, 19-10-13 00:15

Je m'en occupe
Pat, 20-10-13 07:13

Voici le même principe d'aide dynamique repris dans Quitus:

L'aide dynamique telle que Lato Sensu Management l'a implémentée dans Quitus, un principe en œuvre sur quasiment toutes les zones de chacun des modules.

L'aide dynamique n'est pas considérée comme un échaffaudage: c'est un feature du produit fini. Ce feature peut néanmoins être utilisé en Chaotic Testing pour permettre aux utilisateurs du système de communiquer les uns avec les autres au-delà des limites de lieu et de temps.

Les Sticky Notes

Cet article doit être continué.

Messaging

Cet article doit être continué.

Le crash report

Bien des techniques existent qui parfois demeurent dans les produits finis. Je pense par exemple ici au principe du Crash Report.

Rating

Voilà une façon bien pratique de recueillir le feedback des utilisateurs: le rating. Il s'agit d'estimer l'utilité d'un feature sur une échelle de 1 à 5 (ou selon votre propre échelle). Cela permet de gérer la priorisation de manière quasi automatique. Un feature qui n'est pas encore présent dans l'arsenal de Lato Sensu Management mais qui le sera bientôt grâce à la classe LSRating du framework Vae Soli!.

Là encore, Lato Sensu Management ne considère pas cette fonctionnalité comme un echaffaudage mais plutôt comme une caractéristique du produit fini. En outre, Lato Sensu Management souhaite intégrer ladite fonctionnalité au formulaire de feedback.

Et tant d'autres…

Vous avez évidemment compris le principe qui consiste donc à ce que le développement aide le développement via la fonction de Chaotic Testing. Les exemples que je viens de citer ne sont évidemment pas exhaustifs et je vous invite à compléter la liste.

Un principe cependant: il ne faut pas confondre la fin et les moyens. Votre but est de construire le bâtiment principal et non les échaffaudages. C'est un principe architectural d'une évidence limpide. Favorisez donc l'émergence de principes qui feront partie de votre bâtiment principal. Pour être clair, si vous devez choisir entre une fonctionnalité A et une fonctionnalité B, fonctionnalités toutes deux à objectof "boucle de feedback dans le Chaotic Testing", favorisez la fonctionnalité qui vous coûte le moins cher sur le long terme tout en assurant la plus grande utilisation possible [8] .

END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK END OF WORK Parler du random testing qui ne s'apparente pas au testing chaotique mais qui peut le compléter Parler des tests automatiques Prendre les captures d'écran du feedback/support dans Quitus + TODO list sur les pages

Absence de formalisme

à tester capable de créer la confiance dans le produit. Il faut développer du code qui permette qui se teste lui-même.

Testing chaotique en tant que plan plus large

J'ai dit que le Testing chaotique devait se faire sans plan préétabli. Cela ne signifie pas pour autant que le Testing chaotique ne peut pas faire partie d'un plan plus large. Au fond, il s'agirait de prévoir une part d'imprévisible.

Comment savoir si la tondeuse a été au travail? Donc comment savoir si le testing chaotique a rempli son objectif? ARTICLE PRECEDENT

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.

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.

Notes de bas de page

[1] … La date précise est impossible à déterminer mais ce dont je me souviens c'est que la méthode était déjà pratiquée pour la première vague des « Je Gre… », entamée en 1989 mais distribuée dans le public en 1990, si mes souvenirs sont exacts

[2] … La technique peut sans doute être appliquée à d'autres domaines que la construction d'applications informatiques

[3] … Fonctionnement anormal, troubles, insuffisances, excès, …

[4] … On ajoute un S pour Suggestions … Anomalies, manquements, inadéquations, suggestions.

[5] … Une anomalie se définit comme une déviation par rapport aux spécifications

[6] … Rien n'est jamais vraiment gratuit car les utilisateurs, surtout s'ils sont internes à votre entreprise, sont néanmoins payés par votre entreprise. C'est la raison pour laquelle je préfère parler du budget du projet.

[7] … Nous verrons que certaines de ces structures, de temporaires, sont devenues permanentes comme, par exemple, les crash reports

[8] … Notre expérience nous dicte que c'est toujours la fonctionnalité qui peut être laissée dans le produit fini qui l'emporte

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