Auteur/autrice : hightest

Best of 2025 – 1/4

Posted on | by hightest | Leave a Comment on Best of 2025 – 1/4

En 2025, nous poursuivons la résolution un peu folle de 2024 : vous proposer tous les jours sur LinkedIn un contenu sur le test logiciel et la qualité ! Des posts de fond, des partages d’autres personnes, mais aussi des blagues et des memes.

Voici notre best of, pour ne pas que ces petits billets tombent totalement dans l’oubli 🙂

Sélection de posts

Ailleurs sur le web

Memes

Recrutement

C’est avec un peu de facétie que nous avons créé ces communications pour informer de nos postes à pourvoir…

+ ce post sur notre process de recrutement : https://www.linkedin.com/feed/update/urn:li:activity:7292784031090233344

L’année ne fait que commencer, suivez-nous pour toujours + de contenus sur le test !

Bugs d’accessibilité : c’est du vécu !

Posted on | by hightest | Un commentaire sur Bugs d’accessibilité : c’est du vécu !

En janvier, nous avons eu le plaisir de recueillir le témoignage de Cyriaque Delaveau, un développeur qui travaille sans clavier ni souris mais avec une commande oculaire. Aujourd’hui, nous partageons la suite de son témoignage, qui concerne un sujet qui nous tient à cœur : l’accessibilité !

En effet, du fait de ses usages numériques spécifiques, Cyriaque est un aimant un bugs. Une chance quand on fait du test d’accessibilité, mais une vraie galère quand on veut simplement utiliser des services numériques ! Ces bugs sont d’autant plus pernicieux qu’ils peuvent rester des années dans des applicatifs sans que leur équipe projet, si elle n’est pas formée, ne se doute de rien… Il est temps de lever le voile 😉

Parole à Cyriaque Delaveau.

________________________________________________

L’accessibilité est un sujet qui me touche de très près, à la fois comme développeur et comme utilisateur. En tant qu’internaute utilisant une commande oculaire, je rencontre régulièrement des problèmes d’accessibilité qui rendent certaines tâches en ligne inutilement difficiles, voire impossibles.

Menus déroulants

Beaucoup de sites utilisent des menus déroulants ou des éléments interactifs qui ne sont pas navigables sans souris. Ces menus ne répondent pas aux commandes clavier ou aux technologies d’assistances comme les commandes oculaires, au final je me retrouve bloqué pour accéder à certaines sections du site.

Captcha

Certains captchas (surtout les “drag to verify”) sont un cauchemar. Bien qu’il existe des versions accessibles, beaucoup de sites n’en proposent pas. Ça peut complètement bloquer l’accès à un service. J’ai à faire à ces types de captchas très souvent, surtout sur certains sites de streaming gratuit pour animes japonais et mangas (oui j’adore les animes/mangas et non ce n’est pas uniquement réservé aux enfants).

Petits éléments

Des éléments interactifs minuscules (liens, boutons) sont un véritable défi avec une commande oculaire. Le ciblage devient très imprécis, et une mauvaise conception de ces éléments rend leur utilisation frustrante et inefficace. Avec la nouvelle génération de commande oculaire (PCEye 5), je n’ai plus trop ce problème puisqu’il y a une aide à la visée pour le zoom (assistée par IA), mais tout le monde n’a pas la possibilité d’avoir ce nouveau modèle de commande oculaire, et doivent utiliser les anciens modèles.

Cyriaque a demandé à trois de ses amis en situation de handicap (Élodie, 20 ans, M, 26 ans et T, 30 ans) de s’exprimer au sujet de l’accessibilité.

Témoignage d’amis de Cyriaque

  • Les vidéos sans sous-titres excluent les personnes sourdes ou malentendantes, mais elles compliquent aussi les choses pour tous ceux qui ne peuvent pas interagir avec la vidéo pour trouver des options alternatives.
  • Certaines applications ou sites web n’intègrent aucun raccourci clavier ou navigation structurée. Quand il faut passer par des dizaines de clics pour atteindre une section, c’est épuisant, surtout pour ceux qui dépendent de commandes alternatives comme pour la navigation au clavier.
  • Une interface avec des contrastes faibles, des polices trop petites ou des couleurs mal choisies (par exemple, du gris clair sur fond blanc) rend la lecture extrêmement pénible, surtout pour ceux qui ont une déficience visuelle.

NB : Élodie est née avec une malformation congénitale affectant son cerveau, entraînant un manque d’apport en oxygène. Elle peut utiliser ses jambes pour se déplacer, mais n’a pas l’usage de ses bras et dépend d’une sonde gastrique pour son alimentation. M et T sont tétraplégiques et peuvent boire, manger, parler et bouger les yeux. T a été victime d’un accident de moto, tandis que M a fait une chute dans une rivière.

Cyriaque a également répondu à notre question :

Comment savoir si un élément est accessible via commande oculaire ?

Il n’existe pas de moyen de tester en amont si un élément est accessible à une commande oculaire.

Personnellement, dans certains cas, j’envoie un mail au technicien de ma commande oculaire, qui envoie un mail au siège de l’entreprise en France pour avoir leur avis. Par exemple, je leur avais demandé si avec la commande oculaire je pouvais utiliser un double écran comme les postes de travail que vous avez au bureau. Eux-mêmes ne pouvait pas répondre à ma question, car la commande oculaire n’a pas été créée pour cette utilisation, ils étaient même surpris que je fasse de la programmation avec puisqu’à la base la commande oculaire doit seulement permettre d’utiliser un ordinateur ou écrire alors que je l’utilise pour coder, dessiner, jouer et faire de la modélisation 3D sur Blender.

Si je veux savoir si un élément est accessible à la commande oculaire ou non, j’essaie de l’utiliser et si c’est facile je considère que c’est accessible à la commande oculaire. Si c’est trop compliqué à utiliser, je considère l’élément comme étant inaccessible à la commande oculaire.

En soi, on ne peut pas vraiment appeler ça des bugs d’accessibilité, c’est juste qu’elle n’a pas été pensé dans cette optique et pour ce genre d’utilisation. Les doubles écrans ne fonctionnent pas avec, pareil pour les jeux vidéos beaucoup trop avancés (GTA, Red dead redemption, Fifa, etc.), les tablettes ne fonctionnent pas avec, les mac ne sont pas compatibles. Il existe encore beaucoup de choses avec lesquelles la commande oculaire ne fonctionne pas ou n’est pas compatible.

