Malvoyance – vis ma vie numérique avec Marie-Françoise Pierre

Une autre vision du web

Portrait d’un regard

Entrepreneuse, mère de famille et engagée dans diverses associations calédoniennes, Marie-Françoise Pierre passe une grande partie de ses journées devant des écrans. Nous l’avons rencontrée pour nous immerger dans sa vie numérique, qui est adaptée à son handicap : la malvoyance.

Dans cet article, nous allons présenter une vie numérique parmi des millions d’autres, en espérant qu’elle vous aidera à imaginer des sites plus accessibles, mais aussi détecter des problèmes d’accessibilité et en parler pour qu’ils soient corrigés.

Comment voit Marie ?

La déficience oculaire de Marie touche la partie centrale de sa rétine, la macula, ce qui affecte le centre de sa vision. Sa vision périphérique, en revanche, lui permet de se situer dans l’espace et de se déplacer sans problème. Cette déficience l’handicape à 80% ; certaines actions ne lui sont pas possibles, par exemple la conduite.

D’autres types de malvoyances impactent uniquement la vision périphérique, ce qui permet aux personnes de pratiquer des activités demandant une acuité visuelle fine, mais peut représenter un risque important lorsque des dangers surviennent sur les côtés.

Pour Marie, avoir une bonne hygiène de vie est impératif pour voir le mieux possible : une fatigue ou un manque de sommeil peuvent lui rendre encore plus difficile la lecture, voire lui occasionner des vertiges.

Si vous souhaitez expérimenter par vous-mêmes la façon dont Marie voit le monde, vous pouvez télécharger l’application Eye-View (disponible sur iOs et Android) et essayer la vue “DMLA” en agrandissant au maximum la tache grise centrale. Gardez bien votre regard au centre de la tache et laissez votre vision périphérique faire le reste… Pas facile !

Des équipements matériels et logiciels pour plus d’accessibilité

Chez Marie, tout est Mac : ordinateur, tablette et smartphone, car tous ces matériels intègrent directement des fonctions d’accessibilité pour les déficients visuels. Sinon sur PC, Marie doit être équipée du logiciel ZoomText, un logiciel qui coûte cher acheté individuellement (environ 60 000 francs pacifiques). Ces outils permettent de régler la taille du texte, la teinte et le contraste des couleurs, l’apparence du curseur, et propose également une synthèse vocale. Mais le plus souvent, Marie préfère ne pas utiliser la synthèse vocale ; elle a remarqué que celle-ci a tendance à s’entrecouper, répéter plusieurs fois la même chose, ou encore énoncer un autre texte que celui souhaité. Elle préfère lire elle-même les textes, aussi bien dans les visionneuses de documents que dans son client mail ou son navigateur.

Elle maîtrise Siri et a formé d’autres personnes dans le cadre l’association Valentin Hauÿ de Nouméa, mais a l’habitude d’écrire ses mails et autres messages au clavier.

Marie lit avec fluidité à condition que le texte soit à une taille suffisante (police 72 pour un document word affiché à 100%). Il est préférable aussi que la police soit sobre, sans empattements (lire cet article pour comprendre pourquoi !). Pour lire un texte, elle zoome au maximum, fait défiler la page horizontalement avec la souris, dézoome, rezoome… Toute une gymnastique qu’elle fait maintenant sans y penser. Elle explique qu’au départ ça donne un peu envie de vomir, mais qu’on s’y habitue vite.

Le clavier de Marie est tout à fait classique. Pour écrire avec plus d’aisance, elle y a simplement collé deux petits reliefs en plastique qui lui permettent de placer ses mains au bon endroit.

Elle utilise souvent l’appareil photo de son téléphone pour zoomer certains textes rencontrés dans la vie de tous les jours, par exemple des plaques portant un nom de rue, ou les cahiers d’école de ses enfants.

Des bugs auxquels vous n’auriez peut-être jamais pensé

Vous souhaitez construire des logiciels (plus) accessibles ? Voici maintenant des points soulevés par Marie au cours de sa vie d’internaute. Peut-être repenserez-vous à ces cas d’utilisation lors de votre prochaine phase de spécifications… Car une fonctionnalité qui semble parfaite pour une personne valide peut être perçue comme buggée (ou “buggante”) lorsque l’on navigue différemment.

Le menu glissant

Imaginez un site web avec un bandeau comprenant différents onglets thématiques. Lorsque vous survolez un onglet avec la souris, un menu apparaît. Et lorsque vous survolez un item de ce menu, un sous-menu apparaît. Et lorsque la souris quitte soit l’onglet, soit le menu, soit le sous-menu… Tout se replie.

Ce type de design est très courant, en particulier sur les sites de vente ; à peu près gérable quand l’écran est affiché à 100%, il devient cauchemardesque s’il est zoomé à 500%. Comment garder la souris sur ces éléments tout en faisant défiler l’écran horizontalement ? Ces menus interactifs peuvent devenir un casse-tête.

Le carrousel vertigineux

Certains carrousels d’images défilent automatiquement et nécessitent que l’on identifie rapidement les informations utiles et qu’on les lise dans la foulée. Or, pour Marie, l’étape d’identification est plus longue que prévu ; ce qui était censé être une animation agréable et vivante devient une chasse agaçante où l’on joue au chat et à la souris.

Le captcha indéchiffrable

Les captchas sont des outils plus ou moins efficaces pour limiter l’accès des robots sur certaines parties du web. Mais ils ne sont pas toujours accessibles : les lettres indéchiffrables et les contrastes insuffisants bloquent parfois à Marie l’accès à certains services.

Le curseur fugitif

Dans certaines applications, Marie a remarqué que lorsqu’on zoome au maximum un champ où l’on est en train de saisir du texte, le focus de l’écran ne suit pas automatiquement le curseur. Du coup, lorsque le curseur quitte l’écran, on ne voit plus ce qu’on écrit. Elle a remarqué ce comportement en particulier sur son client de messagerie.

La barre qui s’incruste

Quand Marie regarde une vidéo, elle n’a pas le temps de lire les sous-titres. Mais lorsqu’elle a besoin de les lire et qu’elle appuie sur “Pause”, il arrive que la barre de lecture cache la partie basse de la vidéo, ce qui masque le texte.

Cette petite série de bugs n’est qu’un échantillon des embûches que l’on peut rencontrer lorsqu’on navigue autrement que ce qui était imaginé par le concepteur d’un site web. La prochaine fois que vous ouvrirez un site (probablement dans moins de quelques minutes), regardez-le avec un oeil différent ; quelles parties vous semblent bien pensées pour l’accessibilité ? Quelles parties laissent à désirer ? Adopter ce regard nécessite de l’entraînement, et des méthodes et outils peuvent vous aider à le faire, comme nous en parlions précédemment.

L’accessibilité, ce n’est pas que pour les autres

Au cours de sa vie professionnelle, Marie a remarqué que les logiciels destinés à un usage interne étaient souvent moins soignés en termes d’ergonomie et d’accessibilité que les logiciels ouverts à un public plus large. Un constat qui laisse pensif, à l’heure où l’insertion des personnes handicapées devrait être un enjeu important des entreprises.

Pourtant, au bureau ou ailleurs, la majorité des mesures d’accessibilité sont profitables autant aux personnes handicapées qu’aux autres. N’importe qui pourrait avoir besoin de capter toutes les infos d’un site sans se baser sur les images (sa connexion étant trop lente pour les charger par exemple), et donc de se servir des attributs de texte alternatif. N’importe qui, souffrant d’une migraine passagère ou de fatigue oculaire, pourrait apprécier un site dont les contrastes respectent les normes d’accessibilité.

Cela est vrai aussi “dans la vraie vie”… Vous le savez s’il vous arrive de préférer monter via la pente douce plutôt que par les escaliers.

