Catégorie : Méthodologie

Chez Hightest, on sait tous ce qu’est un plan de test, comme on sait tous ce qu’est un wombat ; certains en ont déjà vu en vrai, d’autres non, et ça ne nous empêche pas de faire du test. Ça vous choque ?

Le plan de test est peut-être le livrable le plus ingrat de notre métier. Comme l’écrivent des testeurs de Google dans « How Google Tests Software ? », les managers traînent avec eux des plans de test comme un enfant garde toujours son doudou avec lui. Ces documents les rassurent, mais ils ne leur accordent pas d’attention particulière, et se plaignent seulement quand ils ne sont pas là.

C’est exagéré ? Il doit quand même y avoir un fond de vérité…

Le plan de test est-il un ennemi de la qualité ?

En contexte agile notamment, mais aussi plus généralement, on comprend les risques que présenterait le fait de toujours produire un volumineux plan de test.

Un tel document peut représenter un risque projet, en ralentissant les équipes de test qui devront s’attacher à longuement rédiger ce référentiel. Et pour quel gain, si personne ne le lit ?

Il pourrait aussi présenter un risque produit, en verrouillant en quelque sorte les testeurs à un engagement à tester d’une certaine façon, au lieu de constamment faire l’effort de s’adapter au produit. En pratique d’ailleurs, la rédaction d’un plan de test en bonne et due forme n’est pas systématique.

Il n’est donc pas si étonnant que de nombreux testeurs n’aient jamais écrit ou même lu un plan de test au sens traditionnel. Faut-il en conclure que ce livrable mérite d’être rangé au grenier ?

Mais au fait, qu’est-ce qu’un plan de test ?

Voici la définition d’un plan de test d’après le « Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels » (août 2012), citant IEEE 829 :

Document décrivant l’étendue, l’approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, l’affectation des tâches, le degré d’indépendance des testeurs, l’environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser ainsi que tout risque nécessitant la planification de contingence. Il constitue la documentation du processus de planification de test.

Un template de plan de test correspondant à cette approche pourrait donc suivre la trame suivante :

• Introduction
• Présentation de l’équipe de test et de ses liens avec les autres parties prenantes
• Présentation de l’applicatif à tester
• Présentation des bases de test et de leur traçabilité avec les tests
• Liste des fonctionnalités à tester
• Liste des fonctionnalités à ne pas tester
• Techniques de conception des tests
• Techniques d’évaluation des tests
• Critères de testabilité
• Conditions de refus de la version
• Liste des livrables de test
• Liste des tâches de test en regard avec les personnes impliquées
• Risques projet et risques produit
• Planning
• Environnements requis
• Besoins spécifiques en outils
• Besoins spécifiques en formations
• Besoin spécifiques en prestations

En somme, l’ensemble des informations « méta » qui touchent à la phase de test à venir. Chacune est digne d’intérêt, mais on voit qu’il y en a beaucoup.

Revoir la définition du plan de test ?

On attend peut-être trop de choses différentes d’un seul et même document. Cette liste comprend des éléments qui aident à la coordination inter-équipes, d’autres qui ne concernent que les testeurs. Il y a des parties qui concernent le projet, d’autres qui sont tournées vers le produit.

Pour “sauver le plan de test”, il faudrait peut-être trier ces divers éléments afin d’isoler ce qui sera utile au niveau contractuel et ce qui servira de ligne de conduite pour les testeurs. C’est dans cette direction notamment qu’est parti Google.

Un plan de test au service des testeurs

Comment s’en sort Google

« How Google Tests Software ? » Le titre de ce livre est intimidant. A première vue, il laisse penser que Google travaille avec des méthodologies si sophistiquées qu’elles seront totalement inaccessibles aux « plus petits ». Surprise : leur façon de concevoir les plans de test est applicable à la plus petite équipe projet, et elle ne requiert même pas une heure. Ici, le plan de test est un document qui aide les testeurs à concevoir leurs cas de test, une trame opérationnelle à laquelle ils pourront se référer dans le temps, quitte à la faire évoluer. Avec la méthode ACC développée par Google, on va créer non pas un document de type cale-porte, mais une cartographie légère, exploitable et droit-au-but sur laquelle les testeurs pourront se baser pour écrire leurs tests.

La méthode ACC de Google : un plan de test pour ceux qui n’en ont pas le temps

La méthode ACC se base sur trois concepts : les Attributs, les Composants et les Capabilités. Ces trois concepts vont permettre de dresser un schéma de ce qu’on va avoir besoin de tester.

James Whittaker rapporte que l’exercice ne durerait pas plus de 30 minutes. Alors, on se lance ?

Les attributs : des mots pour dire « comment » c’est

La première étape du plan de test ACC est de lister les attributs de l’application.

Qu’entend-on par attribut ? Tout simplement les adjectifs dont on souhaiterait qualifier l’application en production. Des exemples ?

• Accessible
• Adaptatif
• Durable
• Facile
• Graphique
• Interactif
• Interopérable
• Navigable
• Pédagogique
• Pertinent
• Rapide
• Sécurisant
• Social
• …

Afin de garantir un maximum d’adhésion de la part des parties prenantes (et certainement d’éviter des débats sans fin), l’ouvrage suggère de tirer cette liste d’attributs de documents existants, par exemple des supports issus du marketing.

Les composants : des mots pour dire « ce que » c’est

Deuxième étape du plan de test ACC : lister les composants de l’application.

Peut-être plus simples à trouver, les composants sont les noms des fonctionnalités. Cette liste est généralement facile à trouver : on peut la tirer de cahier des charges, story-mappings, user stories, spécifications…

Ceci dit, il est intéressant de revoir cette liste. Plus généralement, ce qui va avoir du sens ici, c’est de créer une liste des entités pouvant donner lieu à des tests spécifiques.

Par exemple, si votre liste de fonctionnalités comprend « Page des nouveautés » et « Page de recherche enregistrée », et que les deux donnent lieu à des notifications, il vous faudra peut-être ajouter l’élément « Notifications » à votre liste de composants, même si cela ne figure pas dans la liste des fonctionnalités.

Les capabilités : au final, ce qu’on peut faire avec l’application

Dernière étape : lister les capabilités de l’application.

Les capabilités représentent les activités effectuées via ou par l’application ; elles sont exprimées par des verbes d’action.

La particularité de ces capabilités, c’est qu’elles se trouvent à la croisée des attributs et des composants. Par exemple, on peut imaginer que sur un client de messagerie, la capabilité « Recevoir les mails commerciaux dans un dossier dédié » correspond au composant « Liste des courriels » et à l’attribut « Bien organisé ».

Ce qui nous permet de ranger ces trois notions dans un tableau à double entrée !

Nous allons tout de suite rendre les choses plus concrètes en présentant un plan de test ACC.

Un exemple de plan de test ACC

Pour cet exemple, nous allons prendre comme exemple l’application FromageZone. FromageZone est une boutique en ligne qui permet d’acheter du fromage en s’aidant des avis d’autres utilisateurs.

Voici le support commercial de FromageZone :

Nous retenons ici 3 attributs : « Intelligent », « Simple » et « Social ». Nous allons aussi prendre la liberté d’extrapoler le terme « commander » en ajoutant l’attribut « Sécurisé », car il est impossible d’imaginer un e-commerce sans notion de sécurité des transactions.

En outre, FromageZone est une application de e-commerce dont les fonctionnalités sont les suivantes :

• Achat
• Gestion du compte utilisateur
• Liste des fromages
• Détails d’un fromage

En combinant les attributs et les composants, on peut ensuite formaliser les capabilités, ce qui nous donne notre plan de test ACC :

	Intelligent	Sécurisé	Simple	Social