Le mot de la fin

C’est un peu cliché de dire ça mais je rêve d’un web où tout le monde peut naviguer librement, quelle que soit sa situation. C’est faisable, mais comme beaucoup de choses dans notre société, ça demande une prise de conscience collective et des efforts concrets de la part des développeurs et designers. C’est également ce qui me motive à faire carrière dans le développement web.

Merci à Cyriaque d’avoir pris la parole et merci à vous d’avoir lu. Maintenant, à vous de jouer !

LinkedIn 2024 : un an de posts

Posted on | by hightest | Leave a Comment on LinkedIn 2024 : un an de posts

En 2024, pour partager sa passion du test en Nouvelle-Calédonie comme ailleurs, Hightest a publié un post LinkedIn par jour ouvrable !

Cette page fournit un best of de ces posts, afin de vous permettre (et aussi de nous permettre, car parfois nous en avons besoin nous-mêmes !) de retrouver un sujet ou une discussion passée. Nous avons choisi un classement par thématiques plutôt que par date.

Nous avons beaucoup repartagé des pépites produites par notre réseau et remercions au passage la communauté francophone du test logiciel pour sa créativité et son dynamisme.

Cela vous donnera peut-être envie à vous aussi de partager votre quotidien de QA… On l’espère en tous cas !

Bonne (re)découverte !

Mieux tester

Mieux automatiser

Test management

Savoir être

Inclusion et accessibilité

Autres aspects non fonctionnels de la qualité

Jeux de données de l’espace

Memes !

Culture informatique

Explication de concepts

ISTQB, CFTL, JFTL…

Recrutement de QA

C’était un plaisir d’échanger sur LinkedIn avec une multitude de personnes passionnées par la qualité logicielle. Et si on réitérait le défi en 2025 ? 😉

KickTest, votre alliée pour réviser vos certifications ISTQB !

Posted on | by hightest | Leave a Comment on KickTest, votre alliée pour réviser vos certifications ISTQB !

La certification ISTQB est un passage obligé pour une très grande partie des QA. Et tout le monde s’est déjà posé la question, à l’approche de l’examen, “Ai-je suffisamment révisé ?”, “Où trouver d’autres tests blancs” ? Chez Hightest, nous avons nous aussi rencontré cette problématique, ce qui nous a donné envie de concevoir et partager des tests blancs à chaque fois que nous avons préparé un examen.

Ce n’est toutefois pas le sujet de cet article… en effet, ici on va parler d’une toute nouvelle plateforme avec une forte ambition : fournir tellement de questions d’examen qu’il serait presque impossible d’épuiser le stock avant le jour J ! Le code Rousseau de l’ISTQB a un nom qui claque : KickTest. La plateforme est en ligne depuis hier, avec un code promo pour la découvrir gratuitement jusqu’au 31 janvier : FREEKICKTESTJANUARY !

Concept de la plateforme

C’est en 2020 qu’Aurélien Haye et trois de ses amis ont l’idée de créer une plateforme pour aider les QA à réviser ISTQB. Le principe est simple et au plus près des besoins : fournir des questions qui ressemblent au maximum au format de celles de l’examen, classées par chapitre, avec possibilité de réviser de manière ciblée. En effet, à l’issue d’un examen, on ne sait pas précisément à quelles questions on a répondu faux, mais on obtient une note par chapitre.

Le projet a maturé pendant 4 ans. Aujourd’hui, il est en ligne et permet de réviser avec 3 formules au choix : une formule d’un mois pour réviser en autodidacte, une formule de 4 jours pour accompagner les formations qui en général ont cette durée, et une formule de 24h pour faire un maximum de révisions, l’avant-veille idéalement !

L’équipe

L’équipe compte 4 personnes : Aurélien Haye, Enrico Guazzini, Florian Hyvernault et Jonathan Jato. À savoir : un développeur, un designer / graphiste et 2 qualiticiens qui ont rédigé les quiz. “Chacun est resté dans sa spécialité et on a trouvé au fil du temps notre rythme et notre manière de collaborer”, témoigne Aurélien Haye.

Un travail titanesque

6000 questions d’examen : vous ne risquez pas d’en venir à bout avant un bon moment. Pour rédiger tout ça, l’équipe n’a pas ménagé ses efforts. Vous vous demandez si une IA a fait partie de la team ? Aurélien répond : 

Nous avons créé l’intégralité de nos quiz à la main. D’ailleurs, un quiz c’est un peu plus qu’une simple question puisqu’il faut des propositions de réponses, une explication pour que les concepts derrière le quiz soient compris, éventuellement des pièce-jointes, etc. Nous avons testé la production de quiz assistés par l’IA mais les résultats n’ont pas été probants, la grande majorité des quizs générés par les LLM s’est avérée erroné voir complètement fausse. Je pense que les données dont disposent les principales IA sont insuffisantes et que ça explique ces mauvais résultats.

Par contre nous avons collaboré avec d’autres qualiticiens pour augmenter notre rythme de production de quiz et l’équipe est montée jusqu’à 4 rédacteurs (en comptant les 2 de l’équipe historique, NDLR). Ça a plutôt bien fonctionné de ce côté.

Les coulisses du projet

Nous avons demandé à Aurélien s’il y avait eu des idées abandonnées au fil du temps, ou au contraire de nouvelles idées qui ont émergé au fil du développement de la plateforme. Au cours de ce travail de longue haleine, la réponse est évidemment positive.

Au début, on sous-estimait beaucoup la charge de travail nécessaire pour produire une plateforme comme KickTest. Nous avions une idée moins précise de ce qu’on voulait faire et on partait un peu dans tous les sens. Par exemple, on voulait aussi intégrer un comparateur d’outils spécialisés dans les tests au sein de la plateforme. Ce n’était pas une mauvaise idée mais ça n’avait rien à voir avec l’entraînement sur les certifications qualité. Nous avons aussi beaucoup fait évoluer notre stack technique et le rendu graphique tout au long du développement. Comme pas mal de projets, on a itéré pour progresser et on va continuer de le faire. Pour finir avec une idée que nous avons eue en cours de route, c’est la conception de l’administration qui sera invisible pour l’utilisateur mais qui va grandement faciliter notre travail en back office pour gérer la création et la mise à jour de nos quiz, examens blancs et plein d’autres items propres à KickTest.