N’hésitez pas à partager dans les commentaires votre expérience du handicap, de l’accessibilité et des bugs associés que vous avez rencontrés !

Autres articles sur le thème de l’accessibilité

Chiffres sur l’accessibilité du web calédonien

30 days of accessibility testing

Gestion des connaissances : la métaphore de l’île

« Un vieillard qui meurt, c’est une bibliothèque qui brûle »

Pour ce deuxième article sur les métaphores au service du test, nous allons nous concentrer sur un aspect crucial de tout projet informatique : la gestion des connaissances. Comment faire pour partager les bonnes infos aux bons endroits, de manière à ce que les bonnes personnes puissent les trouver au bon moment ? Et pour commencer, comment donner aux collaborateurs l’envie de transmettre leur savoir d’une part, d’augmenter leurs compétences d’autre part ? Lorsque vous étudiez ces questions avec votre équipe, nous vous proposons de garder à l’esprit une métaphore, qui nous vient des confins du Pacifique Sud. Au passage, merci au Guichet du Savoir pour les recherches bibliographiques sur ce sujet !

Gestion des connaissances : et si on jouait les Néo-Zélandais ?

Problématique

Vous en êtes certain, il y a des trous dans la raquette. Les membres de votre équipe sont excellents dans leur spécialité, mais ne connaissent pas suffisamment le travail les uns des autres et sont incapables de se relayer. Cela peut être un handicap à plusieurs niveaux :

  • fonctionnel, car l’absence d’un membre peut constituer un frein pour l’ensemble de l’équipe
    • Marjolaine est la seule à connaître la nouvelle procédure de mise en qualification, mais est clouée au lit par la dengue pour les deux semaines à venir. Les autres membres de l’équipe, frileux à l’idée de se lancer dans une procédure non documentée, se défendent en disant que ce n’est pas à eux de le faire.
  • relationnel, car l’estime et l’empathie ne sont pas toujours au rendez-vous (surtout si les membres de l’équipe ne travaillent pas au même endroit)
    • Quand le projet prend du retard, Anselme le PO considère que les devs ont codé trop lentement et Polly la team leader considère que les specs trop brouillonnes les ont ralentis.
  • individuel, car les membres de l’équipe pourraient s’épanouir davantage en acquérant de nouveaux savoir-faire
    • Boniface est testeur ; le projet dure depuis des mois et des mois et il se sent enfermé dans une routine, il a le sentiment de ne plus rien apprendre. Il songe parfois à changer de boîte.

Métaphore

Mike Talks est testeur en Nouvelle-Zélande. Cité dans More Agile Testing de Janet Gregory et Lisa Crispin (2014), il s’inspire au travail de l’histoire de son pays.

Dans la lignée des idéaux historiques néo-zélandais, j’encourage tout un chacun à sortir de sa zone de confort au sein de son équipe et s’essayer à de nouvelles choses. Dans un contexte de rareté des ressources et des compétences, ces modes de fonctionnements se sont révélées cruciaux pour les premiers pionniers de Nouvelle-Zélande. De manière générale, les spécialistes étaient amenés à diversifier leurs connaissances pour devenir des “spécialistes généralisants“. [Traduction Hightest]

A propos des pionniers de Nouvelle Zélande, Francine Tolron (source) rapporte effectivement les détails d’une vie quotidienne débrouillarde, émaillée de multiples activités :

Le pionnier […] dut trouver en lui-même ses ressources : construire […] un abri, une baraque de ponga, à partir des stipes de fougères, un toit en feuille de lin ; il lui fallut ramasser la nourriture de la forêt […], brûler les troncs pour fertiliser la terre entre les souches afin de planter du blé qu’il devait moudre sur place. Il fabriquait tout ce dont il avait besoin, depuis le beurre jusqu’aux chandelles et aux briques.

Visualisez-vous en train de fabriquer vos propres chandelles pendant que les briques que vous avez vous-mêmes façonnées sont en train de cuire dans votre four ; il n’y a rien que vous ne puissiez pas apprendre, ni vos collègues. Cela dit, on peut être aussi débrouillard que l’on veut, certains savoir-faire ne s’inventent pas, et les cycles projet ne permettent pas forcément de s’accorder de longues journées d’apprentissage autodidacte. La métaphore de Mike Talks permet donc de mettre l’accent sur les liens indispensable entre les membres de l’équipe. De même que les pionniers de Nouvelle-Zélande, il est nécessaire de développer des compétences secondaires, en s’appuyant sur les compétences les uns des autres. L’équipe projet est comme une île où il est nécessaire de valoriser au maximum chacune des ressources, car les risques de perdre une expertise sont décuplés.

Pour la petite histoire, Mike Talks a mis en action cette idée en travaillant de concert avec un business analyst. D’abord convaincu qu’il lui serait simple de rédiger des expressions de besoins, il s’est finalement rendu compte qu’il s’y prenait mal. D’une part, il n’expliquait pas suffisamment le cœur du problème, d’autre part il partait trop loin dans les détails, empiétant sur la marge de manœuvre des développeurs. Progressivement, monter en compétences dans ce domaine a enrichi ses propres pratiques et a par la suite amélioré la performance de ses échanges avec d’autres business analysts.

Mike Talks a également pu approfondir sa connaissance du métier en allant proactivement à la rencontre des utilisateurs du produit testé. Bâtir une relation de confiance, là où il aurait pu ne rien y avoir, lui a encore permis de gagner en pertinence lors de ses tests.

De l’équipe-île au testeur en forme de T

Cette démarche d’apprentissage a pour conséquence de modeler une expertise en forme de T, de nous transformer en “versatilistes” ou “T-shaped testers” (et non, on ne parle pas d’haltérophilie). Cette image a été développée en 1991 par David Guest dans l’ouvrage The Hunt Is On for the Renaissance Man of Computing, où est évoquée l’image de l’homme de Vitruve dessiné par Léonard de Vinci.

Ici, la barre verticale du T représente les connaissances en test, approfondies par l’expérience, et qui permet au testeur d’exercer au mieux son coeur de métier. C’est la taille du testeur ; plus il est grand, plus il voit loin ; il a en tête de nombreux paysages logiciels, il voit venir les problèmes à l’horizon et a le temps de s’y préparer.

La barre horizontale est quant à elle le symbole des domaines connexes maîtrisés en second plan. C’est l’envergure du testeur, ce qui lui permet de tendre la main et d’attraper, d’assimiler et de valoriser des informations issues d’autres domaines. Ce sont les connaissances métier engrangées au contact des clients, la culture technique acquise au contact des développeurs, les compétences managériales développées au fil des projets.

Et vous, quelle est votre T ? Quel est celui de vos collègues ? Que pouvez-vous vous apporter les uns les autres, de manière à ce que votre île soit la plus vivable possible ?

Conclusion

La métaphore de l’île nous amène à capitaliser les connaissances qui existent au sein d’une équipe, afin d’élargir le champ de compétences de chaque individu. De la même manière qu’une fonctionnalité peut être partiellement couverte par des tests portant sur une autre fonctionnalité, des activités peuvent être sommairement assurées par des personnes dont ce n’est pas le coeur de métier.

La démarche d’apprentissage peut s’accompagner d’une réflexion sur le “nous” de l’équipe. Pour cela, nous vous conseillons d’explorer les ateliers et supports développés par l’UdN (Université du Nous).

Nous vous proposerons prochainement une nouvelle métaphore issue de More Agile Testing, qui nous reliera cette fois au monde agricole… d’ici-là, n’hésitez pas à poster en commentaire les métaphores qui vous semblent précieuses pour illustrer la gestion des connaissances.

Gestion du temps : la métaphore de la figue