Achat		Payer en ligne en toute sécurité	Passer commande en suivant un parcours simple
Gestion du compte utilisateur		Gérer de manière sécurisée ses préférences de paiement	Modifier simplement ses informations utilisateur
Liste des fromages	Visionner en premier les fromages les plus pertinents par rapport à mon profil		Naviguer dans la recherche de fromages en étant efficacement guidé	Partager les résultats d’une recherche de fromage
Détails d’un fromage	Visionner mon pourcentage de chances d’aimer ce fromage Visionner les commentaires les plus pertinents sur le fromage		Visionner simplement toutes les informations du fromage	Donner son avis sur le fromage

Chacune des cases non vides devra donner lieu à des tests.

Comment utiliser le plan de test ACC ?

Visualiser les risques

Outre le guidage de la rédaction des tests, l’ouvrage mentionne aussi la possibilité de se servir du plan de test ACC pour visualiser les risques. Chaque case sera verte, jaune ou rouge, en fonction de la moyenne des indices de risque de l’ensemble de ses capabilités. Plus simple que ça, c’est impossible !

Guider les tests exploratoires

De par sa forme tabulaire, le plan de test ACC se prête également bien à l’exercice des tests exploratoires. Lors d’une session, le testeur aura loisir de se concentrer sur une « tranche » horizontale ou verticale de ce tableau.

Limites du plan de test ACC

Certes, l’exercice du plan de test ACC pourra parfois sembler artificiel : par exemple, une capabilité pourra correspondre à deux attributs différents. Il y a également des capabilités dont on saura qu’elles existent, mais qu’on ne pourra pas lier aux attributs cités.

Il est aussi compliqué de savoir comment introduire les tests non-fonctionnels à cette approche sans faire exploser le nombre de colonnes. Ci-dessus nous prévoyions des tests de sécurité (voire également des tests d’utilisabilité), mais quid des tests de performance, de charge, d’accessibilité ?

Le plan de test ACC reste un exercice intéressant à faire, qui permet d’avoir une autre approche sur le produit. Une manière aussi de tester de nouveau une application comme si c’était la première fois.

Conclusion

Une façon de sauver le plan de test serait de convertir ce document protéiforme en un document de travail centré sur une et une seule problématique opérationnelle. Le plan de test ACC de Google est une possibilité parmi d’autres d’aller dans ce sens. Quand le plan de test traditionnel propose de répondre à la très large question “Comment vont se passer les tests ?”, cette variante se concentre sur “Que faudra-t-il tester ?”.

Et vous, quelle place donnez-vous au plan de test dans vos projets ?

Le Véritable Plan de Test

Dernièrement, nous avons organisé dans nos locaux un petit déjeuner consacré au test logiciel et aux façons d’améliorer les phases de recette. « Phases de recette » ? Eh oui, si cette expression peut sembler désuète pour un testeur habitué à travailler en mode agile, elle représente encore une réalité pour une grande partie des projets informatiques calédoniens.

En guise d’ice-breaker, nous avons proposé un jeu de notre cru : le Bingo des Recettes à la Noix.

Chaque participant se voit confronté à 24 situations ; si cela lui rappelle des souvenirs, à lui d’ajouter une gommette dans la zone correspondante.

L’objectif était de prendre la mesure des pires embrouilles (pour ne pas dire emm…) qui peuvent briser le moral des testeurs en période de recette.

Nous n’avons pas été déçus, le Bingo (rebaptisté presque aussitôt « Mur des Lamentations »…) a suscité de nombreuses discussions. Sans surprise, nous nous sommes aperçus qu’il y aurait fallu bien plus qu’un mur pour lister l’ensemble des situations malheureuses dans lesquelles on peut se retrouver en période de recette !

Voici les résultats de ce jeu, sachant qu’il y avait 15 participants.

Le grand gagnant : le manque de communication formelle

« On me parle d’une décision prise à l’oral et dont il ne reste aucune trace. »

C’est dans cette situation que le plus de participants (10) se sont reconnus.

Quand nous avons créé le jeu, nous pensions par exemple, dans des projets agiles, à des ajustements d’User Stories qui sont décidées à l’oral entre le PO et le développeur concerné, sans que la US ne soit jamais mise à jour. Nous avons déjà vu des conflits germer à cause de cela !

Voir l’article d’Atlas Management sur le sujet, « Respectons le sens des valeurs agiles ».

Qui a peur de la mise en prod ?

« J’ai peur qu’il faille mettre en prod avant la fin des tests, ou qu’il faille décaler la mise en prod. »

Ex-aequo avec la situation suivante, cette situation s’est avérée familière pour 9 participants.

On retrouve là l’emblème récurrent de la qualité comme goulot d’étranglement, des campagnes de test que l’on exécute à la fin du projet « s’il y a le temps », et autres images d’Epinal qui collent encore à la peau de notre beau métier. Et que l’on s’efforce de contredire au quotidien…

Sur ce sujet, plusieurs axes peuvent être creusés : la classique question de la couverture des tests, mais aussi la notion de « Shift-Left », que nous aborderons dans un prochain article.

Le cauchemar du testeur

« Un bug est découvert en production, je m’arrache les cheveux. »

8 personnes se sont reconnues dans cette situation. Ce qui rend les choses encore plus frustrantes, c’est quand le bug ne se manifeste qu’en production, à cause d’environnements de pré-production non iso-prods…

Des tests dysfonctionnels ?

« Les tests non-fonctionnels (performances, charge, sécurité) sont laissés de côté. »

Ce constat a été fait par 8 personnes.

C’est un mal fréquent. Comme le souligne Gojko Adzic dans un témoignage recueilli par Janet Gregory et Lisa Crispin dans More Agile Testing (édition Addison-Wesley, p. 109), la notion d’exigence non-fonctionnelle a tendance à intimider les responsables du produit. Il caricature l’attitude que l’on peut avoir, consciemment ou non, face à cette idée : « Cela va donner lieu à une discussion compliquée, laissons tomber. »

Ces tests sont pourtant accessibles à la compréhension de tous, au moins dans les grandes lignes. Voulez-vous rafraîchir votre mémoire avec notre article dédié aux tests de performance, de charge, et consorts ?

Routine contre passion

« La recette approche et je sais que la phase de tests de régression va m’ennuyer. »

8 personnes se sont reconnues. Les tests de régression, lorsqu’ils sont manuels, demandent souvent une patience pénélopique.

Contre l’ennui, qui non seulement est désagréable mais peut également amener à des attitudes dangereuses (négligence, biais de confirmation), nous avons un remède. Le mot d’ordre : toujours s’autoriser à aller au-delà du scénario de test écrit, garder son cerveau allumé (suivre un cas de test ne veut pas dire s’auto-automatiser !) et comme le dit Alan Richardson dans Dear Evil Tester, s’efforcer de toujours tester le produit comme si c’était la première fois.

Autre point important : c’est souvent au moment de l’exécution des tests qu’on peut se rendre compte de lacunes au niveau des cas de test écrits. Vous connaissez la règle du boy-scout ? Elle s’applique dans le domaine du développement, mais peut aussi être adoptée par le testeur. Ne perdez jamais une occasion d’améliorer le patrimoine de test.

Le bug pas bien méchant

« Je tombe sur un bug qui n’a jamais été remonté car « il n’est pas bien méchant ». »

Sacrilège ! Une belle collection de bugs se compose de toutes sortes de défauts ; des grands teigneux, des gros mous, des petits qui grattent, des furtifs, des mignons, des poilus, des grégaires…

Contrairement à ce qu’on est habitués à penser, les bugs ont de la valeur.

Un rapport de bug :

• fait gagner du temps aux autres testeurs
• quand il est bien fait, il en fait aussi gagner aux développeurs
• permet parfois d’imaginer de nouvelles fonctionnalités
• permet parfois d’envisager des refontes de l’implémentation.

Alors pas d’excuse, rapportez ce tout petit bug minuscule que vous serez (ou pas !) la seule personne à avoir jamais vu !