Un conseil souvent donné aux entreprises ces dernières années est de se focaliser sur un seul besoin pour l’honorer complètement, et la plateforme KickTest est bel et bien allée dans ce sens.

L’avenir de KickTest

À ce jour, KickTest permet de réviser 2 examens : ISTQB Fondation et ISTQB Analyste de test. Toutefois, KickTest ne va pas s’arrêter là, et de nombreuses améliorations et contenus complémentaires sont en route. Aurélien Haye en parle :

On a beaucoup de projets dans les cartons.

Pour le court terme : on veut améliorer l’aspect visuel des résultats d’examens blancs et compléter les informations contenues dans cette page pour apporter plus de valeur à l’utilisateur. On travaille également sur l’intégration d’un glossaire intelligent qui trouvera pas mal de synergies avec nos quiz pour offrir à nos utilisateurs une meilleure expérience et un meilleur apprentissage. Au niveau de nos contenus, on souhaite compléter notre catalogue avec les certifications Testeur agile technique, Scrum.org (PSM & PSPO) et TMMI.

Pour le moyen terme : on planche fort sur la partie administration dont je parle plus haut, c’est un sacré investissement en temps et en énergie mais qui paiera sur le long terme. On continuera à produire des quiz pour d’autres certifications en parallèle.

La question qui tue

Évidemment, on ne pouvait pas s’empêcher de poser la question… Comment cette plateforme de test est-elle testée ? La réponse d’Aurélien aborde à la fois les vérifications de la qualité technique de la plateforme et la validation de la pertinence des questions :

Au niveau du développement, nous avons une couverture de tests unitaires qui nous assure un minimum de sécurité même si on peut faire beaucoup mieux à ce niveau dans les mois à venir. En interne, nous avons fait pas mal de sessions de test et de tests non-scriptés qui nous ont permis de détecter pas mal d’anomalies. Puis nous avons collaboré avec certains experts du test pour leur faire essayer KickTest. Enfin, on a fait des bêta tests en conditions réelles avec des étudiants qui passaient leur certification, les résultats ont été globalement assez positifs et le retour d’information riche.

Pour conclure

La plateforme KickTest est toute jeune et va continuer d’évoluer, toutefois nous vous conseillons d’aller y faire un tour dès maintenant, pour vous-mêmes ou pour les personnes que vous souhaitez former ! Merci à Aurélien pour les réponses apportées, vous pouvez le contacter sur LinkedIn si vous souhaitez en savoir davantage sur la plateforme ou vous rapprocher de l’équipe en vue d’un partenariat.

Vis ma vie numérique – Cyriaque Delaveau, développeur sans clavier ni souris

Posted on | by hightest | Leave a Comment on Vis ma vie numérique – Cyriaque Delaveau, développeur sans clavier ni souris

En décembre 2024, nous avons profité de la fin de l’année pour en apprendre un peu plus sur Cyriaque Delaveau, un étudiant développeur rencontré lors d’une de nos prestations. Cyriaque a comme objectif de devenir Développeur Web Full-Stack et il apprécie particulièrement de travailler sur le Front-End et le Back-End mais aime également tout ce qui touche de loin ou de près à l’analyse de données. Il vient de terminer sa licence professionnelle MIAW (Métiers de l’Informatique Applications Web) et approfondit ses connaissances dans le cadre de son alternance. Un dev comme les autres ? Oui, car il s’intègre parfaitement dans son équipe, tant d’un point de vue technique que méthodologique et relationnel. Et non, car Cyriaque n’utilise ni clavier, ni souris. Vous pensez que c’est impossible ? Continuez de lire !

Interview

Hightest : Bonjour Cyriaque ! Peux-tu te présenter ?

Cyriaque Delaveau : Je m’appelle Cyriaque Delaveau, j’ai 23 ans et je suis atteint d’une myopathie de Duchenne. Je suis actuellement à la fin de ma licence professionnelle MIAW. J’ai eu une scolarité tout à fait normale jusqu’en Seconde, puis en raison d’un souci de santé, j’ai terminé mes années de Lycée en service hospitalier. J’ai validé mon DUT MMI (Diplôme Universitaire de Technologie Métiers du Multimédia et de l’Internet) avant de quitter l’hôpital en Décembre 2022 pour entrer dans un foyer de vie pour adultes en situation de handicap.

Ma recherche d’entreprise pour mon alternance a été très compliquée, après une vingtaine de refus successifs, une seule entreprise à bien voulu me donner une chance. À vrai dire, j’ai songé à plusieurs reprises abandonner mais je m’étais fait une promesse à moi-même quand j’étais au collège, à savoir : intégrer une licence informatique par tous les moyens, et prouver qu’elles avaient tort à ma conseillère d’orientation et toutes les personnes qui m’ont imposé des filières administratives pour seul motif mon handicap, sans même prendre le temps d’écouter mes vœux d’orientation.

En 2019, j’ai perdu un peu de mobilité dans les mains et les doigts à cause de l’évolution de mon handicap, rendant impossible l’utilisation de mon ordinateur portable. J’ai rencontré Christelle, une employée de Mieux-Être (magasin de matériel médical), qui m’a présenté et fait essayer une commande oculaire me permettant d’utiliser mon PC avec le mouvement des yeux. Ça va faire maintenant 5 ans que j’utilise cette technologie au quotidien, l’apprentissage à était plutôt rapide et facile pour apprendre les fonctionnalités de base. Au bout de deux semaines, j’avais fait le tour de toutes les fonctionnalités et possibilités d’utilisation, mais même aujourd’hui, il m’arrive encore d’être surpris par les possibilités de cette technologie, notamment pour le dessin.

Hightest : Quelles technologies utilises-tu afin de développer sans clavier ni souris ?

Cyriaque Delaveau : Pour développer sans clavier ni souris, j’utilise une commande oculaire, le Tobii PCEye 5, qui détecte les mouvements de mes yeux. Pendant l’installation, on crée un profil adapté à mes besoins : si je porte des lunettes ou des lentilles, la vitesse à laquelle je veux scroller, le temps que je dois fixer un point pour cliquer. Le PC Eye 5 remplace la souris et le clavier grâce au logiciel TD Control. En gros, je peux piloter tout mon ordinateur avec mes yeux, même si je porte des lunettes. Il est compact, super facile à installer avec un support aimanté, et il fonctionne sur les ordis et tablettes sous Windows 10 ou 11. Chaque utilisateur peut avoir ses réglages persos, comme la vitesse ou le mode d’activation. Il est même compatible avec Windows Hello, donc je peux déverrouiller mon ordi juste avec mes yeux. Si besoin, je peux ajouter des logiciels comme Track and Learn pour enregistrer les mouvements des yeux. Grâce à cet outil, je peux coder, naviguer et utiliser mon ordi facilement, même sans clavier ni souris.