Priorisation : que faire quand ça semble trop tard ?

Pour ce troisième article sur les métaphores au service du test, nous allons nous pencher une fois de plus sur l’ennemi juré de la qualité : le temps, qui vient souvent avec ses cousins le rush, le stress et la précipitation. Et si une métaphore nous aidait à nous réconcilier avec ce facteur incontrôlable ?

Problématique

Le sprint est presque fini mais rien n’est vraiment prêt. Toute l’équipe est stressée et ne sait plus où donner de la tête. Freeze : c’est peut-être le moment de se calmer un peu et de faire le point sur ce qu’on peut rapidement finaliser. Vous avez besoin d’un déclencheur pour vous sortir la tête du guidon et aller à l’essentiel.

Métaphore

« Récolter les fruits d’un travail » est une métaphore assez commune. En cette fin de sprint ou d’itération, vous et votre équipe êtes en pleine cueillette. Mais vos paniers ne se remplissent pas très vite et vous vous inquiétez car le soleil est en train de se coucher. La lumière décline, les figues sont de moins en moins visibles dans les arbres et l’angoisse de ne rien cueillir habite chacun d’entre vous. Naturellement, à ce stade, ce sont les figues les plus basses que vous devez récolter, peu importe si elles sont petites. Le “low-hanging fruit“, c’est un bénéfice rapide que l’on peut faire en déployant un effort modéré.

Cette métaphore est souvent utilisée dans la littérature agile, et en particulier dans More Agile Testing. Dans l’objectif de livrer de la valeur à chaque sprint, il est parfois intéressant de se focaliser sur ce qui est rapidement faisable plutôt que sur ce qui serait idéal à long terme. On pourrait utiliser cette métaphore en réunion, par exemple pour organiser des postits énumérant des solutions à un problème. Attention tout de même à garder en tête la notion de valeur, afin de ne pas cueillir un fruit pourri…

Un exemple de schéma :

Dans ce graphique structuré autour d’un arbre, l’axe horizontal du représente la valeur ajoutée et l’axe vertical rla difficulté ou la complexité. Les post-its peuvent être classés dans cet arbre pour que l’on puisse visualiser les tâches pouvant rapidement apporter de la valeur. Ces tâches se trouveront donc dans la partie en bas à droite du schéma.

Si vous êtes pressé par le temps, relevez la tête et pensez fruit !

Priorisation bis : le puzzle logiciel au service de la sérénité

Mais fort heureusement, nous ne sommes pas toujours en guerre contre le temps. Côté test, une analyse d’un logiciel par les risques permet de limiter les situations de stress et de faire au mieux en temps limité. Et cela, c’est encore une métaphore qui va nous aider à le partager.

Problématique

En bon choriste de l’ISTQB, vous connaissez par coeur les paroles de “Les défauts sont regroupés” et de “Les tests exhaustifs sont impossibles“. Vos interlocuteurs n’ont peut-être pas envie de vous les entendre chanter encore une fois. Il vous faut rafraîchir cette même idée avec une métaphore.

Métaphore

Janet Gregory compare un logiciel à un puzzle dont on découvre l’image peu à peu, au fur et à mesure où l’on assemble ses pièces. Elle explique qu’il est possible d’obtenir des informations sur le puzzle sans l’assembler en entier, et tant mieux, car cela prendrait un temps fou. Pour tester dans les temps, il faut se concentrer sur les parties du puzzle qui nous intéressent le plus.

Imaginons que notre tableau représente une réplique, peinte par un contemporain, de la fresque de La Création d’Adam, peint par Michel Ange sur le plafond de la Chapelle Sixtine au début du XVIè siècle. Il est spécifié que la réplique doit être la plus fidèle possible à l’original, nous voulons donc tester si cela a été respecté, en maximisant nos chances de trouver d’éventuels défauts. Alors, voici ce que nous allons prendre en compte :

  • La partie du tableau où les doigts d’Adam et de Dieu sont sur le point de se toucher est absolument critique. C’est la plus connue, la plus emblématique de l’oeuvre, celle qui justifie son titre ; c’est l’équivalent du cœur de métier. Il faut qu’elle soit testée.
  • Les visages sont des parties d’un tableau qui peuvent être très intéressantes, mais le moindre détail peut ruiner une expression. On va donc assembler ces parties avec une priorité élevée.
  • On sait que le ciel est quasiment un aplat, il contient peu de détails. Inutile d’assembler beaucoup de pièces pour pouvoir affirmer, avec un niveau de confiance élevé, s’il est fidèle au ciel original.
  • Le paysage où se tient Adam n’est pas aussi uniforme. Il n’est pas utile d’assembler toutes ses pièces si jamais on manque de temps, mais il n’est pas à négliger pour autant.

Les trois puzzles ci-dessous correspondent à des couvertures de test différentes, mais en cas de manque de temps, on comprend que c’est la première qu’il faudra choisir.

Sur la première image, les trous au niveau du ciel et du paysage n’empêchent pas d’étudier les parties critiques du tableau. Sur la seconde image, les trous se situent sur des visages et autres parties très signifiantes de l’oeuvre, ce qui pose problème. Sur la troisième image, la couverture est parfaite car on se trouve face à l’oeuvre entière, sans aucun trou.

Pour approfondir cette métaphore avec son inventrice, rendez-vous sur le blog de Janet Gregory !

Conclusion

Ici, la métaphore nous permet de dynamiser notre exigence de qualité plutôt que de laisser l’exigence de rapidité inhiber nos forces. Même en cas d’urgence, il est profitable de faire une courte pause pour orienter au mieux nos dernières heures disponibles.

Nous espérons que cette petite série d’articles vous aura plu. Nous développerons peut-être à l’avenir d’autres métaphores ; nous espérons avoir bien illustré le fait qu’il s’agit de puissants outils de pensée.

N’hésitez pas à poster vos propres métaphores dans les commentaires !

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

Le kit de secours métaphorique pour les tests agiles

La métaphore en action

“Tu travailles dans le test ! Quels langages tu connais ?”

Dans les prochains articles, nous n’allons pas parler de Python, Java ou Ruby, mais d’un langage que l’on utilise tous les jours en tant que QA : le “langage naturel“. Par commodité, c’est comme ça que l’on nomme le langage que l’on parle aussi bien à la maison qu’au bureau. Mais il n’a rien de “naturel” ; nous allons au contraire nous pencher sur des manières de le modeler, de le ciseler, afin de le rendre plus efficace, plus à même de servir la qualité des projets. Nous allons pour cela nous appuyer sur le procédé de la métaphore.

Pourquoi cette figure de style en particulier ?

La rencontre de deux univers sémantiques

Le mois dernier, sur le blog de la Taverne du Testeur, Marc Hage Chahine filait une longue métaphore sur le métier du test en le mettant en parallèle avec une chasse aux champignons. L’article allie l’utile à l’agréable en poursuivant un but bien précis : donner une explication d’un processus complexe, de façon à ce qu’un enfant de 6 ans puisse la comprendre.

Le résultat est assez réussi. Pourquoi ? Parce qu’en sollicitant un univers sémantique familier, on peut faciliter la compréhension d’un autre univers plus difficile à imaginer. Autre avantage : l’interlocuteur peut poursuivre la métaphore et ainsi alimenter la discussion, beaucoup mieux que s’il n’avait pas ce point de repère. Il peut par exemple se replonger dans un embarras qu’il a déjà vécu (ramasser un caillou qu’il prenait de loin pour un champignon) pour imaginer certaines situations du métier (la frustration des QA qui tombent sur des faux positif).

Et les métaphores sont partout. D’ailleurs, elles constituent souvent le ressort comique des memes et des GIF. Un exemple ?