Et les autres…

Voici les autres situations proposée dans notre Bingo, de la plus à la moins fréquente.

• « Je découvre que l’environnement de pré-prod n’est pas identique à celui de la prod. »
• « Je découvre un bug que personne n’a vu et qui est en prod depuis des mois. » A ce sujet, vous aimerez peut-être lire cet article…
• « Un dev me rétorque que « ce n’était pas dans les specs ». »
• « Un dev me rétorque que ça marche sur sa machine. »
• « Je mets à jour le patrimoine de test : ça me prend 150 ans. »
• « J’ai l’impression que les tests ne couvrent pas tout mais je ne vois pas comment vérifier. »
• « Je ne sais pas ce que contient exactement la dernière version. »
• « Un bug corrigé réapparaît dans une version ultérieure. »
• « Personne ne peut me dire si ce comportement relève du bug ou non. »
• « L’application fonctionne sur Window 7 avec IE11. Pour le reste, on se fie à notre karma. » Selon un sondage récent auquel une centaine de testeurs ont répondu, il est apparu que 79 % des répondants ne faisaient pas de tests de portabilité !
• « Quelqu’un dit « Il faudrait automatiser cela » mais personne n’en aura le temps. »
• « Je me retrouve dans un dialogue de sourds où chacun parle un jargon différent. »
• « J’ai l’impression d’avoir déjà vu ce bug mais je ne sais plus par quel canal il a été remonté. »
• « Je rejoue un test car je ne suis pas sûr.e qu’il ait été joué. »
• « J’ai trouvé le bug de l’année mais je n’arrive à le reproduire que quand je suis tout.e seul.e. »
• « J’ai créé 387 bugs mais aucun ne semble devoir être traité dans la décennie qui vient. »
• « Une recette c’est comme un accouchement, à chaque fois c’est différent. » Cette phrase nous vient d’une testeuse que nous avons rencontrée lors d’une mission, une phrase accrocheuse qui nous a bien fait rire !
• « Je ne trouve pas de bug dans cette version. Je trouve ça louche, très louche. »

Un de nos participants a souligné un biais dans notre Bingo : nous n’avons pas mentionné l’absence totale de tests… Cela nous a fait froid dans le dos ; qui sait le nombre de gommettes qu’aurait reçu cette situation ?

Et vous, qu’auriez-vous ajouté à ce Bingo ?

Merci à tous les participants de notre petit déjeuner, et à bientôt pour un autre événement de ce type !

Retrouvez nos autres jeux dans leurs articles dédiés :

• Réunion de clôture, un jeu pour finir en beauté (inspiré, de très loin, du Trivial Pursuit)
• Un jeu pour sensibiliser aux tests unitaires (un casse-tête qui vous empêchera de dormir)

Vous êtes un vieux de la vieille, vous avez passé le niveau Foundation il y a belle lurette (et peut-être d’autres certifications entre-temps, si oui bravo). Vous n’avez pas le temps ni l’envie de vous replonger dans la Bible du testeur, et pourtant vous vous demandez ce qui a pu changer entre 2011 et 2018. Ca tombe bien, cet article est fait pour ça !

Comment connaître précisément les évolutions du syllabus ?

EDIT d’octobre 2020 : auparavant existant une liste des évolutions entre les deux versions, qui indiquait les changements de manière systématique. Ce document nous a bien aidés pendant la rédaction de cet article, malheureusement il n’est plus disponible.

Au passage, voici le lien vers la version de 2011 du syllabus, et la version de 2018.

Y a-t-il plus de contenu dans la nouvelle version du syllabus ?

Oui, un peu plus, on passe de 82 à 96 pages.

Y a-t-il de nouveaux chapitres ?

Le document listant les évolutions du syllabus indique la création de 6 nouveaux sous-chapitres, mais pour certains il s’agit de thématiques déjà traitées dans la version précédentes, qui ont simplement été structurées différemment.

Les sous-chapitres totalement nouveaux sont les suivants :

• 1.4.1 : « Le processus de test dans le contexte », p. 18
• 3.2.4 : « Application des techniques de revue », p. 54
• 4.4.3 : « Tests basés sur des checklists », p. 65

Qu’est-ce qui a disparu ?

Le code d’éthique, qui était en 1.6.

La nouvelle version du syllabus est-elle plus agile ?

Globalement oui. Des notions propres à l’agilité, et qui étaient absentes dans la version de 2011, sont maintenant évoquées au fil du syllabus. Cela permet de se raccrocher plus facilement à des situations connues et au vocabulaire désormais couramment employé dans les organisations.

Les méthodes et techniques de test agile font cependant l’objet d’une certification à part, l’extension Testeur Agile, qui a aussi son syllabus, daté de 2014.

Exemples de termes apparus entre 2011 et 2018 :

• User Story (26 fois). La User Story est citée comme une base de test (ce sur quoi on se base pour définir les scénarios de test), mais aussi comme un document que le testeur peut aider à raffiner pour éviter les bugs liés aux ambiguïtés.
• Epic (4 fois). Idem que pour User Story.
• Product Owner (9 fois). Ce rôle ainsi que les responsabilités qui lui sont associées sont évoquées dans certains exemples qui permettent encore une fois de faire appel à des situations connues, qui parleront à un maximum de testeurs.

De nouveaux types de tests sont-ils évoqués ?

Oui, notamment les tests d’accessibilité, qui sont mentionnés brièvement à 3 reprises.

Les tests non-fonctionnels sont plus souvent mentionnés (37 fois contre 18 dans la version d’avant).

Quid de l’aspect psychologique des tests ?

Ces dernières années, des articles très intéressants sur les biais cognitifs du testeur sont apparus dans la communauté scientifique (par exemple « Cognitive Biases in Software Quality and Testing » de Iflaah Salman) ainsi que sur le web (voir la série d’articles dédiée sur LyonTesting). Il est satisfaisant de voir que cette notion de biais, absente dans la version de 2011, est aussi régulièrement évoquée dans la version de 2018 (11 fois).

En tant que testeur, il est important de savoir remarquer ses propres automatismes mentaux pour prendre du recul sur sa pratique et améliorer ses tests. Ces passages sur les biais cognitifs sont appréciés donnent de la profondeur au syllabus.

De plus, cette notion permet d’apporter certaines nuances au contenu du syllabus. On ne sous-entend plus que le testeur a une vision plus objective du produit, mais qu’il a des biais différents de ceux qui en sont les auteurs. Cette reformulation est tout à fait constructive.

Y a-t-il un 8^ème principe du test logiciel ?

Eh… non ! On reste sur le nombre magique de 7.

Quelques changements cependant : le principe 3, « Tester tôt » devient « Tester tôt économise du temps et de l’argent ». Ce même principe évoque maintenant la notion de « shift left », absente dans la version précédente.

Le principe 6 (« Les tests dépendent du contexte ») n’indique plus seulement le contexte produit, mais aussi le contexte projet : « le test dans un projet agile est effectué différemment du test dans un projet à cycle de vie séquentiel ». Cela fait écho au nouveau sous-chapitre 1.4.1, « Le processus de test dans le contexte ».

Pour réviser les 7 principes du test logiciel, on vous suggère de regarder nos broderies faites main sur ce sujet !

Le style du syllabus est-il moins austère ?

Oui, de manière générale le syllabus nous a semblé plus digeste. Les phrases sont moins alambiquées, plus naturelles qu’auparavant.

Les exemples sont plus nombreux (on passe de 53 à 96 « par exemple » !) et mieux expliqués.

La mise en page est également plus claire, avec notamment davantage de listes à puces.

Autres remarques stylistique

Certains anglicismes ont été supprimés (« bug » est devenu « bogue »).

Le métier de testeur n’a pas été féminisé, il n’est nulle part question de « testeuse ».