Avant, j’utilisais une souris sans fil et un clavier virtuel sur un ordinateur portable classique. Quand j’ai dû passer à la commande
oculaire, ça n’a pas été simple. J’étais pas du tout emballé, parce qu’accepter cette technologie, c’était un peu comme accepter que mon
handicap avait évolué. Au début, j’étais réticent, mais après quelques essais, j’ai vite réalisé que cette solution me permettait de garder mon autonomie et de continuer à travailler comme avant. L’apprentissage a été rapide : en deux semaines, je maîtrisais les bases, et avec le temps, j’ai découvert des fonctionnalités que je ne pensais même pas possibles.

Hightest : Concrètement, comment clique-t-on avec les yeux ?

Cyriaque Delaveau : Cliquer avec les yeux, c’est très simple. Tu fixes une zone de l’écran, et après un petit temps d’attente, qui peut être modifié en fonction de tes préférences, le clic se fait automatiquement. Un cercle ou une animation te montre que le clic est en préparation. Tu peux régler la durée de fixation et choisir entre clic gauche, clic droit ou double clic et d’autres fonctionnalités encore via un menu d’interaction. Pour taper du texte, un clavier virtuel s’affiche, et tu sélectionnes les touches avec ton regard. En gros, ton regard remplace le déplacement de la souris et la durée de fixation de ton regard remplace le clic. Pour te donner un ordre d’idée, ma sensibilité pour la durée de fixation avant interaction et la vitesse d’activation des boutons est réglée sur 450 millisecondes, en sachant que le maximum est de 350 millisecondes pour durée et 200 millisecondes pour la vitesse.

Pour permettre de mieux comprendre le fonctionnement de la commande oculaire, Cyriaque a réalisé cette vidéo de démo de PCEYE5 :

Hightest : Qu’est-ce qui t’a amené à choisir le métier de développeur ?

Cyriaque Delaveau : J’ai choisi le métier de développeur parce que je suis passionné par la technologie et fasciné par son potentiel. Mon DUT MMI m’a donné un premier aperçu du développement et a renforcé mon envie de créer des solutions concrètes et utiles. Je me suis également lancé ce défi personnel pour prouver que mon handicap n’est pas une limite et pour tenir la promesse que je me suis faite au collège. Enfin, je vois dans ce métier une opportunité de contribuer à des projets innovants tout en relevant des défis techniques passionnants.

Hightest : Précédemment, tu as contribué au développement d’une application axée sur l’accessibilité. Peux-tu nous en dire plus ?

Cyriaque Delaveau : J’ai participé à la réalisation du module d’accessibilité web Tenjity, pendant mon stage de dernière année de DUT MMI. Mon maître de stage, un Senior Web Developer très engagé sur l’importance de l’accessibilité dans le Web, m’a guidé tout au long du projet. À cette époque, je n’avais pas encore beaucoup de compétences en programmation, donc ma contribution s’est concentrée sur la rédaction des documents techniques des fonctionnalités du module. Tenjity est un module d’accessibilité web gratuit et convivial, conçu pour être facile à installer et compatible avec tous les principaux navigateurs. Il propose des profils prédéfinis pour différents types de handicaps, tout en permettant une personnalisation selon les besoins spécifiques de chaque utilisateur. L’objectif de Tenjity est de rendre le web plus inclusif en offrant des outils qui facilitent l’accès aux contenus en ligne pour tous. Par exemple, si l’utilisateur est dyslexique il peut activer le profil “Dyslexique”, ce qui remplace toutes les polices d’écritures du site par une police plus adaptée (OpenDyslexic). Pour l’anecdote, le nom Tenjity a été inspiré par les Tenji Blocks, des dispositifs japonais destinés à aider les personnes malvoyantes à se déplacer grâce à des blocs tactiles installés au sol. Ce lien avec l’accessibilité et l’innovation a donné toute son identité au projet.

Hightest : Es-tu actuellement en recherche d’emploi ? Si oui, quel serait le type de poste qui te plairait le plus ?

Cyriaque Delaveau : Effectivement je suis en recherche d’emploi, faire de longues études ne fait pas partie de mes perspectives même si j’aurais bien aimé. L’idéal pour moi, serait un poste de développeur web junior, en full télétravail et en temps partiel. Au vue des soins médicaux quotidiens que j’ai, être en temps plein me paraît assez compliqué voire impossible. De plus, j’ai une maladie dégénérative, d’ici trois à cinq ans, je ne serai plus en mesure de faire quoi que ce soit, d’où le temps partiel.

Hightest : L’accessibilité est un sujet qui te concerne non seulement en tant que dev, mais aussi en tant qu’internaute. Quels sont les bugs d’accessibilité les plus fréquents que tu rencontres et qui sont des obstacles pour toi ?

… La réponse de Cyriaque est à découvrir dans notre prochain article. Il a d’ailleurs mobilisé quelques amis qui ont eux aussi témoigné des bugs rencontrés au quotidien !

Merci à Cyriaque pour cet échange qui illustre une fois de plus la diversité des profils d’internautes et l’importance d’intégrer ces profils en entreprise. Nous invitons les organisations numériques calédoniennes offrant des postes de dev web full-stack junior à prendre contact avec lui !

Comment les QA voient le monde, épisode 4 : esprit critique es-tu là ?

Posted on | by hightest | Leave a Comment on Comment les QA voient le monde, épisode 4 : esprit critique es-tu là ?

Et voilà, c’est aujourd’hui le dernier épisode de notre série avec Rose Lutz d’Alt QA (😿) ! On a voulu finir avec un soft skill souvent mal compris : l’esprit critique.

Avoir un “esprit critique”, c’est très différent de “critiquer” !

Avant toute chose, il est important de faire une mise au point : “critiquer” est une chose, “avoir l’esprit critique” en est une autre. Les deux concepts ont des connotations diamétralement opposées. Et nous, les QA, on connaît bien cette différence !