Trois chats regardent avec beaucoup d'attention un oiseau par la fenêtre. Soudain, un petit chien arrive derrière les chats et les fait sursauter. Sur l'image, une étiquette indique que les chats représentent l'équipe projet, l'oiseau représente le week-end et le chien représente un bug inattendu.

On dit souvent qu’une image vaut mille mots. Mais ce qui est vrai à l’écrit, avec les graphiques et les illustrations (et, donc, les GIF), l’est donc aussi à l’oral, avec les métaphores. La formulation d’une idée peut avoir un impact notable sur la façon dont le cerveau de l’interlocuteur est stimulé. Ces dernières années, des chercheurs se sont même employés à le confirmer expérimentalement.

Les effets d’une métaphore sur le cerveau

Le psychologue Rutvik Desai, dans un article paru en 2011, a par exemple observé que les verbes d’action, y compris ceux qui étaient présents dans des métaphores, faisaient réagir les zones moteur du cerveau (source [PDF]). Ce qui pourrait signifier que la phrase « Il va falloir qu’on se serre les coudes pour terminer cette campagne de test » est plus stimulante que « Il va falloir qu’on s’entraide […] ». A noter : plus une métaphore est commune, moins elle active les zones moteur du cerveau. Quand on dit qu’on saisit l’intérêt de quelque chose, l’image de la préhension est assez lointaine. C’est comme si le cerveau avait besoin d’un effet de surprise pour que la métaphore joue son rôle.

Des résultats similaires ont été obtenus par l’université d’Emory en 2012 avec des métaphores contenant des références au toucher (source). Là, par exemple, on pourrait remplacer “Votre implication m’a fait très plaisir” par “m’a fait chaud au coeur”.

On voit bien pourquoi les ouvrages de fiction nous donnent l’impression de nous évader ; l’imagination, entendue comme production d’images mentales, peut mettre en action les zones du cerveau impliquées dans les mêmes actions lorsqu’on les vit réellement. De la même manière, on peut aussi supposer que les métaphores, lorsqu’elles sont utilisées au travail (pour susciter l’attention, expliquer une idée, défendre un point de vue, motiver une équipe…) peuvent jouer un rôle intéressant.

C’est en tous cas ce que nous avons pensé en lisant l’excellent ouvrage More Agile Testing (2014) de Janet Gregory et Lisa Crispin. Le propos, truffé de métaphores intéressantes, en est d’autant plus limpide et stimulant. Nous avons donc décidé d’en sélectionner quelques-unes et de les développer dans une série d’articles.

Pour entrer dans le vif du sujet, voici la première métaphore de notre série, qui vous permettra peut-être de résoudre des situations de conflits d’intérêts.

Vélocité : le bus rapide VS le bus efficace

Problématique

Vous en avez assez de ressasser le sempiternel triangle Coût-Temps-Qualité. Dans certains contextes, vous avez besoin d’une autre image pour faire comprendre que la qualité prend du temps au début, mais qu’il serait contre-productif de la négliger.

Métaphore

Parole à David Evans, coach agile (traduit par nos soins) :

« Le management se montre parfois réticent lorsque je préconise d’écrire collaborativement les tests d’acceptation avant de se lancer dans l’implémentation de chaque story. On m’objecte généralement que cette tâche ralentirait la vélocité du développement. Je leur concède qu’en effet, en une certaine mesure, ça ralentit les choses. Cela dit, s’arrêter pour prendre des passagers ralentit aussi le trajet d’un bus. »

Il cite ensuite Kent Beck dans Test-Driven Development: By example (2002).

« Si écrire des tests d’acceptation avant de se lancer dans l’implémentation ralentit une chose, c’est bien la vitesse de création de code qui ne marchera pas. »

La métaphore du bus met en oeuvre un raisonnement absurde :

  • Les transports publics sont trop lents
  • S’arrêter pour prendre des passagers ralentit les transports publics
  • Donc les transports publics devraient cesser de prendre des passagers.

Si l’on suit cette logique, les transports publics gagneront en rapidité mais le résultat final ne correspondra en rien à ce qui était attendu. Les usagers résilieront leur abonnement, congestionneront le centre ville avec leurs voitures personnelles et critiqueront les transports publics sur les réseaux sociaux.

Nous vous proposons de filer la métaphore d’une manière qui vous permettra maintenant de rejoindre votre interlocuteur. Il s’agit d’abonder dans son sens dans la première partie de l’argumentation, mais de proposer d’autres solutions pour accélérer le trajet du bus. La métaphore devient ici force de créativité. En se projetant dans la problématique du bus, on quitte le quotidien du projet et on suscite de nouvelles idées.

Un exemple :

  • Les transports publics sont trop lents
  • Un ensemble de trajets mal optimisés ralentit les transports publics
  • Donc il faut s’atteler à revoir tout ou partie de ces trajets. Autrement dit : existe-t-il des étapes de notre workflow qui ralentissent le projet sans contrepartie ?

Ou encore :

  • Les transports publics sont trop lents
  • Le trafic des autres modes de transports ralentit les transports publics
  • Donc il faut s’atteler construire des voies dédiées aux transports publics. Autrement dit : existe-t-il des facteurs extérieurs qui ralentissent le projet et que nous pourrions limiter ?

La métaphore nous a servi ici à combattre une idée allant à l’encontre de la qualité du projet, de rejoindre son interlocuteur et d’entamer avec lui une discussions sur l’amélioration des processus.

Conclusion

Les métaphores peuvent donc être utilisées pour mieux nous faire comprendre, en particulier lorsque le sujet est complexe. Mieux encore, en nous faisant voir les choses sous un autre angle, elles peuvent initier une réflexion et susciter de nouvelles idées.

Merci au Guichet du Savoir pour les recherches bibliographiques sur la confirmation expérimentale de la puissance de la métaphore ainsi qu’à Audrey Loiseau qui nous a transmis le GIF. Et merci à vous, qui posterez vos propres métaphores dans les commentaires !

Nous publierons prochainement une autre métaphore issue de More Agile Testing.

Testeur en contexte Agile

L’Agile c’est quoi ?    

La méthode Agile n’est plus vraiment à présenter, cette méthodologie basée sur des cycles itératifs a su s’imposer dans de nombreux projets de développements.

Pour rappel, les 4 valeurs fondamentales de la méthode Agile sont :

  • L’ équipe : “Les individus et leurs interactions, plus que les processus et les outils”
  • L’ application : “Des logiciels opérationnels plus qu’une documentation exhaustive”
  • La collaboration : “La collaboration avec les clients, plus que la négociation contractuelle”
  • L’ acceptation du changement : “L’ adaptation au changement, plus que le suivi d’un plan”

Et le testeur dans ce contexte ?

Le métier du test est en constante évolution de par l’évolution des technologies, des outils de tests automatisés et des méthodes de gestion de projet.

Dans un contexte Agile, le testeur a une place prépondérante pour le succès du projet.

ISTQB en a d’ailleurs fait un syllabus que vous pouvez retrouver ici.

Comment se positionner ? Quels types de tests réaliser ? Avec qui interagir ?

Nous vous donnons quelques clés du succès qui feront de vous un bon testeur Agile dans cette vidéo :

Vous êtes certifié ISTQB fondation ? vous souhaitez être certifié ISTQB testeur Agile ? Contactez nous !!

Vous aimerez peut-être…

5 graphiques Jira pour mieux communiquer sur les anomalies

Réunion de clôture : un jeu pour finir en beauté !

Respectons le sens des valeurs agiles (blog d’Atlas Management)

 

World Quality Report 2017-2018 : focus sur l’agilité, les tests mobiles et l’automatisation

Une étude annuelle sur le monde du test logiciel