Faut-il relire le syllabus ?

Oui, allez-y ! Bonne lecture à vous !

Pssst : la photo utilisée pour l’image de couverture de cet article est de Gilles San Martin, un professionnel du portrait de bugs. De nombreuses ressources sont disponibles sur son profil Flickr.

De retour chez vous en fin de journée, avez-vous déjà découvert dans le miroir que vous aviez de la salade dans les dents ? “Tous ces gens qui l’ont vu et qui ne m’ont rien dit !” En tant que QA, c’est ce genre de malaise que l’on ressent lorsqu’on trouve un bug et que l’on se rend compte qu’il est déjà en production depuis plusieurs mois. Mais à quel point devons-nous espérer que les internautes lambda remontent des anomalies ? Et si l’on renverse les points de vue, dans quelle mesure peut-on considérer que rapporter un bug est un devoir ?

Premier constat : rapporter des bugs n’amuse personne

(… sauf les QA ?)

En tant qu’internaute, nous poursuivons un but qui nous est propre. Quand nous rencontrons un bug non bloquant, le plus simple est de le contourner. Lorsqu’au contraire on se retrouve dans un cul de sac, avant de prendre la décision de demander de l’aide, on réévalue notre but initial.

• Est-ce que ça peut attendre ? Je réessaierai plus tard.
• Est-ce vraiment indispensable tout de suite ? Je laisse tomber complètement, ou bien je bascule sur un service concurrent.

Résultat : les entreprises reçoivent essentiellement des feedbacks de personnes irrémédiablement bloquées dans leur navigation. Encore faut-il ensuite faire le tri entre les demandes d’assistance (mécompréhension de l’application) et les “vrais” bugs.

En général, il y a donc une grosse perte d’informations. C’est bien sûr dommageable pour l’organisation concernée.

Une question de confiance ?

Au fond, tout le monde pourrait faire le calcul et envisager les gains, pour soi et pour les autres, d’une remontée d’anomalie. Pourquoi n’est-ce pas le cas ?

Outre les problématiques habituelles de manque de temps, peut-être est-ce parce que le chemin paraît incertain et que l’entreprise semble injoignable. Un formulaire de contact trop généraliste ou difficile d’accès suffit certainement à décourager.

A titre d’exemple, Facebook semble dissimuler à dessein son formulaire de remontée d’anomalies, et tout dans le parcours qui suit invite plutôt à changer d’avis.

Premièrement, il faut cliquer sur le bouton “point d’interrogation”. Pour quelle raison ? Vouloir communiquer un problème et se poser une question, ce n’est pas la même chose.

Deuxièmement, il faut cliquer sur l’option “Signaler un problème”, précédée d’une icône en forme de point d’exclamation (ah, là c’est plus cohérent !)

Troisièmement, quatre options, assez hétéroclites, se présentent dans une modale. Il faut cliquer sur “Quelque chose ne fonctionne pas”.

Un formulaire de rapport de bug s’ouvre enfin, qui permet de saisir son problème.

Pour finir, un message de remerciement un peu mielleux affiche (ironie du sort !) une liste d’anomalies connues, qu’il eût été bien avisé de positionner avant l’accès au formulaire.

Cette sinueuse suite d’étapes n’incite pas à la remontée d’anomalies, et pourtant Facebook fait partie des sites les plus fréquentés au monde.

Pour favoriser ces usages, il faudrait adapter le design des applications pour éviter des efforts inutiles (ainsi que le travail de dédoublonnage des anomalies en aval), et lui assurer, si la remontée d’anomalie est bel et bien nécessaire :

• que son retour sera traité en un laps de temps donné
• qu’on l’informera du traitement de “son” anomalie le cas échéant.

Éventuellement, une compensation (réelle ou symbolique) pourrait lui être attribuée le cas échéant.

En rendant à la fois familier et attractif le processus de remontée d’anomalies, il serait alors possible d’engager véritablement sa clientèle dans la qualité des services numériques.

La démarche n’en est qu’à ses débuts, même si l’on peut observer ici et là quelques petites trouvailles d’UX (comme l’onglet ci-dessous, discret mais toujours présent sur l’interface web d’AdopteUnMec.com).

Cependant, au moins deux domaines contredisent ce premier constat : la sécurité informatique et le monde du jeu vidéo.

Sécurité informatique : une symbiose plus ou moins organisée

Les échanges entre le public et entreprises peuvent être assez intenses concernant l’aspect de la sécurité logicielle. Il s’agit alors essentiellement de personnes expertes en la matière qui recherchent activement des failles de sécurité. Leurs motivations peuvent être de toutes natures. Elles sont tantôt sociétales, visant à protéger la communauté (dans ce cas, on est clairement dans une optique de devoir citoyen). Elles peuvent également être vénales dans une certaine mesure, si l’on tient compte des politiques de “bugs bounties” mises en place par les grands noms du web ou des opportunités de recrutement occasionnées. Le processus de feedback est parfois structuré de manière à inclure les hackers white-hat dans la chaîne de production logicielle.

Dernièrement, ce fonctionnement a reçu de la part de l’Union Européenne une véritable reconnaissance dans la mesure où cette institution a lancé en 2019 un bug bounty sur quinze des logiciels libres très utilisés (dont VLC, Drupal, Notepad++ et FileZilla).

Les médias évoquent l’initiative avec enthousiasme, scandant avec gourmandise les montants des rémunérations hypothétiques. Rappelons tout de même que cette « chasse au trésor » ne profitera qu’à ceux qui trouveront des anomalies (pour la première fois), et non à ceux qui confirmeront, par l’échec de leurs tentatives d’intrusion, la robustesse des applicatifs. Pourtant, l’une et l’autre de ces issues ont de l’importance. Il y a un décalage paradoxal entre l’urgence des enjeux de sécurité informatique et les moyens déployés, qui reproduisent sans complexe le mécanisme de la machine à sous, où seul l’alignement des trois paires de cerises profitera au joueur assidu.

Early-access : un pacte sous le sceau de la qualité

Tu paies tout ou partie du prix du produit, et tu obtiens en accès anticipé une version inachevée de celui-ci. Dans le monde du biscuit, on aurait droit à des paquets d’Oreo à 50 XPF, pour découvrir peut-être que certains ne contiennent pas de crème vanillée (ou sont même carrément immangeables, carbonisés). Quelques mois plus tard, on recevrait éventuellement un deuxième paquet gratuit, rempli de biscuits parfaits. Ce contrat vous conviendrait-il ?

Les offres d’accès anticipé (ou early-access) sont très variées et comportent toutes un risque : le jeu pourrait très bien s’avérer rempli de bugs et ne jamais être finalisé. Certains jeux passent par des rebondissements des plus burlesques. D’autres sortent au bout de plusieurs années, comme DayZ qui est resté en version alpha de décembre 2013 à décembre 2018. Nombreux sont ceux qui se découragent de voir sortir un jour Star Citizen, en alpha depuis juin 2014.

Le early-access, en résumé, c’est un pacte entre un joueur enthousiasmé par un produit, et une équipe de développement ayant besoin d’alimenter leur trésorerie avant la release finale.

Les retours sur la qualité (et surtout sur les bugs ou glitches) du jeu sont très bienvenus. Voir par exemple les consignes de rapport d’anomalie prodiguées par l’équipe de Sad Square, éditeur du jeu Visage dont le jeu est sorti en accès anticipé en octobre dernier. Le joueur est invité d’abord à vérifier si « son » bug a déjà été rapporté, à trouver un moyen de le reproduire, puis à rédiger le rapport en tant que tel en suivant une trame prédéfinie, comprenant les informations de jeu, les étapes de reproduction, etc. Pour être rigoureux, il n’est pas excessif de penser que le processus entier dure entre 15 minutes voire 30 minutes au minimum.