Critiquer, c’est plutôt être négatif, dire et penser que rien ne va, que c’est nul que de toute façon il n’y a rien à faire de mieux… Bref, critiquer est rarement constructif.

Avoir l’esprit critique, au contraire, c’est une démarche constructive : c’est essayer de poser un regard plus impartial sur les choses et ne pas tout prendre pour argent comptant. C’est confronter les informations extérieures à la représentation que l’on se fait d’un système, et les questionner avant de les intégrer. En bref, c’est penser par soi-même, en questionnant ses propres biais.

Les QA ne prennent donc aucun plaisir à critiquer, en revanche on s’efforce d’avoir un regard critique sur les choses.

Et pour ce faire, une de nos armes redoutables n’est pas la “critique”, mais… la question !

Des questions, des questions, encore des questions

Les QA posent beaucoup de questions… mais sans attendre de réponse spécifique. Ce ne sont pas des questions rhétoriques, comme celles de quelqu’un qui aurait déjà en tête la réponse parfaite. Ce sont des questions candides, posées avant tout pour savoir si une réponse existe ou si, malheureusement, personne n’y avait jamais réfléchi.

Nous avons déjà parlé de l’importance des questions dans le monde des QA (on ne nous appelle pas des “Question Askers” pour rien !).

Lorsque nous posons des questions, c’est généralement pour combler des manques, mettre en lumière des oublis. Comme la nature a horreur du vide, à chaque fois qu’il y en a, les QA y déposent une question !

Mais quand nous faisons jouer notre esprit critique, nous ne posons plus juste des questions : nous remettons en question. Par rapport à des référentiels plus vastes que les simples spécifications, par rapport à nos connaissances, notre culture personnelle. C’est pour ça que c’est important de se tenir à jour des pratiques de notre métier et de notre environnement.

Virtuellement, il n’y a rien, dans un contexte donné, qui ne soulève la question “Pourquoi ?” Et nous aurons du mal à nous contenter d’un “On a toujours fait comme ça”.

Esprit critique et bases de test

Les bases de test sont les documents faisant autorité, qui décrivent le fonctionnement attendu des applications. Autrement dit, un terrain de jeu parfait pour réfléchir à tout ce qui pourrait être clarifié et amélioré ! L’esprit critique nous amène à prendre du recul, à remettre en perspective ce qui est spécifié, et ce même quand la spec est bien écrite (qui signifie par exemple, pour une User Story, qu’elle respecte les critères INVEST). En effet, ce qui est demandé est-il vraiment conforme au besoin ? Existe-t-il des manières plus simples, plus efficaces, d’accomplir la même chose ?

L’esprit critique nous aide à : 

  • Détecter des décalages entre ce qui est spécifié et les usages standards en termes d’UI et d’UX, cf la loi de Jakob qui invite à concevoir des interfaces rappelant au maximum les autres interfaces connues par le public visé. Cela se traduit par la question : “Pourquoi avoir conçu cette interface ainsi plutôt qu’autrement ?”
  • Trouver les redondances, trouver ce qui pourrait être simplifié. Cela se traduit par la question “Si on faisait plutôt comme ça en enlevant X étapes, est-ce que ça répondrait toujours aussi bien au besoin ?”
  • Identifier les fonctionnalités qui ne correspondent à aucun besoin réel. Cela se traduit par la question “Qui pourrait avoir besoin de ça, et dans quel contexte ?”
  • Identifier des incohérences dans les specs, qui sont autant de sources d’incompréhension et de confusion. Cela se traduit par la question “Qu’as-tu voulu dire exactement ?”

Vous l’aurez compris, cette démarche revient parfois à aller à contre-courant ! Avoir un bon esprit critique doit alors s’accompagner d’une certaine audace, et de bonnes compétences en argumentation.

Esprit critique et pratiques de test

Les QA ne prennent donc rien pour argent comptant. Même pas les résultats de leurs propres activités ! Quand une série de tests ne déclenche aucune défaillance, nous avons tendance à remettre en question les tests plutôt qu’à nous réjouir de la bonne qualité présumée du produit. Cela donne lieu, encore une fois, à énormément de questions…

  • On dit que ce test est réussi, mais à quel point peut-on s’y fier ?
  • On a automatisé 20 % des tests d’IHM, mais qu’en est-il de la couverture fonctionnelle ?
  • Nos jeux de données sont-ils représentatifs de la réalité ?
  • Les environnements de test ressemblent-ils vraiment à l’environnement de production ?
  • Comment tester nos propres tests ?

Pour conclure

L’esprit critique n’est pas nécessairement une qualité innée, mais il est tout à fait possible de le développer. Pour cela, n’hésitez pas à questionner les vérités toutes faites, les arguments d’autorité. N’oubliez pas que vous participez à la création du produit pour le rendre plus fiable et satisfaisant.

En devenant QA, vous risquez fort de développer une certaine vision du monde – que vous avez peut-être déjà en germe. Et non : ce n’est pas grave, docteur ! 

Au contraire, cultivez ces manières d’être et de voir le monde, cela ne le rendra que meilleur !

Comment les QA voient le monde, épisode 3 : l’empathie

Posted on | by hightest | Leave a Comment on Comment les QA voient le monde, épisode 3 : l’empathie

Le mois dernier, avec Rose Lutz de Alt QA, nous avons parlé d’une déformation professionnelle fréquente chez les QA : le pessimisme.

Nous revenons ce mois-ci avec un nouvel épisode de “Comment les QA voient le monde”, axé sur un autre trait courant : l’empathie !

Se mettre dans la peau des autres : la base !

Rassurez-vous, on ne vous parle pas de devenir un Whisperer comme dans la saison 9 de Walking dead*, mais plutôt de développer cette force des QA qu’on nomme souvent “empathie”.

(*) les Whisperers se camouflent sous une peau de zombie pour passer inaperçus et vivre parmi les vrais zombies.

L’empathie, c’est être capable de voir le monde d’un autre point de vue que le sien. En tant que QA, on fait ça tout le temps, pour aborder le produit testé sous différents angles.

Avant d’aller plus loin, distinguons quand même l’empathie de la sympathie et de la compassion : lorsqu’on est empathique, on comprend les perceptions et sentiments des autres, mais pour autant on garde une certaine distance affective. Aussi, si vous trouvez un bug à la soumission d’un formulaire d’inscription sur Parcours Sup, ce sera normal de ne pas pleurer parce que votre avenir sera foutu !