Le premier World Quality Report (en bon français, rapport mondial sur l’assurance qualité) a été publié en 2009 par Capgemini. D’année en année, l’étude s’est étoffée, a gagné en moyens et en notoriété. En 2017, le World Quality Report, c’est :

  • 1660 seniors de l’IT interrogés
  • 32 pays représentés (dont la France, avec 150 personnes interrogées)
  • Une photographie à l’instant T de l’assurance qualité dans les organisations publiques et privées de plus de 1000 employés
  • Des focus par thème, mais aussi par type d’entreprise
  • Des recommandations pour faire face aux problématiques actuelles du métier

Bref, un panorama intéressant à décoder, en gardant tout de même à l’esprit que cette année l’étude a été commanditée par la Sogeti et Capgemini, en partenariat avec l’éditeur Microfocus. Ce pure-player a notamment développé Silk Test et, plus dernièrement, racheté un large portefeuille de logiciels d’Hewlett-Packard Enterprise, dont Loadrunner. Ce qui n’est pas neutre

Notre article fait le point sur trois sujets brûlants dans le domaine du test logiciel : les transformations du métier induites par l’émergence de l’agilité, le défi encore peu exploré des tests mobiles et les challenges liés à l’automatisation des tests.

Le boom du test agile

Les chiffres du test agile

En développement comme en test, le World Quality Report révèle que l’agilité a le vent en poupe. 95% des répondants affirment mettre en oeuvre des pratiques de test agile, au moins sur une partie de leurs projets. 37% des entreprises pratiquent le test exploratoire.

Les pratiques devOps aussi sont également en expansion, et sont désormais représentées dans 88% des entreprises interrogées. Cependant, elles ne touchent jamais la totalité des projets, et concernent moins de 20% des projets dans 47% de l’ensemble des entreprises.

De nouvelles contraintes

Face à cette transformation, les forces vives du test tendent à se décentraliser, et affrontent notamment trois problématiques :

  • La création d’environnements de test idoines et de jeux de données réalistes, qui notamment respectent les lois en vigueur (“QA teams need to help their organizations comply with new data laws such as the EU’s General Data Protection Regulation”, ce qui nous rappelle une fois de plus l’aspect juridique du métier de testeur). Cette problématique rend également difficile l’automatisation des tests et les tests mobiles.
  • La réutilisation et la répétition des tests au fil des itérations
  • Le manque de méthodologie de test agile

Même si la décentralisation du test présente de nombreux avantages, le WQR conseille aux grandes organisations de conserver un organe central (un “TEC” ou “Test Excellence Center”) afin d’harmoniser les pratiques, de capitaliser sur les réussites et de réaliser des POCs.

Automatisation des tests : un horizon impossible ?

Les chiffres de l’automatisation des tests

Le World Quality Report de 2017 révèle que presque la moitié des entreprises (48%, et jusqu’à 57% des entreprises spécialisées dans les télécoms, les médias et les divertissements), se trouvent trop dépendantes des tests manuels. Et effectivement, le chiffre peut étonner : seuls 16% des cas de test fonctionnels sont automatisés !

Parmi les difficultés le plus fréquemment rencontrées, on retrouve :

Autant de challenges qui freinent l’avancement des projets d’automatisation, et augmentent année après année le manque à gagner.

Des pistes pour mieux automatiser les tests

Face à ce constat, le World Quality Report conseille de s’armer de patience. Le rapport indique que parmi les entreprises ayant mis en oeuvre une stratégie d’automatisation des tests, celles dont la démarche a été la plus fructueuse ont commencé par des projets-pilotes autonomes (à l’inverse d’une approche “big bang”).

Il est aussi conseillé de prendre au sérieux la formation en automatisation des tests des équipes qualité, où d’importantes lacunes sont constatées.

Enfin, la présence d’une réelle stratégie et la transparence des reportings des tests automatisés sont cités comme des critères de réussite majeurs.

Tests mobiles : ça pourrait bouger plus

C’est ce qui ressemble à la cinquième roue du carrosse : 52% des répondants n’ont pas assez de temps pour mener des tests mobiles. 47% pointent un manque de méthodologie dans le domaine, 46% ne disposent pas d’équipements adéquats. 5% des organisations interrogées ne font même aucun test mobile.

Ces chiffres sont étonnants, à l’heure où des solutions open-source telles qu’Appium, ou des IDE performants et gratuits comme Katalon, permettent de mettre en oeuvre à moindre coût des stratégies de test mobile, y compris en externalisant la gestion des hardwares (avec par exemple AWS Device Farm, Xamarin Test Cloud ou Kobiton).

Un point intéressant à relever est que les tests non-fonctionnels sont bien représentés dans le domaine du test mobile :

  • 53% des stratégies incluent des tests de performance
  • 43%, des tests de sécurité
  • 39%, des tests de compatibilité
  • 38%, des tests de portabilité,

Contre 48% pour les tests d’interface utilisateur.

Plongée dans le passé : quoi de neuf depuis 2009 ?

L’automatisation des tests était déjà source d’embarras

Certaines choses ne changent pas : en 2009, les entreprises étaient déjà frustrées par leur taux d’automatisation des tests. Le World Quality Report indiquait en effet que 50% des entreprises n’avaient pas atteint leurs objectifs d’automatisation 3 ans après avoir acquis les outils ad hoc. En cause : le manque de plannification, de stratégie sur le long terme et de formation des testeurs. A l’époque, des solutions d’automatisation existaient déjà depuis une quinzaine d’année.

… mais la vision de l’automatisation a mûri

Il existait à l’époque un aspect qui peut maintenant nous étonner : dans l’édition de 2009, la majorité des personnes interrogées pensaient que l’automatisation des tests pourrait aider à réduire la taille de l’équipe de test. Une corrélation qui de nos jours paraît naïve, et qui a d’ailleurs totalement disparu dans l’édition de cette année.

On est sortis de la crise…

Dans le WQR de 2009 transparaît un sentiment d’inquiétude lié à la crise. L’agilité est directement assimilée à un gain pécuniaire, les robots de test semblent voués à remplacer les humains… Il est réjouissant de constater qu’en 2017, ce biais a disparu (au profit d’autres que nous n’identifierons sans doute, hélas, qu’en 2025).

… et on a découvert tant d’autres choses

Pour faire bref, voici quelques mots que l’on ne trouvait pas encore dans la première édition du World Quality Report :

  • Mobile
  • API
  • Load testing
  • DevOps (et pour cause, le mot a été inventé deux mois après la parution du WQR de 2009 !)

La sécurité applicative, la performance et le cloud sont brièvement évoqués, mais on ne les retrouve pas plus loin que dans l’introduction. Bref, depuis la première édition du WQR, le métier du test n’a eu de cesse de s’étoffer. Multidisciplinaire en pratique, il l’est devenu de plein droit au fil des années.

Conclusion

Certes, il n’est pas toujours facile de comprendre comment sont générés les chiffres du World Quality Report. “Nous ne pratiquons pas le test agile” : ils étaient 2% à l’affirmer en 2015, contre 31% en 2016 (!) et maintenant 5% en 2017… Mais malgré ce genre de bizarreries que l’on retrouve tout du long, ainsi que quelques partis pris qui s’expliquent par les commanditaires de l’étude (par exemple l’évocation de TMap, mais pas d’ISTQB) le WQR reste un document utile pour prendre la température du monde du test et comprendre les problématiques auxquelles font face aujourd’hui les grandes organisations. Une analyse qui s’avère encore plus intéressante lorsqu’on la met en parallèle avec les éditions précédentes. Alors bonne lecture !

Ressources

World Quality Report de 2009 (pdf)

World Quality Report de 2017 (formulaire de téléchargement)

Vous aimerez peut-être…