Sans cette sollicitation de rapports de bugs, on pourrait comparer le modèle du early-access à la vente de billets pour les pool parties du Kuendu Beach, qui sont à 1500 XPF en pré-vente et 2500 XPF sur place. Le produit est le même, mais ceux qui prennent le risque de payer à l’avance (sans savoir par exemple s’il pleuvra des cordes le jour même) sont récompensés par un prix plus avantageux.

Mais force est de constater que le rôle du joueur va plus loin que ça. On peut considérer que les bénéficiaires de l’accès anticipé sont amenés à réaliser un travail de testeur, un travail rémunéré par avance, au forfait, grâce au tarif préférentiel. La frontière entre producteur et consommateur se brouille. La responsabilité de la qualité semble de déplacer du côté de l’utilisateur, et le travail du testeur se cantonner à un forfait bloqué, au-delà duquel il faudra œuvrer bénévolement, pour l’amour de l’art.

Si cette problématique vous intéresse, nous vous conseillons cet article de fond consacré au modèle économique de l’accès anticipé.

Une question de responsabilités ?

Faire participer les utilisateurs à la remontée des anomalies et plus globalement à la démarche qualité d’un produit pose donc un certain nombre de problèmes, et en premier lieu celui de la responsabilité.

Marie-Anne Dujarier, dans son essai Le Travail du consommateur, De Mac Do à eBay : comment nous coproduisons ce que nous achetons, met au jour la manière dont un certain nombre de tâches ont été déléguées aux consommateurs, que ce soit dans le monde physique (peser ses fruits et légumes au supermarché) ou numérique (faire la promotion d’une marque sur les réseaux sociaux). Ce phénomène est une véritable tendance de fond qui s’invite subrepticement dans nos vies. Il structure parfois des processus auxquels on ne peut pas échapper, comme si nous étions une partie d’une chaîne de production minutieusement conçus ; impossible par exemple d’attendre à une table au Mac Donald que l’on prenne notre commande, comme de quitter ladite en laissant les reliefs du repas aux soins d’un inexistant employé de salle. Lorsqu’un client entre dans un fast-food, il accepte tacitement le rôle que l’enseigne lui confère. D’ailleurs, s’il s’assied à une table souillée de soda et de frites, ce n’est pas à la chaîne qu’il s’en prendra dans ses vitupérations, mais bien à l’incivilité de ses semblables.

De la même manière, un produit buggé sera-t-il à terme la faute des utilisateurs réputés négligents, dont on aurait attendu qu’ils préviennent dès que possible les équipes techniques ?

Il faudrait trouver un équilibre entre optimisation de la qualité à l’aide des utilisateurs d’une part et responsabilisation des éditeurs d’autre part. Exercice difficile qui, nous l’espérons, s’illustrera dans les années à venir par des dispositifs innovants.

Pour finir sur une note pragmatique, en tant qu’utilisateur, nous vous proposons de retenir ces derniers points :

• Si vous avez payé pour accéder au produit, vous n’êtes pas tenu de fournir un travail bénévole à son éditeur.
• Si vous n’avez pas payé pour accéder à ce produit mais que son modèle économique repose sur l’exploitation de vos données, vous n’êtes pas non plus tenu de fournir un travail bénévole à son éditeur.
• Toute contribution bénévole à l’amélioration de ce produit est un acte surérogatoire qui vous honore, et non un devoir qui vous incombe.
• Tentez d’obtenir une compensation proportionnelle en tant qu’échange de bons procédés (bon d’achat, réduction, entrée gratuite…)

En parallèle, à nous d’inventer les meilleures façons d’écouter nos utilisateurs, mais aussi et surtout de compenser leurs efforts.

Le crowdtesting comme filet de sécurité

Le crowdtesting, ou test participatif, représente un moyen d’anticiper les problématiques rencontrées en production par les utilisateurs réels. En général, les campagnes de test participatif ont lieu en amont d’une mise en production. On peut voir cette pratique comme un filet de sécurité, en complément des canaux à mettre en place pour permettre à l’ensemble des utilisateurs de remonter les anomalies trouvées.

Le crowdtesting prévoit une rémunération pour les testeurs ; la relation gagnant-gagnant est garantie dès le début. Sur la plateforme Testeum par exemple, la rémunération est identique que l’on trouve des anomalies ou non, ce qui garantit le paiement des testeurs.

Pour continuer d’explorer ce sujet, nous vous suggérons également de consulter l’article “Why I don’t report bugs“, de Cassandra H. L.

Dans l’article précédent, nous parlions d’un de nos jeux permettant de clôturer un projet en faisant le point dans la bonne humeur. Aujourd’hui ça continue, car c’est important de jouer avec la qualité !

Les tests unitaires : une expérience à vivre

Dans certaines organisations, il existe une dette technique importante concernant les tests unitaires. Mettre en œuvre une reprise de cette dette demande du temps et du budget, et il est important que les décisionnaires comprennent précisément l’intérêt d’un tel chantier. Le problème : les tests unitaires sont généralement dans la partie invisible de l’iceberg.

Le jeu présenté ici va permettre de répondre à cette problématique. Il va être question de développer une application sans tests unitaires, puis avec ; une application constituée non pas de classes, de méthodes, d’API et de bases de données, mais de cartes à jouer !

Le jeu : “Avec ou sans tests unitaires ?”

Combien peuvent jouer ?

Vous pouvez jouer à ce jeu de 2 à N personnes, la seule limite étant l’espace et le nombre de jeux de cartes dont vous disposerez !

Une personne doit endosser le rôle de sentinelle de la qualité (super classe, non ?). A vue de nez, ce sera vous !

Matériel

• 2 jeux de cartes par équipe (idéalement, une équipe ne dépassera pas les 4 personnes). Il est possible de ne jouer qu’avec une équipe.
• De quoi montrer les règles de gestion (projecteur, fiches imprimées…)
• Un chronomètre

Déroulement du jeu

Le jeu se joue en 2 sessions de 10 tours, qui simulent 10 sprints.

Au début de chaque session, l’application est composée de 4 cartes tirées au hasard dans le jeu (on part rarement de rien…) Il n’est pas important de conserver ces 4 cartes au cours de la partie, cela constitue simplement un point de départ.

La sentinelle lance un chronomètre, ce qui va constituer un levier de pression en cas de bavardage entre les participants ! En effet, la deadline est dans 10 minutes, mais comme ça arrive parfois, la mise en prod risque d’être décalée…

A chacun des 10 tours, une règle est lue par la sentinelle. La règle du tour est lue par la sentinelle uniquement pendant le tour N. Elle peut être répétée à volonté au cours du tour, mais en aucun cas après. La sentinelle peut être assez tranchante sur ce point :

« La règle du tour d’avant ? Vous devriez vous en souvenir ! ».

On passe au tour suivant dès que les « devs » considèrent que c’est terminé.

Bien sûr, toutes les règles doivent être respectées à l’issue des 10 tours.

Une autre phrase peut être retenue, par exemple si les personnes se posent des questions sur la meilleure implémentation à fournir :

« Je me fiche des détails techniques, je veux juste que l’application corresponde à toutes mes règles métier. »

Il n’y a pas de temps limite, mais la sentinelle est invitée à presser et stresser les devs. La durée visée est de 10 minutes par session.

Tous les membres de l’équipe ont le même rôle. C’est à l’équipe de valider à l’issue des 10 sprints que l’application fonctionne comme demandé.

Première session

Les règles de la première session sont les suivantes :