Quand on parle de l’empathie des QA, on pense avant tout à “se mettre dans la peau des utilisateurs”.

Pourtant, l’empathie est multi-dimensionnelle :

  • sur l’axe du “qui”, l’empathie s’applique aux utilisateurs, mais également au reste de l’équipe, notamment à l’équipe de développement. 
  • sur l’axe du “quoi”, on cherche certes à imaginer les ressentis des utilisateurs, mais également leurs motivations.

Lever au plus tôt un mystère inutile

Mettons, par exemple, que l’équipe travaille sur un produit qui s’étoffe peu à peu. Chaque membre comprend parfaitement la logique de ce produit, les spécifications sont bien connues, suffisamment complètes et semblent correspondre en tous points au besoin exprimé.

Eh oui, “semblent”… Car en effet, comment l’affirmer ? Le 7ème principe du test logiciel est l’illusion d’absence de défaut. La seule vérification du logiciel ne suffit pas, car ce qui est spécifié est souvent incomplet vis-à-vis des besoins réels, dont une partie reste tacite. L’empathie permet alors de se poser des questions qui comblent les vides.

“Le formulaire doit être iso-fonctionnel… certes… et en effet, si on compare les fonctionnalités seules, la correspondance entre le nouveau système et l’ancien semble adéquate. Mais proposer un produit “iso-fonctionnel” suffit-il ? Comment travaillent les personnes ?”

On testera différemment en sachant que : 

  • Les personnes devront remplir le formulaire en moins de 15 minutes en utilisant la fonctionnalité, sous peine de subir l’impatience et la colère de leur clientèle mise en retard
  • Elles utilisent des PC assez lents avec une connexion parfois instable
  • Elles auront besoin de pouvoir remplir le questionnaire en étant hors connexion
  • Elles naviguent au clavier plutôt qu’en utilisant la souris 
  • Ou encore, elles ont l’habitude d’utiliser le même logiciel depuis des années et ne sont pas forcément à l’aise avec l’informatique en-dehors de ça

Décrypter les besoins cachés

Parfois, on découvre ces informations en fin de projet, ce qui produit une forte résistance au changement. Vous connaissez déjà le shift left, rappelez-vous, le rôle de QA c’est aussi challenger les specs. Alors autant anticiper et se poser la question dès le début : pour qui créons-nous ce logiciel ? À quoi ressemble le quotidien de ces personnes ? Quelles sont leurs pratiques et leurs attentes secrètes ? Pour ne pas découvrir ces informations trop tard, notre rôle de QA c’est aussi de questionner au plus tôt les POs et UI/UX Designers pour connaître ces informations. 

Levons donc au plus tôt ce mystère inutile !

Une suggestion pour démarrer : en tant que QA, participez aux ateliers de connaissance de la cible. Si aucun atelier n’est prévu, suggérez l’idée et faites participer vos collègues : la qualité est un travail d’équipe, bien plus vaste que le testing seul.

Deux modèles d’atelier permettant de développer la connaissance de sa cible : la carte d’empathie et les personas. Ces modèles sont proposés en ligne gratuitement par la société Atlas Management.

L’empathie au service de projets plus sereins

Mais l’empathie s’applique de manière plus large, par rapport à l’ensemble de notre équipe, notamment les devs : n’oublions pas que notre rôle est de trouver et leur remonter des bugs dans le fruit de leur travail : la diplomatie s’impose ! Même s’il s’agit davantage de la capacité à communiquer, dans les faits réussir à comprendre comment les devs peuvent percevoir les choses aide à avoir une communication plus cordiale (“il y a un bug” vs “tu as mal codé” : merci la CNV !)

D’ailleurs, en tant que QA, nous nous attachons nous aussi au fruit de notre travail, nous connaissons donc bien les émotions que peuvent ressentir les devs quand leur travail fait l’objet de demande de changements, voire de suppression.

Chaque membre de l’équipe mérite une écoute respectueuse de ses émotions, qui n’est qu’un signal (positif ou négatif, anodin ou significatif) de la santé du projet.

Les motivations sont plus variées que ce qu’on imagine

Souvent, on pense l’empathie uniquement par rapport à l’affect : qu’est-ce que pourrait ressentir l’utilisateur ? Mais il y a aussi un aspect plus factuel, qui consiste à identifier les comportements de l’autre. On sort du ressenti, on entre dans la motivation.

Ce deuxième aspect est particulièrement utile pour les tests end-to-end. Il ne s’agit pas juste de faire un parcours et vérifier que tout se passe comme demandé. On cherche surtout à incarner une vraie personne pour reproduire ses comportements en partant de son intention initiale : quel objectif vise-t-elle ? Quelle attitude a-t-elle (par exemple users, mis-users, abusers) ? Et on voit si le cheminement est fluide et robuste.

Enfin, dans le cas des tests exploratoires on active les deux – ressenti et motivation – simultanément pour se faire une idée de l’application et trouver des dysfonctionnements de tous ordres : utilisabilité, habitudes, failles, etc.

Pour conclure

L’empathie ne se résume donc pas à une simple qualité relationnelle, mais c’est un véritable moteur de performance dans le monde du test logiciel. En se mettant dans la peau des autres – dans notre équipe ou au-delà, parmi la multitude de profils pouvant utiliser notre produit – on réinvente notre façon de concevoir, de tester, de travailler ensemble.

Reste à trouver vos moyens de développer ce super-pouvoir ! Comment procéderiez-vous ?

Comment les QA voient le monde, épisode 2 : le pessimisme (oui, mais “professionnel” !)

Posted on | by hightest | Leave a Comment on Comment les QA voient le monde, épisode 2 : le pessimisme (oui, mais “professionnel” !)

Le mois dernier, avec Rose Lutz de Alt QA, nous avons parlé d’une déformation professionnelle fréquente chez les QA : tout doit être précis, tout doit être carré.

Nous revenons ce mois-ci avec un nouvel épisode de “Comment les QA voient le monde”, axé sur un autre trait courant : le pessimisme !

“Tout ce qui est susceptible d’aller mal ira mal”

(“Anything that can go wrong, will go wrong”)

C’est pas nous, c’est Murphy qui le dit, dans une loi très sérieuse qui porte son nom. Elle pose comme principe que :