Chiffres sur l’accessibilité du web calédonien

9 points juridiques que chaque QA devrait maîtriser

Le test logiciel est une protection contre les bugs, mais aussi contre les litiges. Vous avez un doute ? Cet article est fait pour vous.

La loi relative à l’informatique, aux fichiers et aux libertés, indique :

Constitue une donnée à caractère personnel toute information relative à une personne physique identifiée ou qui peut être identifiée, directement ou indirectement, par référence à un numéro d’identification ou à un ou plusieurs éléments qui lui sont propres.

Sous peine de sanctions, ce type de données doit faire l’objet d’un traitement particulier. Toute personne travaillant dans la qualité logicielle devrait valider que les données personnelles sont manipulées de manière légale.

1) Il est obligatoire d’assurer la sécurité des données personnelles

Comme le dit l’article 34 de la loi,

Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu’elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès.

La loi est sans équivoque : la sécurité des données personnelles relève de la responsabilité de celui qui les traite. En cas d’attaque informatique, l’entreprise victime de l’attaque peut être poursuivie en justice par ses internautes. Double effet kiss cool.

Les QA, connaissant cette problématique, doivent veiller à ce qu’elle soit soulevée au plus tôt, et si possible renforcer la sécurité des informations en pratiquant des tests de sécurité.

2) Le traitement des données doit être transparent

Les utilisateurs doivent être informés de leurs droits. Pouvoir consulter les mentions légales (dont le contenu est également réglementé) est obligatoire.

3) La localisation des données est réglementée

Transférer des données personnelles en-dehors de l’UE a des implications juridiques. Il est important de savoir vers quels pays les données personnelles peuvent être transférées. A titre d’exemple, en mars 2017, il est possible de transférer des données personnelles en Argentine, mais pas en Australie.

4) Envoyer un mail peut être un délit

Envoyer un mail ne coûte rien… mais ce n’est pas toujours autorisé. Il est interdit d’envoyer des mails commerciaux à des adresses trouvées dans des espaces considérés comme publics : pages web sans authentification, forums de discussion, annuaires.

Le cas échéant, si un internaute donne volontairement son adresse e-mail, il faut impérativement lui dire qu’il est susceptible de recevoir des offres commerciales.

Tout courrier commercial doit proposer un lien de désinscription.

Dans les formulaires, les cases à cocher proposant l’envoi de mails publicitaires doivent être décochées par défaut.

Plus d’informations ici.

5) Ne pas crypter les mots de passe peut coûter cher

Il est interdit de conserver en base de données des mots de passe non cryptés, comme Optical Center qui, en 2014, en a fait les frais. 50 000 euros d’amende ont dû être déboursés. Un coût financier mais aussi réputationnel… A cet effet, la CNIL donne des éléments pour mettre les mots de passe en sécurité.

6) Stocker certaines données est interdit

Une donnée sensible, au sens CNIL, concerne un ou plusieurs des aspects suivants de l’internaute :

  • ses origines raciales ou ethniques,
  • ses opinions politiques, philosophiques ou religieuses,
  • ses appartenances syndicales,
  • sa santé ou son orientation sexuelle,
  • ses données génétiques ou biométriques,
  • son passé judiciaire,
  • son numéro de sécurité sociale.

Attention, certaines données sont sensibles sans en avoir l’air. Vous demandez à vos utilisateurs s’ils sont végétariens, végans, au régime sans gluten, sans oeufs, sans porc, sans lactose ? Sans le savoir, vous êtes sur le point de stocker une donnée sensible dans votre base de données. Demandez-vous si le risque en vaut la peine.

Le traitement des données sensibles est en principe interdit. Si ces informations sont vraiment nécessaires, leur recueil doit être justifié et nécessite le consentement exprès de la personne. Par prudence, il est conseillé de demander un avis sur les données sensibles à la CNIL, voire une demande d’autorisation (obligatoire par exemple pour le numéro de sécurité sociale). Attention, la réponse peut prendre quelques mois avant d’arriver.

Toutes les données sensibles sont concernées : celles déclarées par les utilisateurs sur le site, celles recueillies “IRL” et informatisées ensuite, et même si ces informations sont prévues pour être utilisées strictement en interne. La CNIL donne une définition précise de la donnée sensible.

7) Il est interdit de placer un cookie sans autorisation

Il est obligatoire de :

  • communiquer aux internautes la finalité des cookies
  • demander leur consentement (dont la durée maximale de validité est de 13 mois)
  • leur fournir un moyen de refuser les cookies.

Et tout cela, avant de générer le cookie.

En savoir plus sur les cookies

Respecter la propriété intellectuelle

8) Les contenus textuels et multimédias doivent être contrôlés

Des questions de bon sens sont de rigueur :

  • Les contenus affichés par le système à tester appartiennent-ils à sa société éditrice ? Si non, les autorisations idoines ont-elle été produites ?
  • Les crédits sont-ils correctement mentionnés ?
  • Le droit de courte citation est-il correctement appliqué ? Le contenu est-il exempt de plagiat ?
  • Les personnes dont les photos apparaissent ont-elle donné une autorisation explicite ?

Quelques vérifications bien utiles, qui prendront peu de temps à l’équipe de test et pourront éviter litiges et bad buzz.

9) Les briques open-source peuvent imposer des contraintes qu’il faut respecter

Si le produit comprend des briques issues de programmes open-source, il est essentiel de respecter la licence qui leur est associée. Attention, certains logiciels open-source obligent à partager leurs versions modifiées (par exemple avec la licence GNU GPL).

Conclusion

Certes, les QA ne sont pas des juristes. Dans une vision 360° de la qualité, nous devons pourtant être capables de porter un regard critique sur les aspects juridiques du système à tester. Les champs d’étude sont extrêmement vastes : il faudrait encore parler du droit à l’oubli, des lois propres aux sites de e-commerce… Nous ne saurions assez vous conseiller d’investiguer afin de comprendre jusqu’où les tests peuvent aller.

Bonus

Performance, charge, stress… quelle différence ?

Vocabulaire ISTQB : on fait le point !

Dans le domaine du test comme ailleurs, il est important de bien nommer les choses afin de partager un langage commun avec ses interlocuteurs.

Quelle est donc la différence entre un test de charge et un test de performance ? S’agit-il de la même chose que d’un test de stress ? De robustesse ?… Sans avoir connaissance des définitions précises de ces termes, il est facile de s’emmêler les pinceaux.

Or, il arrive que des sons de cloche ne s’accordent pas, et par exemple que des sites se contredisent entre eux. Pourquoi ? D’une part, parce que les tests se ressemblent et mettent parfois en jeu les mêmes outils. D’autre part, parce que les termes évoquent des choses similaires ; dans la vie de tous les jours, on peut dire qu’une équipe performante est capable de tenir une grosse charge de travail en gérant bien son stress.

Il est donc important de se baser sur une source qui fasse autorité et permette de trancher ! Ici, nous nous réfèrerons au glossaire officiel de l’ISTQB, un “must-have” et un “must-read” pour les testeurs.  Plongeons-nous donc dans les définitions de ces termes !

Qu’est-ce qu’un test de performance ?

Test de performance : le processus de test pour déterminer les performances d‘un produit logiciel.

Performance : degré en fonction duquel le système ou composant accomplit les fonctions qui lui sont affectées dans le respect de contraintes données en ce qui concerne son temps d‘exécution et taux de débit. [d‘après IEEE 610]

Le but du test de performance est de fournir des métriques sur la rapidité de l’application. On veut déterminer si elle est capable d’exécuter ses fonctionnalités en un temps acceptable. La priorité n’est pas de connaître les performances de l’application dans un contexte particulier. Pour cela, un autre type de test peut être distingué : le test de rendement.