1. La plus petite carte de carreau a sa jumelle dans tous les autres signes.
2. Toutes les cartes de trèfle sont présentes en double.
3. Le code contient deux piques de plus que de trèfle.
4. Le code ne doit pas contenir de 2, 4, 6 et 10.
5. Les dames et les as sont respectivement présents en nombre impair.
6. Il n’y a pas de carte de carreau inférieure au valet.
7. Toutes les cartes de trèfle ont au moins une jumelle dans les piques, mais l’inverse n’est pas forcément vrai.
8. Toutes les cartes de pique ont au moins une jumelle dans les cœurs, mais l’inverse n’est pas forcément vrai.
9. Le nombre de cartes de carreau correspond au plus petit nombre que l’on peut trouver sur une carte de cœur.
10. Il y a 2 fois plus de cartes de cœur que de cartes de pique.

A la fin de la session, la sentinelle montre l’ensemble des 10 règles qui ont été lues à tour de rôle, et les équipes comptent le nombre de règles qu’elles ont et n’ont pas respectées.

Après cela, la sentinelle peut éventuellement interroger les équipes. Quelques idées de questions :

• Quels ont été vos ressentis pendant cette session ?
• Avez-vous été plus rapides au début ou à la fin des 10 sprints ?
• La qualité était-elle meilleure au début ou à la fin des 10 sprints ?
• Comment a évolué l’ambiance de l’équipe au cours des 10 sprints ?
• Que faudrait-il améliorer ?
• Que pourrait-on changer ?

NB : si des personnes vous rétorquent que des règles se contredisent, vous pourrez leur présenter a posteriori une solution possible :

Coeur	Pique	Trèfle	Carreau
1 K Q Q V V 9 9	1 K K Q	1 1	1

Deuxième session

La deuxième session se déroule comme la première, à la différence que cette fois, la sentinelle met à disposition des équipes chaque RG énoncée. Ainsi, au tour 4, les personnes auront accès aux RG 1, 2, 3 et 4.

Les règles de la deuxième session sont les suivantes :

1. Toutes les cartes de cœur sont présentes en double.
2. Le nombre de cartes de trèfle correspond au plus petit nombre que l’on peut trouver sur une carte de pique.
3. La plus petite carte de trèfle a sa jumelle dans tous les autres signes.
4. Il y a 2 fois plus de cartes de pique que de cartes de carreau.
5. Il n’y a pas de carte de trèfle inférieure au valet.
6. Les dames et les as sont présents en nombre impair.
7. Le code contient deux carreaux de plus que de cœur.
8. Le code ne doit pas contenir de 2, 4, 6 et 10.
9. Toutes les cartes de cœur ont au moins une jumelle dans les carreaux, mais l’inverse n’est pas forcément vrai.
10. Toutes les cartes de carreau ont au moins une jumelle dans les piques, mais l’inverse n’est pas forcément vrai.

Les règles des deux sessions sont les mêmes, seuls les signes changent et l’ordre d’énonciation des règles ! Une solution possible pour la deuxième session est donc :

Pique	Carreau	Coeur	Trèfle
1 K Q Q V V 9 9	1 K K Q	1 1	1

Prévoyez un temps d’échange après la deuxième session. Les mêmes questions qu’après la première session pourront être posées. Vous verrez les parallèles s’établir entre les vérifications humaines et les tests unitaires (beaucoup plus rapides soit dit en passant !)

La conclusion naturelle de ce jeu sera : les TU permettent de vérifier à tout moment la présence de régression, et même de les anticiper.

Un bon préambule avant d’organiser en pratique la résolution de la dette technique.

Bon jeu et bons échanges autour des tests unitaires !

Vous aimerez peut-être…

Nos autres jeux :

• Le Bingo des Recettes à la Noix
• Notre jeu pour pimenter les réunions de clôture, inspiré (de très loin) du Trivial Pursuit
• Notre série sur la gamification des tests logiciels

Remerciements préalables

EDIT (paragraphe ajouté le 20 septembre 2018)

Ces illustrations ont été réalisées grâce au réjouissant projet open-source Historic Tale Construction Kit, version Bayeux. Merci à leurs concepteurs Leonard Allain-Launay, Mathieu Thoretton et Maria Cosmina Etegan !

Dans notre enthousiasme nous avions omis de les citer dans la première mouture de cet article, datée du 14 septembre 2018. Merci à l’un de nos lecteurs de nous avoir signalé cet impardonnable oubli !

Les tests montrent la présence de défauts

Et non leur absence. Comme le dit l’adage, l’absence de preuve n’est pas la preuve de l’absence…

Les tests exhaustifs sont impossibles

D’où la nécessité d’une stratégie de test basée sur les risques et d’un ciblage pertinent de l’effort de test.

Tester tôt

Il est plus simple, plus rapide et plus économique de corriger une ambiguité dans une user story ou un cahier des charges, que d’improviser un patch après la découverte d’un bug majeur en pré-production. C’est en ça que le test représente, contrairement à l’idée reçue, un gain de temps pour les équipes. Reste à trouver un moyen de quantifier ce temps gagné pour convaincre les derniers sceptiques !

Le regroupement des défauts

Après avoir éprouvé vos cas de test une première fois sur l’application, vous pourrez certainement identifier les fonctionnalités les plus “buggantes”. L’effort de test pourra alors être accru sur ces zones. Attention, les bugs peuvent changer de planque au fil du temps, ce qui nous amène au principe suivant…

Le paradoxe du pesticide

De même que les insectes développent des résistances contre les pesticides, les cas de tests répétés à l’identique au fil du temps perdent de leur efficacité. Garder un référentiel de tests trop statique tend à laisser les bugs proliférer dans les friches. Il est essentiel de revisiter périodiquement sa combinatoire : le Docteur Lenoir ne se fait pas toujours tuer par le Colonel Moutarde avec un chandelier dans la véranda ! 

Les tests dépendent du contexte

Le contexte métier, le moment de l’année, le nombre et les caractéristiques des utilisateurs constatés au cours des derniers mois… sont autant d’éléments précieux qui permettent d’identifier les types de tests à prévoir.

L’illusion de l’absence d’erreur

Ce principe est certainement celui qui en dit le plus long sur le rôle du testeur. L’exigence de qualité nécessite de comprendre en profondeur le besoin des utilisateurs finaux, c’est pourquoi le testeur doit endosser un rôle proactif d’interface entre équipe technique et équipe métier. Sans cela, on aboutira à un produit bien fait, qui ne sera pourtant pas le bon produit.

Bonne chance

… si vous passez prochainement votre examen ISTQB Foundation !

Vous pouvez librement utiliser ces images en citant Hightest et en indiquant un lien vers notre blog.

Vous reprendrez bien un peu d’humour testeur 🙂

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

3 maladies de l’automatisation des tests

Le kit de secours métaphorique du testeur agile

Et un supplément de memes inédits ? C’est par ici !

… et d’ISTQB !

Performance, charge, stress… quelle différence ?

Dear Evil Tester

Un bon testeur est un testeur diabolique ; c’est ce qu’Alan Richardson met en avant dans Dear Evil Tester, un recueil de questions-réponses issues d’une chronique au sein du journal The Testing Planet. Une lecture facétieuse, qui prend le contre-pied de tous les dogmes gravitant autour du test. Alan Richardson nous invite à bousculer nos certitudes et appelle à interroger constamment le métier de testeur.

Everyone can add mutation to the testing DNA.

Cerise sur le gâteau, il nous régale d’un poème, As if it were the first day. Comme il nous a plu, nous vous en proposons une traduction libre.

Comme au premier jour

Ce n’est pas le code que le testeur affronte,
C’est lui-même qu’il met au défi, en quête
Des manières dont on il aurait pu (la honte !)
Ignorer des trous dans la raquette.

Si on laisse le temps émousser notre regard
Les bugs nous échapperont par millions et par milliards.

Alors, méfiant, je reste sur mes gardes
J’ai peur qu’un autre me chaparde
Ce petit truc sans conséquence
« Comment ne l’ai-je pas vu, ça n’a pas de sens ! »