“S’il existe plusieurs façons de faire quelque chose et qu’au moins l’une de ces façons peut entraîner une catastrophe, il se trouvera forcément quelqu’un pour emprunter ce chemin”.

Dans la vraie vie, ce “quelqu’un” ce sera l’utilisateur final. Alors oui, c’est vrai, imaginer le pire ça casse l’ambiance, on est d’accord. Mais nous, les QA, c’est notre rôle de voir ce qui peut mal tourner, parce que si on ne l’anticipe pas, ce sera l’utilisateur final qui le fera… Et là, ça peut vraiment être une catastrophe !

Les logiciels ne sont pas des bateaux

“Pardon, mais on en reparle du Titanic ? Sans doute par excès d’optimisme (orgueil ?), il a notamment été construit avec trop peu de canots de sauvetage, pour sauver son look et parce qu’il était prétendument insubmersible. Et pourtant, le pire est arrivé : Jack est mort noyé !”

Le Titanic avait été très soigneusement conçu (avec de nombreux aller-retour avant de valider les plans). Avant d’accueillir son public, il avait également fait l’objet de nombreux tests : 

  • tests de vitesse
  • tests des portes étanches
  • tests des canots de sauvetage (sont-ils en bon état, contiennent-ils bien tout ce qu’il faut… notamment des boîtes à biscuits et des gobelets ?)
  • tests de télécommunication par télégraphie…

(Si vous voulez en savoir plus, nous vous invitons à lire cet article !)

Pourtant, si le Titanic avait été un logiciel, les QA auraient certainement refusé de dire qu’il était insubmersible. Comment apposer un terme aussi flatteur et définitif sur un système complexe ?

De plus, les QA auraient certainement imaginé des tests un peu étranges : 

  • Et si tout le monde décidait de se rendre à babord en emportant toutes ses valises ? Et en poussant tous les meubles à babord aussi ? Pendant un orage exceptionnel ? Est-ce que ça aurait une chance de faire basculer le bateau ? De casser le pont ?
  • Et si le système d’éclairage électrique tombait en panne en pleine nuit ? Une alternative pourrait-elle éclairer les couloirs et les escaliers ? Pendant combien de temps ?
  • Et si un feu se déclarait dans la cuisine ? Dans la soute ? Sur le pont ?
  • Et si le bateau croisait… imaginons… un énorme iceberg ? S’il était positionné à X mètres, sachant que le bateau navigue à X nœuds, pourrait-on le contourner ?
  • Et si on manquait de nourriture (qu’elle soit avariée, ou qu’elle tombe par-dessus bord, ou …) ?
  • Et si des pirates embarquaient à notre insu ?
  • Et si le capitaine avait une crise cardiaque ? 
  • Et si un groupe de cachalots prenait le bateau pour un jouet ?
  • …

La liste est sans fin.

Mais pourquoi tant de pessimisme chez les QA ?

Un début d’hypothèse… Ce n’est pas seulement parce que notre mission est de trouver des défauts. C’est plutôt qu’elle nous amène à déclencher des défaillances ! Le monde numérique nous permet de mettre en œuvre les scénarios les plus farfelus : en effet, dans le pire des cas, on redéploie l’environnement de test et rien n’est véritablement cassé. Notre imagination ne rencontre aucune limite tangible et on peut vraiment voir le pire arriver, en environnement de test. C’est peut-être pour cette raison que, lorsque nous revenons dans le monde physique, on continue d’imaginer les pires scénarios ; on en a vu tellement se produire, y compris de très improbables.

Difficile, donc, de baisser sa garde quand notre métier consiste non seulement à prévoir le pire… mais à le déclencher.

Le pessimisme est créatif

Nous, on se dit que c’est un peu notre capacité spéciale : celle de voir ce que les autres ne voient pas. 

Car oui, tout le monde pense toujours au “happy path”, par contre, arriver à voir les “sad paths”, c’est moins évident.

D’ailleurs, c’est aussi assez créatif d’imaginer tout ce qui pourrait (mal) se passer. Pour ça, on a aussi une technique : toujours penser à incarner 3 types d’utilisateurs différents. Les “users” (les internautes classiques), les “mis-users” (qui enchaînent les gaffes, cliquent à côté, oublient ce qu’il faut faire…) sans oublier les “abusers” (aux mauvaises intentions).

Attention, on tient vraiment à préciser que c’est un pessimisme “professionnel” !

Autant que possible, laissez-le entre votre chaise de bureau et votre clavier pro, pour ne pas sombrer dans la déprime une fois de retour à la maison. Après… il est possible que vous en rameniez un peu chez vous tout de même. Dans votre vie de tous les jours, vous vous surprendrez à porter un regard beaucoup plus soupçonneux sur les sites web et applis en tous genres. “Ma commande est-elle vraiment passée ? Pourquoi devrais-je faire confiance à ce mail de confirmation ? Ma commande est en retard… Et s’il y avait eu un micmac ? Et si on échangeait ma commande avec celle de quelqu’un d’autre ?”

Le pire, c’est que parfois, vous aurez raison. Mais vous risquez aussi de perdre vos amis si vous poussez le bouchon trop loin (qui aime les rabat-joie ?) 😀

Pour conclure

Tant que ça reste un pessimisme professionnel, qu’on garde pour le boulot, il faut le voir comme un atout, car oser regarder les risques en face c’est aussi la garantie de toujours prévoir un plan B… et donc au final de minimiser les risques !

Alors, la prochaine fois que vous croisez la route de QA un peu trop pessimistes à votre goût, souvenez-vous : on est justement là pour ça !

Comment les QA voient le monde, épisode 1 : de la précision avant tout !

Posted on | by hightest | 2 commentaires sur Comment les QA voient le monde, épisode 1 : de la précision avant tout !

Vous voulez rejoindre le métier du test et vous vous demandez à quelles déformations professionnelles vous vous exposez ? 

On vous propose, avec humour et dérision, un petit tour de la question dans une série d’articles !

Cette série a été écrite à quatre mains avec Rose Lutz, consultante QA chez Alt QA. Nous vous invitons vivement à suivre la page LinkedIn de cette société, qui contient beaucoup de contenu intéressant sur le métier du test et la qualité logicielle !

“À une vache près”, pour nous c’est pas assez précis !

Le langage courant est un tissu d’ambiguïtés. Et le problème de l’ambiguïté, c’est que c’est un nid à bugs. Les QA ont donc tendance – et même doivent – prêter une attention soutenue à ces imprécisions, et le plus en amont possible.