Le test de performance répond à la question : l’application est-elle suffisamment rapide ?

Des APIs permettent de diagnostiquer rapidement les problèmes de performances d’une page web. La plus utilisée est certainement PageSpeed, développée par Google. Elle founit un score sur 100, ainsi que des pistes pour améliorer la vitesse de chargement de la page.

Amusez-vous à utiliser cette ressource pour évaluer la performance de votre site web !

Voici par exemple les résultats du calcul des performances du site Testeum :

Qu’est-ce qu’un test de rendement ?

Test de rendement : le processus de test pour déterminer le rendement d‘un produit logiciel.

Rendement : la capacité du produit logiciel à fournir des performances appropriées, relatives au niveau de ressources utilisées dans des conditions spécifiées. [ISO 9126]

Le test de rendement introduit la notion de “conditions”. Le test de rendement permet d’établir un rapport entre performances et ressources utilisées dans un contexte réaliste (ex : plusieurs utilisateurs connectés en même temps, réalisant des requêtes consommant plus ou moins de ressources).

Le test de rendement répond à la question : l’application est-elle suffisamment rapide dans un contexte donné ?

Qu’est-ce qu’un test de charge ?

Test de charge : un type de test concerné par la mesure du comportement d‘un composant ou système avec une charge croissante, p.ex. nombre d‘utilisateurs et/ou nombre de transactions en parallèle pour déterminer quelle charge peut être gérée par le composant ou système

Le test de charge recherche la limite des capacités de l’application. En augmentant graduellement la charge à laquelle est soumise l’application, il est possible d’identifier des paliers. On peut considérer le test de charge comme un pré-requis au test de stress.

Le test de charge répond à la question : quelle est la charge maximale supportée par l’application ?

Qu’est-ce qu’un test de stress ?

Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l‘accès mémoire ou serveurs [d‘après IEEE 610].

Le test de stress permet d’anticiper les performances d’une application en contexte exceptionnel (afflux non anticipé d’utilisateurs, panne). Un cas d’école : l’explosion des visites sur un site de e-commerce le premier jour des soldes. On peut considérer le test de stress comme une catégorie de test de robustesse.

Le test de stress répond à la question : comment réagit l’application lorsqu’elle est soumise à sa charge maximale ?

Qu’est-ce qu’un test de robustesse ?

Test de robustesse : test concernant le degré pour lequel un composant ou système peut fonctionner correctement en présence de données d‘entrée invalides ou de conditions environnementales stressantes.

Le test de robustesse permet de vérifier qu’une application reste opérationnelle en contexte exceptionnel. Les menaces testées viennent aussi bien d’une charge importante (comme le test de stress) que de comportements non souhaités (flux d’informations incorrectes, de fichiers corrompus…)

Le test de robustesse répond à la question : comment réagit l’application lorsqu’elle est soumise à des inputs ou un contexte exceptionnels ?

Autant de tests non-fonctionnels…

Malgré leur synonymie apparente, les différents termes que nous venons de présenter donnent donc lieu à des tests spécifiques, que nous ne devrions pas confondre afin de maintenir une communication claire.

Envie de passer une certification ISTQB ?

Si vous souhaitez approfondir vos connaissances en test, nous organisons à la demande des accompagnements à la maîtrise d’ISTQB à Nouméa. Hightest est organisme de certification accrédité par le GASQ depuis 2015 et est habilité à organiser des examens ISTQB. Pour plus d’informations, veuillez prendre contact avec nous !

Et pour vos révisions, jetez un oeil à notre article Les 7 principes généraux du test en illustrations et à nos différents quiz en ligne !

3 maladies de l’automatisation des tests

Le testeur chargé de l’automatisation des tests est vulnérable à des troubles qui lui sont propres. Il est important de les connaître pour mieux s’en protéger.

La logopathie – Trouble cognitif

Symptôme

Le patient est le seul de son équipe à pouvoir lire les logs produits par ses tests automatisés. Souffrant d’une apparente dissonnance cognitive, il énonce des propos déroutants tels que “Tous ceux-ci ne passent pas mais c’est normal”.

Cause

Trop absorbé par le développement de ses automates, le patient a négligé la qualité du reporting, un élément pourtant nécessaire à la compréhension des résultats des tests.

Complications possibles

  • L’équipe devient dépendante de son testeur automaticien. Par conséquent, s’il est absent, il est impossible d’analyser les résultats des tests automatisés.
  • Analyser les logs devient si compliqué que, par manque de temps, on ne lance plus les tests automatisés. Tout le temps consacré à ce travail est désormais perdu.
  • Dans le pire des cas, on finit par abandonner l’automatisation des tests.

Mesures préventives

  • Utiliser un framework de test BDD : Gebish, Cucumber… qui prendra en charge nativement un reporting d’une clarté satisfaisante.
  • A défaut, anticiper cette problématique dès le début du projet d’automatisation. Pour chaque étape du test automatisé, générer un log en bon français. Il est également important de faire savoir où se trouvent les reportings, afin que les personnes concernées puissent les trouver en toute autonomie.

Remèdes possibles

Allouer du temps à cette problématique en communiquant sur son importance. Chiffrer les gains de temps possibles en analyse.

Si vous utilisez Selenium, une petite virée sur notre article dédié à la qualité des logs Selenium vous redonnera des couleurs.

Troubles associés

Le documutisme (trouble de la communication). Le patient n’a pas conscience de la complexité de son projet et/ou ressent une aversion envers les tâches documentaires. Il en résulte une aura de mystère autour des travaux d’automatisation des tests. Seuls quelques proches du patient ont été instruits de bouche à oreille et sont en mesure de comprendre, de loin en loin, ce dont il est question.

L’automatite – Trouble de l’identité

Symptôme

Le patient agit davantage en “automaticien” qu’en testeur. Il enchaîne les scénarios et automatise au kilomètre.

Cause

Le testeur chargé de l’automatisation des tests est soumis à une forte exposition à des problématiques purement techniques. Comment cliquer sur le premier bouton visible en ignorant les boutons cachés qui le précèdent ? Comment naviguer entre 2 popups ou plus ? Comment autoriser ou interdire la géolocalisation sur tel ou tel navigateur ? Cette charge cognitive peut le mener à oublier le pourquoi au profit du comment. Le patient devrait, en temps normal, être en mesure de conserver un œil critique sur les scénarios qu’il doit automatiser.

Complications possibles

  • Faute de recul, le patient perd un temps précieux à automatiser des scénarios à faible valeur ajoutée.
  • Le patient passe à côté de bugs qu’il aurait pu trouver.
  • Les reportings perdent en pertinence.

Mesures préventives

Dès le début du projet, prévoir des rôles hybrides. La dichotomie entre le testeur manuel et le testeur automaticien, décriée par certains, pourrait être néfaste au métabolisme de l’équipe de test.

Vu sur https://mrslavchev.com

Remèdes possibles

Redonner une vision d’ensemble de la qualité du produit en introduisant des phases de test manuel et de rédaction de cas de test dans l’emploi du temps du patient.

Troubles associés

Chez le testeur dit manuel, la checklistopathie paralyse les mêmes neurones que l’automatite. Les deux types de malades ont besoin, pour recouvrer la santé, de raviver leur curiosité et leur passion pour le fouinage logiciel.

La scalophobie – Trouble de la motricité

Symptôme

Le patient se trouve face à un projet d’automatisation des tests dont il n’a pas suffisamment étudié la scalabilité. L’architecture est brouillonne et difficile à maintenir. Le patient évolue avec difficulté au sein d’un écosystème qu’il a lui-même créé.

Cause

Avide d’avancer rapidement dans l’automatisation des scénarios, le patient a consacré un temps insuffisant à la conception de l’architecture de son projet d’automatisation.