Il n’y a rien de tel que le passé : l’expérience du temps est une illusion
Il n’y a rien de tel que le présent, et j’ai la solution.

Je reste dans l’instant, mais pas dans le plan-plan
Je reste alerte, yeux grands ouverts et armé jusqu’aux dents
De mes talents, de mes modèles et mes outils (la fine équipe !)
L’appli ne peut pas gagner. C’est mon seul principe.

Je ne reteste pas. Je teste, je teste et je teste encore,
Comme au premier jour, aussi bien et aussi fort.

Bonne lecture, et n’hésitez pas à poster en commentaire ce que vous avez pensé de ce livre !

Vous pouvez même télécharger le poème au format image comme ci-dessous s’il vous prend l’envie de l’afficher dans votre bureau…

Une chanson sur le test logiciel ?

Ceci est une mise à jour du 27 mai 2019.

Dans le même registre, nous venons de découvrir sur le site Test Automation University une chanson sur la testeuse Angie Jones. Bonne écoute, et n’hésitez pas à nous faire part de toute autre œuvre lyrique sur notre beau métier !

Vous reprendrez bien un peu d’humour testeur 🙂

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

3 maladies de l’automatisation des tests

Le kit de secours métaphorique du testeur agile

Infographie sur l’accessibilité des sites calédoniens

A partager sans modération ! L’article qui suit reprend et explique chacune des données découvertes, expose la méthodologie et ses limites, et donne un rappel sur la nature et le rôle de l’accessibilité numérique. Vous pouvez également télécharger l’infographie (image au format PDF de 446 Ko).

Pourquoi mesurer l’accessibilité ?

L’accessibilité est un sujet encore insuffisamment maîtrisé, en métropole comme en Nouvelle-Calédonie. C’est un état de fait que l’on peut constater en navigant sur un certain nombre de sites web. Nous avons mené cette étude pour pouvoir préciser ce constat par des chiffres.

Quels critères d’accessibilité ont été analysés ?

Le choix d’un standard international

Des règles pour l’accessibilité des contenus web existent et forment un standard : le WCAG (Web Content Accessibility Guidelines). Pour chaque thématique, des règles sont proposées par niveau d’accessibilité souhaité (A, AA ou AAA).

Une partie de ces recommandations peut être vérifiée par un simple script de test automatique. Parmi celles-ci, nous avons retenu :

• Présence d’un attribut de texte alternatif sur toutes les images (règle 1.1.1, niveau A)
• Unicité du texte alternatif des images par rapport au contenu lisible et par rapport aux autres textes alternatifs de la page web (règle 1.1.1, niveau A)
• Lisibilité du texte alternatif (celui-ci ne doit pas être le nom de fichier de l’image) (règle 1.1.1, niveau A)
• Unicité des textes des liens pointant vers des ressources différentes sur une même page web (règle 2.4.4, niveau A)
• Présence d’un attribut indiquant la langue de la page (règle 3.1.1, niveau A)

Partant de ce constat, nous avons décidé d’étudier ces critères sur un large corpus de sites web calédoniens. Nous avons utilisé l’outil de scrapping JSoup, dont nous vous avons parlé dernièrement.

Parallèlement à l’analyse de ces critères, nous avons aussi étudié l’utilisation (quantitative) de la famille d’attributs “aria” et de l’attribut “tabindex“. Ces attributs ont vocation à améliorer l’accessibilité et l’ergonomie des sites web. Cependant, ces attributs sont parfois inclus par défaut dans les templates de sites et ne sont donc pas forcément sciemment implémentés par l’entité responsable d’un site. D’autre part, ces attributs peuvent faire l’objet d’une utilisation erronée ; leur présence au sein d’une page web ne veut pas forcément dire qu’elle est plus accessible qu’une autre.

Limites de l’analyse

• Les informations récoltées sont des indicateurs isolés qui ne sondent que grossièrement le niveau d’accessibilité des sites.
• Certains sites web calédoniens n’ont pas d’extension en “.nc” et n’ont pas été inclus dans l’analyse.
• Pour certains critères, certains sites n’ont pas pu être étudiés suite à des indisponibilités ou des incompatibilités techniques. Dans le pire des cas, 33 sites sur 800 n’ont pas pu être analysés.

Quels chiffres pour l’accessibilité calédonienne ?

Corpus

Le corpus est composé de la page d’accueil de 800 sites web calédoniens. Les sites les plus connus (sites institutionnels, administrations, médias…) y côtoient des sites commerciaux et associatifs. Les sites personnels de particuliers ne sont pas représentés.

La langue des pages est-elle déclarée ?

• 25 % des pages ne déclarent pas la langue du document. Une mesure pourtant peu coûteuse, puisqu’il s’agit d’un simple attribut à ajouter dans la balise html. La langue du document est une donnée utile pour les logiciels lecteurs d’écran, mais peut aussi être utile pour le référencement. En savoir plus sur l’attribut “lang”
• 7 % des pages où la langue est déclarée indiquent une langue qui n’est pas pertinente ; majoritairement l’anglais, mais aussi le portugais et le “nc”, qui n’est pas une langue ! Ces mauvaises pistes représentent 5 % du corpus total.

Les images sont-elles accessibles ?

Données générales sur les images

• 90 % des pages d’accueil contiennent au moins une image déclarée dans le DOM (et non chargée par CSS).
• 14 images : c’est le nombre médian par page d’accueil. Le nombre moyen est 24 et le nombre maximum, 1473.
• 47 % des attributs de texte alternatif sont vides (notés alt=” ou alt). Cela n’est pas un problème en soi ; cela signifie simplement que les synthèses vocales passeront sur les images sans donner d’information. Cette pratique est particulièrement pertinente pour les images à seul but décoratif.

Données sur l’accessibilité des images

• 20 % des images n’ont pas d’attribut de texte alternatif (même vide). Les synthèses vocales sont susceptibles de passer dessus en disant « image », ce qui n’apporte aucune valeur à l’utilisateur, et peut être irritant si le site contient beaucoup d’images. Si l’image contient des informations nécessaires à la compréhension du contenu, l’utilisateur en sera privé si sa machine ne charge pas les images, ou s’il est aveugle.
• 11 % des pages n’ont d’attribut de texte alternatif sur aucune de leurs images. 33 % en ont un pour chaque image.
• 34 % des textes alternatifs non vides contiennent du texte qui se trouve déjà dans le texte visible de la page. Cette utilisation n’est pas toujours erronée ; un logo dans le header avec comme texte alternatif “Accueil” est acceptable. Toutefois, une analyse plus poussée des données récoltées a montré que bien souvent, ces textes alternatifs étaient effectivement redondants.
• 18 % des textes alternatifs non vides possèdent au moins un doublon (image sur la même page ayant le même texte alternatif). Sur la page d’accueil d’un site de billetterie en ligne, il y a 40 doublons de ce type !
• 2 % des textes alternatifs sont des noms de fichier (par exemple : photo00032.jpg).

Accessibilité des liens

Données générales sur les liens

• Lors d’une navigation au clavier et au lecteur d’écran, le texte des liens prend toute son importance, car chaque lien est susceptible d’être lu hors de son contexte. Il est donc important de choisir de textes parlants, comme “notre point de vue sur le World Quality Report de 2017-2018“, plutôt que des textes génériques comme “dans cet article” ou “cliquez ici”.
• 14 liens : c’est le nombre médian par page d’accueil. Le nombre moyen est 26 et le nombre maximum, 1215.

Données sur l’accessibilité des lien

• 5 % des liens partagent leur texte avec un autre lien de la même page dont la destination est différente. Problème : comment faire la différence entre 2 liens qui se suivent et indiquent « En savoir plus » ? Sur une des pages étudiées (la page d’accueil du site d’une agence immobilière), 55 liens sont dans ce cas de figure.
• Pour 30 % des liens, c’est l’inverse (ils pointent vers la même ressource mais ont un texte différent), ce qui est beaucoup moins problématique. Par exemple, on imagine bien qu’un lien “La dernière version” puisse pointer vers la même ressource qu’un lien “La version de juin 2018”.