D’accord, mais en quoi cela peut constituer une déformation professionnelle ? Parce que notre esprit suspicieux va avoir tendance à décortiquer des affirmations et des consignes en “poussant un peu le bouchon”… Même quand il s’agit d’œuvres culturelles ! 

Vous en doutez encore ? Voici quelques exemples cinématographiques et musicaux qui nous, nous font bugger !

“Les Gremlins ne doivent pas être nourris après minuit.” 👽

Mmh… ça paraît bancal comme spécification, non ? Si je veux le nourrir à 6h du matin, c’est après minuit. Mais à 23h, c’est aussi après minuit, puisque c’est vingt-trois heures après cette heure. À partir de quand est-ce qu’on peut recommencer à les nourrir ?

“Wake me up when September ends” ⏰

Ça, c’est de la sieste ! Mais tu veux que je te réveille quand exactement ? Le 30 septembre à 23h59 ? Ou bien avant ? Mais alors quand ? Quand est-ce que tu considères que le mois de septembre commence à se terminer ? Est-ce que tu considères que le mois de septembre commence du 1er au 15, et se termine du 16 au 30 (ce qui m’autoriserait à te réveiller le 16 septembre à minuit) ?

“Do you remember on the 21st night of September” 🌙

Il s’en passe des choses en septembre ! Mais encore une fois il faut que je te demande une précision : tu veux parler de la nuit du 20 au 21, ou de celle du 21 au 22 ?

Pour conclure

Devenir QA, c’est aussi prendre le risque de regarder le monde différemment. Les phrases les plus anodines deviennent des énigmes à résoudre, et certains mots banals cristallisent notre réflexion. Ça vous fait peur ? En réalité, cela rend le monde encore plus intéressant !

Retrouvez-nous le mois prochain pour l’épisode suivant !

Bouchons et pilotes : qu’est-ce que c’est ?

Posted on | by hightest | Leave a Comment on Bouchons et pilotes : qu’est-ce que c’est ?

En feuilletant un syllabus ISTQB, vous avez peut-être rencontré les termes de “bouchon” (“stub” en anglais) et “pilote” (“driver”). Vous souhaitez clarifier ces notions ? Cet article est pour vous !

Les définitions officielles

Voici les définitions de ces termes tels qu’ils apparaissent dans le glossaire ISTQB.

Bouchon

Type de doublon de test fournissant des réponses prédéfinies.

Pilote

Un composant ou un outil temporaire qui remplace un autre composant et contrôle ou appelle un élément de test de manière isolée.

Ces définitions sont très concises et méritent un petit approfondissement pour y voir plus clair !

Qu’est-ce qu’un bouchon ?

Comme souvent, une métaphore permet de mieux comprendre de quoi il s’agit.

Pour comprendre ce qu’est un bouchon, on peut imaginer une comédienne qui doit répéter un passage, mais son acolyte de scène est encore en route. Pas question d’attendre. Une doublure la rejoint alors sur les planches avec le texte imprimé. À chaque fois que la comédienne dit une réplique, elle lit les réponses de la personne absente.

Un bouchon, c’est comme cette doublure. C’est une simulation de composant qui remplace un autre composant logiciel. Cela peut être pour deux raisons : soit ce composant n’est pas encore disponible, soit on veut réaliser un test en isolant bien les composants.

Imaginons un service en ligne qui permet de calculer les frais d’expédition d’un colis et d’imprimer un timbre en conséquence. Tout est prêt, sauf l’interface avec le service externe qui fournit les tarifs postaux en fonction du poids du colis. Un bouchon peut alors être utilisé pour simuler ce service, et ainsi permettre de réaliser une première simulation du scénario final.

Qu’est-ce qu’un pilote ?

Là encore, utilisons une métaphore ! Un pilote est un composant qui, comme son nom l’indique, va venir diriger, “donner des ordres” au composant à tester. Le pilote est la télécommande, la voiture télécommandée est le composant à tester.

Reprenons le même exemple avec une variante. Si le composant de calcul des frais d’expédition prêt mais que l’interface cliente n’est pas encore développée, un pilote peut être utilisé pour simuler cette interface et fournir les entrées nécessaires. Ainsi, on peut vérifier que le calcul est correct sans avoir à attendre que l’interface soit terminée.

Des petits bouts de code pour expliquer

Un petit bouchon

// Bouchon pour le service de tarifs
public class BouchonTarifsPostaux {
    public double getTarifExpedition(String destination) {
        // Retourne des tarifs fixes en attendant les "vrais"
        if (destination.equals("local")) {
            return 5.0;
        } else {
            return 10.0;
        }
    }
}

Ce bouchon pourrait être utilisé dans cette classe :

public class CalculatriceDeTarifs {
    private BouchonTarifsPostaux bouchon;

    public CalculatriceDeTarifs(BouchonTarifsPostaux bouchon) {
        this.bouchon = bouchon;
    }

    public double calculPrixExpedition(String destination, double poids) {
        double tarif = bouchon.getTarifExpedition(destination);
        return tarif * poids;
    }
}

Un petit pilote

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

public class TestCalculPrix {

    @Test
    public void testCalculPrixExpedition() {
        // Utilisation du bouchon
        BouchonTarifsPostaux bouchon = new BouchonTarifsPostaux(); // Création du bouchon
        CalculatriceDeTarifs calculatrice = new CalculatriceDeTarifs(bouchon); //

        // **Pilote**
        double prix = calculatrice.calculPrixExpedition("local", 2.0);
        assertEquals(10.0, prix, "Le coût d'expédition pour une expédition locale devrait être 10.0");

        prix = calculatrice.calculPrixExpedition("international", 3.0); // Appel de la méthode à tester
        assertEquals(30.0, prix, "Le coût d'expédition pour une expédition internationale devrait être 30.0");
    }
}

Explications

Le bouchon (BouchonTarifsPostaux) simule le service de tarifs postaux, fournissant des tarifs fixes pour les destinations.
Le pilote est le test unitaire (TestCalculPrix). Il initialise les objets nécessaires, appelle la méthode à tester (calculPrixExpedition) et vérifie que les résultats sont corrects.

Et vous, quelles métaphores et exemples utiliseriez-vous pour expliquer ce que sont les bouchons et les pilotes ?