Complications possibles

  • Importantes pertes de temps en maintenance.
  • Difficulté à intégrer de nouveaux collaborateurs dans le projet.
  • Risques accrus de contracter la logopathie

Mesures préventives

En début de projet, dédier une plage de temps suffisante à la conception de l’architecture du projet. Communiquer sur l’importance de cette phase. S’appuyer sur des design patterns éprouvés, tels que le Page Object (dont nous donnions dernièrement un exemple avec Protractor).

Remèdes possibles

Une bonne refactothérapie !

Troubles associés

La scalophobie de type documentaire, qui affecte les testeurs en charge de la rédaction des cas de test.

Conclusion

Il est essentiel de maintenir une bonne hygiène de vie afin d’éviter les maladies que nous venons de lister. Garder le cap sur les objectifs de l’automatisation, communiquer avec son entourage et conserver un recul sur ses activités permettra au testeur de rallonger l’espérance de vie de ses automates et de booster leur tonus au quotidien.

Bon courage !

Vous aimerez peut-être aussi…

Ce n’est pas un bug, c’est un poème

Les 7 principes généraux du test en illustrations

Le kit de secours métaphorique du testeur agile

Vous avez à coeur de respecter les bonnes pratiques de tests automatisés ? Cette page mémo pourrait vous être utile !

Saga de l’audiovisuel – Et l’automatisation alors ?

Saga de l’audiovisuel

Pourquoi automatiser ?

Bienvenue à nouveau dans le monde de l’audiovisuel. Nous avons évoqué les enjeux du test en télévision numérique, ainsi que les différents types de test et leur protocoles. Abordons maintenant le sujet de l’automatisation.

Les pauvres testeurs ! On trouvait ça cool nous, d’être payé à regarder la télé derrière son bureau, mais en fait c’est dur comme boulot !

Exactement, c’est pas tous les jours facile la vie de testeur dans l’audiovisuel, beaucoup de tâches répétitives, j’appuie sur la touche menu, j’observe, je mesure, et à la longue, la concentration diminue, et le risque d’erreur, de passer à côté d’une anomalie augmente.

D’autre part, durant les longues phases de test d’endurance, le testeur connaît l’état de son décodeur au lancement du test, puis à l’issue du test, mais comment savoir s’il n’y a pas eu d’erreur pendant le test, un redémarrage imprévu après lequel la set top box s’est remise sur pied d’elle même, des problèmes de qualité audio/video, un message d’erreur temporaire,…

Certains problèmes, comme un redémarrage du décodeur, peuvent-être détectés en “instrumentant” un décodeur en test, c’est-à-dire, en récupérant les logs ou traces de l’application, mais cette solution a le défaut d’influer sur les performance du décodeur, et ne reproduit pas fidèlement le comportement d’un décodeur sur le terrain qui eux sont configurés pour ne plus produire de logs.

Robots de test

Oyez, testeurs, vous n’êtes pas seuls. Quelques sociétés du secteur informatique et télécommunication, Sopra, S3 TV Technology (racheté par Accenture), ou encore Witbe on mis au point des solutions d’automatisation des test pour la télévision numérique.

Le rôle de ces équipements, ou robots de test, est de reproduire les actions d’un utilisateur réel et d’analyser les comportements du matériel testé.

Pour ce faire, un robot possède des “mains”, ou plutôt un émetteur infrarouge (ou bluetooth ou RF) contrôlable avec lequel il peut envoyer des commande au décodeur. Il possède également des “yeux”, une carte d’acquisition vidéo lui permettant de visualiser la sortie vidéo du décodeur, des “oreilles”, une carte d’acquisition audio pour récupérer la sortie audio, et pour gérer tout ça, un cerveau rapide et puissant, composé d’un processeur, de beaucoup de mémoire vive et d’algorithmes complexes lui permettant par exemple :

  • De reconnaître des images spécifiques : message d’erreur, mogo de démarrage, bannière information, ou toute autre image fixe pouvant être vue par un humain
  • De reconnaître des caractères (OCR) : numéro de chaîne, nom du programme en cours
  • De mesurer le volume audio et inversement de détecter une absence de son ou un niveau anormal
  • De détecter une image figée non prévue
  • De détecter un écran noir

Voici un schéma explicatif d’un environnement de test automatisé au moyen d’un robot de test :

 

La combinaison de toutes les fonctionnalités décrites ci-dessus, offre aux robot de test, la possibilité d’effectuer des tâches répétives et complexes de navigation, de reconnaissance des menus affichés, des mesures précises des temps de zapping ou encore de démarrage.

Les robots n’ont pas besoin de sommeil, ainsi, il peuvent observer, détecter et enregistrer toutes les anomalies survenant jour et nuit ce qui, comme nous l’avons vu précédemment peut s’avérer très utile lors des tests d’endurance.

Les robots possèdent également des capacités d’analyse de la qualité audio/vidéo (QoE pour Quality of Experience). Ils sont notamment capables de détecter des “artefacts”, qui sont des défauts de qualité comme la présence de courts écrans noirs, ou encore de macroblocs (présence de carrés anormaux sur l’image, comme quand vous regardez un film en streaming et que soudain, votre débit internet diminue, vous entendez alors des bruits étranges, les glitchs audio, et votre image se dégrade, devient, rouge, verte, violette avec pleins de carrés, comme si l’image se pixelisait.

Enfin, les capacités de reconnaissance d’image des robots permettent également de faire de la supervision afin de connaitre en temps réel la disponibilité des services vidéo (QoS pour Quality of Services) délivrés. Ce sujet s’écarte de la pure problématique qualité d’un décodeur numérique, et touche à la diffusion des programme vidéos (broadcasting). Nous y reviendrons sûrement dans un autre article.

Hommes de test

Ah on est rassurés, on ne leur demande pas d’appuyer 100 000 fois sur une touche de leur télécommande. Mais ils ne risquent pas de se faire virer si des machines peuvent faire leur travail à leur place ?

Aucune chance, et gare à celui qui viserait cet objectif. Les robots n’ont pas de perte de concentration, sont insomniaques et sont des bourreaux de travail, mais ils ont un point faible, ils ont besoin de l’Homme pour savoir quoi faire, comment le faire et pour comprendre leur langage. Ces deux là sont totalement complémentaires, symbiotiques. Les robots soulagent les testeurs en prenant en charge les tâches longues et répétitives, les testeurs, en échange les entretiennent, les optimisent, et interprètes les données qu’ils fournissent.

Le plus souvent, lorsque qu’un robot est déployé, là où il n’y avait qu’un testeur, il y a maintenant, en plus, un responsable d’exploitation chargé de l’infrastructure, de la rédaction et de la maintenance des scripts de tests.

Et côté ROI, pas d’inquiétude non plus, c’est tout de même l’un des interêts, une gestion automatisée des tests augmentera la capacité de l’équipe et la fiabilité des tests, diminuant significativement les coûts de non qualité.

Conclusion

Si nous avions un conseil à vous donner, n’ayez pas peur d’automatiser ! Que ce soit en confiance, en fiabilité, en couverture, en rapidité, vous y gagnerez. Et si nous avions un second conseil à vous donner, automatisez intelligemment ! Toutes les solutions existantes ne vous sont pas forcément nécéssaires. Prenez le soin et le temps d’étudier votre besoin et les compétences de vos équipes avant de vous jeter sur la solution la plus attirante ou la moins chère. A titre d’exemple, il vaut peut-être mieux investir dans une solution plus coûteuse mais pour laquelle l’écriture des scripts se fait dans un langage de programmation déjà connu de vos équipes. Bonne automatisation !

Découvrez nos autres séries d’articles !

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

Le kit de secours métaphorique du testeur agile