Présence d’attributs aria et tabindex

• 16 % des pages comptent au moins un attribut aria-*
• 10 % des pages comptent au moins un attribut tabindex

Rappel : quels sont les enjeux de l’accessibilité ?

Améliorer l’expérience de l’ensemble des utilisateurs

Accessibilité et handicaps sont souvent associés. Mais contrairement à l’idée répandue, l’accessibilité n’est pas une affaire de personnes handicapées, mais plutôt de situations de handicap, car tout un chacun peut être amené, temporairement ou situationnellement, à être privé de tout ou partie de l’acuité d’un de ses sens. Quelques exemples :

• La difficulté à lire l’écran de son smartphone quand on le consulte en plein soleil
• La photophobie provoquée par une forte migraine
• La difficulté à écouter une émission quand on se trouve dans un bus bondé en centre-ville

Le matériel que l’on utilise peut lui-même nous mettre en situation de handicap :

• Ecouteurs en panne
• Ecran anormalement terne
• Connexion internet bas-débit

Le kit de design inclusif de Microsoft illustre par exemple cette diversité de contextes en montrant qu’on peut avoir “un bras en moins” lorsqu’on est amputé, plâtré, ou simplement occupé à tenir un bébé.

Les bonnes pratiques d’accessibilité sont donc profitables à tous et permettent de construire du contenu tout-terrain. Ce faisant, on améliore les conditions de la satisfaction utilisateur et le rendement de ses services en ligne.

Résorber les fractures numériques

Ceci étant dit, il est correct de dire qu’une part grandissante de la population se trouve dépendante de l’accessibilité des services web.

Selon l’enquête HID, il existait en France 1,7 millions de déficients visuels en 1999, dont plus de 200 000 aveugles ou malvoyants profonds. A l’époque, cela représentait 2,9% de la population. Un nombre similaire (2,8%) a été obtenu en 2012 au Canada. Ajoutez à cela le fait que le nombre de déficients visuels est en forte augmentation dans le monde entier dû au vieillissement de la population.

Nombreux sont les éléments à prendre en compte pour aller vers plus d’accessibilité : malvoyance, malentendance, cécité, surdité, daltonisme, épilepsie, dyslexie…

Plus le temps passe et plus la société se digitalise ; il n’est donc pas question de laisser de côté une si grande partie de la population.

L’accessibilité : une obligation juridique

Soulignons que depuis 2005, l’accessibilité des sites web est en France un enjeu juridique. Depuis la loi pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées, il est obligatoire aux sites institutionnels de fournir des services en ligne accessibles. En octobre 2016, la Loi pour une République numérique a rappelé cette obligation.

Mais les associations considèrent souvent que cette législation est insuffisante et trop peu appliquée. A l’heure actuelle, l’accessibilité est encore majoritairement le fruit de décisions volontaires, plutôt que celui d’une obligation légale. Une raison de plus de prendre conscience de sa responsabilité individuelle dans ce domaine.

Sur notre blog, vous pourrez découvrir d’autres articles sur ce thème. L’an dernier, nous avons participé à un défi du Ministry of Testing sur l’accessibilité, et il y a deux mois nous avons rencontré Marie-Françoise Pierre, une entrepreneuse malvoyante.

Durant cette analyse, nous avons découvert un certain nombre de freins à l’accessibilité sur notre site, et nous sommes en train de les résoudre. Et vous, que pourriez-vous améliorer ? Histoire de ne pas être dans nos prochaines statistiques… 

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

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

30 days of accessibility testing

 

Qu’est-ce qu’un testeur ?

Il y a plusieurs sortes de testeurs : il y a les flacons de parfum qui ne seront pas vendus, les consommateurs rémunérés pour évaluer des produits alimentaires, et aussi les équipements électroniques qui mesurent le Ph d’une piscine. Des questions ?

Nous sommes testeurs et, lorsqu’on nous demande notre métier, il nous faut souvent broder un peu pour que notre interlocuteur non-informaticien comprenne de quoi il s’agit. Et l’article Wikipedia sur les testeurs ne nous aide pas beaucoup…

“Un testeur, en informatique, est une personne chargée de tester le logiciel produit par les programmeurs, et de livrer à intervalles réguliers un rapport décrivant les erreurs trouvées dans le produit.”

Si tous les testeurs qui ne correspondent pas vraiment à cette définition se tenaient par la main, la chaîne humaine serait au moins aussi longue que la distance qui nous sépare de la métropole (à hauteur de 100 000 personnes mesurant en moyenne 1 mètre 70 d’envergure, on est peut-être même en-deçà de la vérité).

Mais continuons de nous promener sur l’encyclopédie en ligne.

Qu’est-ce que l’automatisation des tests ?

L’automatisation des tests et l’une de nos activités à forte valeur ajoutée ; qu’en dit Wikipedia ?

L’article sur l’automatisation des tests, à l’état d’ébauche, compte dix lignes et pas une de plus. Dont cette phrase malheureuse :

“Plusieurs éditeurs proposent à ce jour des robots de tests, par exemple Smartbear (outil : TestComplete), Selenium ou la société Applause.”

Aïe, depuis quand Selenium est une société ? Depuis quand Smartbear n’a qu’un seul outil ? Et… pourquoi Applause ? Dans l’historique, on voit que le contributeur a simplement rajouté cette mention par esprit d’équité :

“Il est peu objectif de ne proposer que 2 logiciels. J’ai rajouté un prestataire différent, proposant une méthodologie autre que le software. Il est leader mondial, il me semble donc normal que son nom soit cité.”

“Une méthodologie autre que le software” : si un jour vous écrivez un livre, essayez de ne pas l’appeler comme ça… Mais ne jetons pas la pierre à ce contributeur ; sur Wikipedia, les uns corrigent les erreurs des autres, et son approximation aurait dû être épongée depuis des mois (par vous et par nous).

Allez, on se donne une troisième chance ?

Qu’est-ce que… non, rien.

Si on parlait de test agile ? Mince, l’article n’existe pas. De test d’accessibilité ? Non plus. Gestion des anomalies, gestion des tests, rien, nothing, nada.

Et en anglais ? Là c’est moins pire. Les thématiques principales du test logiciel sont abordées, il y a un peu plus de pages, avec un peu plus de contenu. Mais tout ça laisse sur sa faim. Car sur d’autres pans de Wikipedia, lorsqu’un article en langue X est de bonne qualité, un article en langue Y s’en inspire et indique clairement qu’il s’agit d’une reprise ou d’une traduction.

De plus, il serait inexact de dire que ce triste sort est réservé à tous les “nouveaux métiers” (d’ailleurs, le test logiciel n’est pas un domaine métier si récent). Des pages plus fournies existent sur les responsables du bonheur (chief happiness officers), les animateurs de communautés (community managers), sur l’optimisation des moteurs de recherche (ou SEO) ou encore sur le devOps.

Qu’en conclure ? Google régurgitera-t-il impassiblement, année après année, cette soupe froide et indigeste dès que le moindre curieux s’enquerra de notre passionnant métier ? Les pépites sont-elles vouées à rester cachées dans les livres ? Une encyclopédie vivante du test logiciel est-elle impossible ?

A grand pouvoir, grande responsabilité

Vous vous en doutez, on ne peut pas conclure là-dessus. Car à quoi bon continuer de se lamenter sur cette piteuse vitrine, quand nous sommes à même d’être le changement que nous voulons voir… Allez, on s’y met ?

Si le coeur vous en dit, indiquez votre pseudo Wikipedia en commentaire, nous serons heureux d’aller lire votre travail !