Catégorie : Méthodologie

Le numéro de téléphone est un grand classique des formulaires, ce n’est pas le champ le plus complexe à tester. Toutefois, c’est l’un de ceux où l’on rencontre régulièrement des problèmes, d’où l’idée de lui consacrer un article !

Une petite anecdote pour commencer

Récemment, une personne de notre entourage achetait en ligne un billet de train. Au moment de renseigner son numéro de téléphone, impossible : le formulaire refusait obstinément la valeur saisie. Trop courte, visiblement, alors même que l’indicatif calédonien avait bien été sélectionné dans la liste. Pour contourner le problème, elle a saisi le numéro français d’un proche résidant en métropole, et la commande est passée.

C’est exactement le genre de bug qui transforme un simple achat en source d’irritation pour une partie de la clientèle. Et c’est typiquement ce qu’un bon jeu de données aurait dû détecter !

Qu’est-ce qui compose un numéro de téléphone ?

Au niveau international, la référence est la norme E.164 de l’UIT (Union internationale des télécommunications). Elle pose deux règles simples mais essentielles :

• un numéro complet comporte au maximum 15 chiffres (hors préfixe) ;
• il s’écrit sous la forme indicatif pays + numéro national.

L’indicatif pays fait de 1 à 3 chiffres. Le numéro national a une longueur qui dépend entièrement du pays.

Le piège n°1 : supposer que tous les numéros ont la même longueur

C’est l’erreur de notre site de billets de train. En métropole, on a l’habitude des numéros à dix chiffres. Mais d’un pays à l’autre, ce nombre varie énormément. Voici quelques exemples :

– 4 chiffres : Niue (+683)

– 6 chiffres : Nouvelle-Calédonie (+687)

– 7 chiffres : Islande (+354)

– 8 chiffres : Norvège (+47)

– 9 chiffres : Espagne (+34)

– 11 chiffres : Chine (+86)

Coder en dur « un numéro = 10 chiffres », c’est s’assurer d’exclure une partie de la population. La règle de longueur doit dépendre du pays sélectionné.

Piège n°2 : une mise en forme mal gérée

Deux difficultés se rejoignent ici. D’abord, le zéro. En France comme dans beaucoup de pays, le 0 initial est un préfixe national d’acheminement : on le compose en interne, mais il saute dès qu’on passe à l’international. Le 06 12 34 56 78 devient +33 6 12 34 56 78, sans le zéro. Faut-il alors saisir le 0 ? L’indicatif ? Les deux ? C’est une source classique d’interrogations, avec possiblement des données hétérogènes à la clé.

De plus, un numéro peut s’écrire de multiples façons différentes : avec des espaces, des points, des tirets, voire des parenthèses… Plutôt que de tenter d’accepter puis de nettoyer toutes ces variantes (et de risquer d’en oublier) notre préconisation est plutôt de :

– n’autoriser que les chiffres dans le champ : tout caractère non numérique est bloqué dès la frappe (pensez à tester la lettre « e » qui passe parfois à travers les mailles du filet…) ;

– utiliser intelligemment les placeholders pour lever le doute sur le format attendu ;

– afficher un masque de saisie, pour encore plus de confort (faire en sorte par exemple qu’une petite espace s’affiche entre chaque paire de chiffres).

Conclusion

Un champ de numéro de téléphone ne réclame pas des trésors d’ingéniosité, mais un peu d’attention là où on n’en met pas spontanément. Varier les pays, les longueurs et les modes de saisie dans vos jeux de données suffit à débusquer l’essentiel de ces problèmes. Bons tests !

« TMMi ». Que vous a évoqué cet acronyme la première fois que vous l’avez lu ? Probablement un standard très strict, applicable uniquement aux très grosses organisations, et peut-être trop rigide pour suivre le rythme effréné des changements que vit constamment le monde de l’informatique, surtout à l’ère de l’agilité… et surtout à l’ère de l’IA.

Est-ce mérité ? On ne va pas faire durer le suspense : non. Dans cet article, nous allons voir pourquoi TMMi reste un référentiel tout à fait pertinent, à condition de comprendre comment il fonctionne réellement. Car bien souvent, ce qu’on reproche à TMMi, c’est en réalité une idée qu’on s’en fait sans l’avoir vraiment étudié !

D’où vient cette réputation ?

TMMi (Test Maturity Model integration) est un modèle de maturité dédié au processus de test. Il permet de situer son organisation sur une échelle de 1 (très faible maturité, niveau « initial ») à 5 (très forte maturité, niveau « En optimisation »). Cela peut évoquer de lourdes démarches d’audit, d’épais classeurs qui prennent la poussière, des certifications accrochées au mur et dont la moitié de l’entreprise ignore même la signification, et qui ne servent à rien d’autre que se faire un peu mousser…

Mais si on regarde de plus près la mécanique du modèle, on comprend que l’idée n’est pas de coller une étiquette et de poser des jalons artificiels. Il s’agit plutôt de dessiner une perspective et d’insuffler des dynamiques vivantes, au plus près des objectifs réels de l’organisation.

Structure de TMMi

TMMi structure la maturité du test en 5 niveaux. Le niveau 1, c’est la case départ  : même une entreprise qui ne ferait aucun test pourrait « prétendre » à ce niveau. Ainsi, chaque niveau sauf le premier contient ce qu’on appelle des « domaines de processus », qui représentent des grands axes de travail. Au total, on compte 16 domaines de processus.

À leur tour, chacun des domaines de processus contient des objectifs… qui eux-mêmes contiennent des pratiques… qui elles-mêmes peuvent être détaillées en sous-pratiques et exemples de produits d’activité (autrement dit, des documents ou artefacts qui retracent cette activité). Un peu partout, on peut aussi trouver des notes, des exemples, des références.

Trop de jargon ?

C’est ici en effet que beaucoup de gens décrochent. Tout ça commence à ressembler à une énorme montagne de cases à cocher, et on peut avoir peur de se perdre dans les branches de cette arborescence.

Mais qu’il faut s’accrocher parce qu’il y a une subtilité qui fait tout basculer !

TMMi… c’est comme une pizza

Embarquons-nous dans la métaphore la plus hasardeuse de l’histoire de ce blog, avec nos excuses par avance aux personnes qui en savent plus que nous sur les pizzas.

Le modèle TMMi, nous venons de le voir, dispose d’une structure où les éléments s’emboîtent les uns dans les autres. Les niveaux de maturités contiennent des domaines de processus, qui contiennent des objectifs, qui contiennent des pratiques, qui contiennent des sous-pratiques et des exemples de produits d’activité.

C’est la même chose pour les pizzas : la pâte soutient la base (base crème ou base tomate), et la base soutient les différents ingrédients.

Et les éléments de TMMi, comme les ingrédients de la pizza, ont différents statuts.

Les éléments requis

Les domaines de processus sont requis pour atteindre un niveau de maturité. Et pour qu’un domaine de processus soit validé, il faut que ses objectifs soient remplis ; ces objectifs sont également requis.

On imagine difficilement une pizza sans pâte.

Exemple TMMi : le niveau 2 de TMMi contient 5 domaines de processus, dont « Politique et stratégie de test ». Ce domaine de processus présente 3 objectifs : « Établir une politique de test », « Établir une stratégie de test » et « Établir des indicateurs de performance du test ». Tout ça, c’est requis.

Les éléments attendus

Sous les objectifs requis, on trouve les pratiques, et c’est ici qu’arrive la nuance la plus importante. Les pratiques ne sont pas des composants requis, mais attendus.

Citons le modèle :

Les composants attendus décrivent ce qu’une organisation doit généralement mettre en œuvre pour satisfaire à un composant requis. Les composants attendus guident ceux qui mettent en œuvre des améliorations ou effectuent des évaluations. […] Les pratiques décrites ou des alternatives acceptables à ces pratiques doivent être présentes dans les processus planifiés et mis en œuvre de l’organisation, avant que les objectifs puissent être considérés comme atteints.

~Le modèle TMMi, p. 14. Le gras et le soulignement sont de notre initiative.

Relisez bien : ou des alternatives acceptables. Autrement dit, TMMi ne dit jamais « Faites exactement ceci, de cette façon ». Il dit « Voici une pratique attendue, et si vous faites autrement tout en respectant l’esprit de la démarche, c’est recevable ». TMMi est souple par nature. Juste assez souple pour que les intentions du modèle restent au cœur de la démarche, et non les détails du « comment », qui restent à la discrétion des organisations.

Ainsi, toute pizza qui se respecte a une base, mais ça peut être une base tomate ou une base crème. Ce qui est attendu, c’est que la pâte soit recouverte d’une couche uniforme et goûteuse ; c’est à vous de voir laquelle est la meilleure pour votre contexte.

Exemple TMMi : une des pratiques de l’objectif « Établir une politique de test » est « Définir la politique de test ». Le texte qui l’accompagne est le suivant :

Une politique de test, alignée avec la politique de l’entreprise (qualité), est définie en fonction des objectifs de test et approuvée par les parties prenantes.

~Le modèle TMMi, p. 27

Il est tout à fait possible ici d’accepter des alternatives. Si votre entreprise n’a pas de politique de test à part entière, mais dispose d’un document dont certains passages sont conformes à ce qu’on attend d’une politique de test, alors la pratique peut être validée.

Les éléments informatifs

Tous les autres composants que nous avons cités sont informatifs. Ceux-là ne sont jamais obligatoires lors d’une évaluation. Ils existent dans le modèle TMMi pour illustrer, donner des pistes concrètes, montrer ce que d’autres organisations ont mis en place. Il faut comprendre ça comme « il arrive que les équipes procèdent ainsi », et non comme une consigne. Les modalités d’application étant infinies, TMMi se garde bien de les imposer.

Et tout ça rappelle le nombre extrêmement varié de choix d’ingrédients et d’assaisonnements qu’on peut répandre sur notre pizza.

Exemple TMMi : parmi les sous-pratiques de la pratique « Définir la politique de test », on trouve « Clairement séparer le test du débogage dans la politique de test ». C’est une simple option, à prendre seulement si ça vous paraît pertinent.

Alors, trop rigide ?

TMMi se compose donc de trois étages : ce qui est requis (les domaines de processus et les objectifs, intouchables), ce qui est attendu (les pratiques, avec leurs alternatives possibles) et ce qui est informatif (les éléments purement indicatifs).

Ce qu’on reproche à TMMi — la lourdeur, la rigidité, l’inadaptation au terrain repose donc sur une lecture bien superficielle.

La Fondation TMMi apporte d’ailleurs un parfait exemple de cette souplesse, avec son document TMMi dans le monde agile. Il ne faut surtout pas lire ce document comme un erratum, une mise à jour ou encore une reculade par rapport à tout ce qui est dit dans le modèle TMMi. C’est bien au contraire une éclatante illustration de la souplesse du modèle.

Envie de vraiment maîtriser TMMi ?

Si cet article vous a donné envie d’aller plus loin que les idées reçues sur TMMi, nous avons développé une plateforme de e-learning entièrement dédiée à TMMi, pour s’approprier le modèle pas à pas, sans s’y perdre. Laissez-nous un commentaire si vous souhaitez en savoir plus !

Vous souhaitez monter en compétences sur le test logiciel. Peut-être visez-vous une certification ISTQB (International Software Testing Qualifications Board) ou TMMi (Test Maturity Model integration). Et très vite, une question se pose sur les modalités de la formation : faut-il rejoindre une session inter-entreprises, ouverte à des personnes venues d’horizons divers, ou organiser une session en intra-entreprise, réservée à vos équipes ? Les deux formats préparent aux mêmes certifications, mais ne produisent pas tout à fait les mêmes effets… Faisons le point sur leurs forces et leurs limites !

La formation inter-entreprises

Ses atouts

Le premier bénéfice de ce format est humain. Réunir des profils venus d’entreprises, de secteurs et de cultures de test différents crée une richesse d’échanges qu’on ne peut pas reproduire en vase clos. Une personne confrontée à un problème de gestion des tests entendra peut-être comment une autre l’a résolu dans un contexte tout à fait différent. Ces rencontres élargissent les perspectives et donnent des clés supplémentaires.

Le choix de ce format est d’autant plus pertinent quand peu de personnes d’une même organisation sont concernées.

Aussi, davantage de personnes dans une même session, c’est davantage de questions et d’interactions, qui favorisent bien souvent l’ancrage des connaissances en vue de passer les certifications !

Ses limites

Le revers de cette ouverture, c’est un contenu plus générique. Le programme ne peut pas s’adapter aux spécificités de votre organisation, ni s’appuyer directement sur vos cas concrets, encore moins sur des informations confidentielles. Les exemples restent volontairement « standard », et les discussions spontanées qui ont lieu sont nécessairement contraintes par ces aspects.

À noter

Un autre élément à prendre en compte est que la formation se déroule dans un lieu neutre, et non dans les locaux de votre organisation. Il faut anticiper le déplacement des personnes.

La formation intra-entreprise

Ses atouts

Le format intra-entreprise, quant à elle, se distingue par sa capacité d’adaptation. Le contenu peut s’ancrer dans votre réalité : vos applications, vos processus, vos cas de test, y compris des sujets sensibles qu’on n’aborderait jamais devant un public extérieur. La théorie du syllabus se relie alors directement à votre pratique.

Il vous est d’ailleurs possible de demander des adaptations au moment où vous planifiez cette formation. Si vous souhaitez avant tout former vos équipes sur la méthodologie, sans forcément leur faire passer les certifications, le contenu de la formation pourra être ajusté, en faisant l’impasse sur les tests blancs notamment.

Ses limites

Le risque principal est l’entre-soi. À rester entre collègues, on se prive du regard extérieur et des idées venues d’ailleurs. C’est d’autant plus vrai dans les organisations où l’équipe de test est très réduite. Former une ou deux personnes d’une organisation, pourquoi pas (nous l’avons déjà fait et le referons !), en revanche cela réduit les échanges possibles.

Un autre écueil est que, lors de telles formations, si elles se passent sur le lieu de travail habituel des personnes, celles-ci risquent de se laisser rattraper plus facilement par leur quotidien. Elles conservent leur PC portable habituel, reçoivent leurs mails et y répondent… Autant de micro-interruptions qui nuisent à la qualité de leur apprentissage. Attention à cet aspect !

À noter

Les formations préparant au passage de certifications ont un rythme soutenu. Il est très intéressant de pouvoir s’appuyer sur des exemples internes pour illustrer les concepts, toutefois il n’est pas possible de digresser trop longtemps. Un équilibre sera trouvé entre la théorie et le quotidien.

Dans un cas comme dans l’autre…

Nous remarquons toujours, au moins une fois par session, un décalage entre le vocabulaire utilisé dans les syllabus et celui utilisé dans les organisations. C’est parfaitement normal. Une partie du travail consiste à prendre du recul vis-à-vis du vocabulaire, et de s’attacher plutôt aux concepts et aux intentions spécifiques des textes de référence.

En formation inter-entreprises, cela permet de se rendre compte que des mots différents au sein de plusieurs organisations peuvent recouvrir les mêmes objectifs, et s’attacher à bien décortiquer ceux-ci en priorité. ISTQB et TMMi proposent certes une lingua franca permettant à des QA de tous horizons de se comprendre, mais n’imposent jamais de détruire le vocabulaire interne d’une organisation. Cela serait parfaitement contre-productif, et mal vécu par les personnes qui utilisent ce vocabulaire de bonne foi depuis des années.

En formation intra-entreprise, les jeux de miroir sont forcément moins nombreux, mais cela facilite également la « traduction ». La formatrice ou le formateur peut ensuite, au cours de la session, plus facilement faire référence au vocabulaire de l’entreprise.

Un exemple classique de décalage entre le vocabulaire standard et celui de « la vraie vie »

ISTQB parle de « tests de régression », et jamais de « tests de non régression », une formule pourtant très souvent utilisée en pratique (avec son célèbre acronyme « TNR »). Bien qu’il soit intéressant de comprendre pourquoi cette formule est privilégiée dans les syllabus, il est inutile de corriger systématiquement les personnes qui emploient l’autre expression !

Conclusion

Il n’y a pas de format qui soit meilleur dans l’absolu, seulement un format plus adapté à votre situation. Dans les deux cas, la certification visée reste la même.

Nous vous souhaitons bonne route sur votre chemin d’apprentissage ! Contactez-nous si vous souhaitez vous former au test logiciel.

Cet autre article pourrait vous plaire : Les 3 bénéfices ultra-concrets des certifications.

« Test Cedric » a fait le tour du web en quelques heures. Ces deux mots ont été envoyés dans une notification du Crédit Agricole, hier, le mardi 9 juin. Des millions de personnes la reçoivent, et bon nombre, intriguées, cliquent dessus. Et sous cet afflux inopiné… l’appli tombe. Cette histoire nous en rappelle d’autres, par exemple la notification de l’application Air France du 24 janvier 2022, « Test de Julien à nouveau ». Vous vous en souvenez ?

Certes, ce n’est pas un bug logiciel, mais une confusion d’environnements. C’est ce qui se passe ensuite que nous trouvons riche d’enseignements.

 

Leçon 1 : un incident bien géré rend plus sympathique qu’un parcours sans accroc

Cette idée peut être contre-intuitive, surtout dans notre métier où on a plutôt tendance à rechercher l’irréprochabilité.

En 1966, le psychologue Elliot Aronson met en évidence ce qu’on appelle l’effet pratfall (« pratfall » signifiant « gaffe »). Une personne perçue comme compétente devient plus sympathique lorsqu’elle commet une petite maladresse. La faille la rend humaine, donc attachante.

Le Crédit Agricole a appliqué ce principe à la lettre. La marque a présenté ses excuses, puis a réagi avec humour : nouvelle photo de profil, et surtout un nouveau nom, « Cédric Agricole ». Une grande banque, institution sérieuse s’il en est, qui se moque gentiment d’elle-même, c’est exactement la petite gaffe assumée qui fait basculer la perception du côté de la sympathie.

À noter que l’effet pratfall n’a lieu que si la boulette est commise par une personne (ou une organisation, en l’occurrence) disposant initialement d’une bonne image. On peut d’ailleurs analyser les choses à l’envers : le fait que le web rie de bon cœur à la réponse du Crédit Agricole ne fait que confirmer de la bonne réputation de cette banque de manière générale. Un établissement déjà connu pour de nombreux faux pas aurait plutôt provoqué des moqueries et du dédain.

Ce phénomène a un cousin du côté du marketing des services : le paradoxe de la récupération de service (« service recovery paradox »), étudié au début des années 1990 par les chercheurs Michael McCollough et Sundar Bharadwaj. Bien réparé, un incident peut laisser une clientèle plus satisfaite (et plus fidèle) que si rien ne s’était passé.

 

Leçon 2 : la transparence et l’humour fonctionnent mieux que le silence

Le chercheur américain William Benoit a recensé les stratégies possibles que mettent en œuvre les marques lors d’une crise. Ces stratégies sont développées dans sa théorie de la restauration d’image (« image repair theory », ou « image restoration theory »). Deux d’entre elles sautent aux yeux ici.

La première est nommée « mortification » (un terme dont la connotation est moins dramatique en anglais qu’en français…) Cela consiste dans le fait de reconnaître la faute et s’excuser, sans chercher d’excuse bancale. Le Crédit Agricole est bien passé par là, en s’excusant pour la gêne occasionnée.

La seconde, c’est la réduction du caractère offensant (« reducing offensiveness »), et l’humour en est un levier redoutable. En transformant l’incident en plaisanterie collective, la marque a requalifié l’événement. Ce qu’on retient, ce n’est pas une banque qui a planté, mais l’humour dont elle a pu faire preuve.

Une très bonne infographie sur la théorie de la restauration d’image est disponible à cette adresse.

 

Leçon 3 : ne jamais accabler la personne derrière l’erreur

C’est sans doute la leçon la plus précieuse, et la plus transposable à nos équipes. Pendant que le public s’amusait à plaindre Cédric (et Burger King, toujours adepte du newsjacking, à lui suggérer plaisamment de postuler dans leur entreprise…), le Crédit Agricole a répliqué que l’entreprise ne laisse personne tomber, surtout pas Cédric.

Derrière la blague, on devine un vrai message de culture interne. L’idée n’est pas de déresponsabiliser, mais de reconnaître qu’une équipe qui permet à une seule personne de tout faire tomber a un problème de processus, pas un problème de personnel. Défendre publiquement Cédric, c’est envoyer un signal clair : ici, on a le droit de se tromper ; on peut parler des échecs. On évite ainsi les effets boule de neige qu’impliqueraient une dissimulation d’un problème. Les intérêts de l’entreprise et des personnes qui y travaillent convergent admirablement sur ce point !

 

Conclusion

La notification « Test Cedric » n’était pas un bug, mais cet incident dessine une réaction adéquate possible face à un vrai bug en prod : expliquer sans se cacher, dédramatiser sans minimiser (si la situation s’y prête), et protéger les personnes plutôt que les pointer du doigts.

Et vous, avez-vous déjà transformé un incident en occasion de renforcer la confiance, en interne ou auprès de votre clientèle ?

Il y a quelques mois, nous vous avons proposé un jeu d’immersion pour jongler avec les concepts du syllabus ISTQB CTAL TM. Le suspense a assez duré, voici les réponses aux questions ! 🙂

Comme prévu, nous avons également cité vos meilleures réponses.

À la lecture de ces mails, parmi les 7 activités qui constituent le processus de test standard, auxquelles avez-vous la certitude d’avoir participé dernièrement ?

Rappelons d’abord ce que sont ces 7 activités :

• Planification des tests
• Pilotage et contrôle des tests
• Analyse de test
• Conception des tests
• Implémentation des tests
• Exécution des tests
• Activités de clôture des tests

Les mails permettent d’identifier 4 de ces activités :

Planification des tests

Le plan de test de Servmanyax est évoqué plusieurs fois.

Pilotage et contrôle des tests

Le décalage de la mise en production de Wafwaf est acté suite aux « éléments fournis lors de la dernière sprint review ». Cette mesure correspond à une action corrective, typique du contrôle des tests.

Implémentation des tests

L’automatisation des tests sur l’appli Wafwaf est évoquée.

Activités de clôture des tests

La rétrospective évoquée par Anna Drénalin fait partie des activités de clôture des tests.

Considérez-vous que le plan de test de l’application Servmanyax est validé ? Pourquoi ?

“Le plan de test doit être accepté par toutes les parties prenantes et, par conséquent, les désaccords entre elles doivent être résolus.”

La DSI Jessica Scroute, absente, n’a pas lu le plan de test.

Le DSI adjoint Sam Eum, absent également, approuve le plan de test mais ne l’a pas lu non plus.

Il n’est donc pas validé.

Vos réponses

Une personne anonyme commente élégamment l’attitude de Sam Eum : « On appelle ça du management par tampon encreur » !

Quel est le SDLC du projet Servmanyax ?

Comme l’a dit une personne anonyme, « hybride ou pseudo-agile presque« .

En effet ! Le vocabulaire agile parsème les mails de l’organisation, pourtant certaines pratiques témoignent d’une culture plus traditionnelle. En témoigne le mail de Jacques Antan : « On me met un peu la pression pour avoir des chiffres précis des coûts par fonctionnalité, en amont du lancement. »

Nous vous renvoyons au syllabus CTAL-TM, qui aborde les SDLC hybrides.

Suivant les bons conseils de votre collègue Yves, vous décidez d’organiser un atelier d’identification des risques. Qui serait-il pertinent de consulter pour l’identification et l’analyse des risques, et pourquoi ?

• Farah Antastique, CEO – Si possible. Le contexte ne permet pas de savoir si elle participe à ce genre de réunion. Dans le doute, l’inviter serait une bonne idée.
• Jessica Scroute, DSI – Elle a été sollicitée sur la relecture du plan de test, c’est donc normal qu’elle participe à cet atelier
• Sam Eum, DSI adjoint – Idem
• Charles Apricorne, RSSI – Cette partie prenante est susceptible d’apporter un éclairage unique sur sa spécialité, la sécurité informatique
• Jacques Antan, chef de projet et Product Owner ParapluY et Servmanyax – Cette partie prenante est incontournable pour le projet
• John Okari, administrateur système – Impliquer cette partie prenante est essentiel pour anticiper les risques liés à la mise en production (et limiter les frictions historiques)
• Léonard Ampion, responsable du pôle UX – Cette partie prenante sera impliquée sur le projet, notamment pour les enjeux liés à l’accessibilité
• Yves Olanda, QA – Pour apporter un regard complémentaire sur les risques qualité
• Giani Ustatif, fondateur et gérant du restaurant Le Tofu fou (peut être remplacé par Marion) – En tant que client final
• Marion Outarde, directrice du restaurant Le Tofu fou (peut être remplacée par Giani) – En tant que cliente finale

Quels sont les risques PROJET que vous anticipez d’ores et déjà ?

Nous avions listé celles-ci :

• Absence ou indisponibilité de parties prenantes clés (cf Jessica, mais aussi Sam qu’il a fallu relancer pour la relecture du plan de test)
• Risque de changement d’exigences ou d’objectifs stratégiques (cf Sam et les changements d’avis concernant l’accessibilité)
• Risque lié au manque de préparation ou de clarté dans le plan de test (cf remarques de Yves)
• Risque de surcharge ou de pression sur les ressources (cf Jacques Antan)
• Risque de communication insuffisante ou tardive (cf en interne cf John Okari, et en externe Giani Ustatif)
• Résistance au changement par le personnel, car le personnel du restaurant n’est pas impliqué !
• Relations tendues entre équipes (cf John Okari)
• Flou autour du SDLC (discours très orienté agile alors que dans les faits, on est plutôt sur de l’hybride non assumé)

Vos réponses

D’autres risques ont été relevés en complément :

• « Grégoire est parti. 5 ans d’expérience envolés et visiblement pas de passation. La connaissance elle est partie avec lui. »
• Le fait que le PO de Servmanyax soit aussi PO d’un autre produit pourrait nuire à sa disponibilité sur le projet.

Quels sont les risques PRODUIT que vous anticipez d’ores et déjà ?

Voici ceux que nous avions listés. Notez que les risques produit comprennent des risques fonctionnels et non fonctionnels.

• Réservation en double du même shift
• Portabilité insuffisante (affichage imparfaitement géré en fonction de la taille de l’écran)
• Accessibilité insuffisante
• Fuite de données personnelles via la messagerie
• Accès non autorisé au tableau de bord
• Indicateurs incorrects dans le tableau de bord
• Perte de performance des équipes ou abandon de l’outil en raison d’un temps de chargement trop élevé
• Faible engagement du personnel à cause de la complexité des fonctionnalités
• Produit non conforme aux valeurs du personnel
• Non-respect des règles RGPD
• Non-respect du droit du travail

Vos réponses

D’autres risques ont été identifiés (toujours en anonyme) :

• « La gamification avec les points convertibles en bons cadeaux. Ça sent le calcul foireux et la faille d’exploitation à plein nez. »
• « La marque blanche. Chaque resto va vouloir sa customisation. Faut anticiper les régressions à chaque variante. »
• « Et la gestion des shifts avec pré-réservation et validation manager. Si deux serveurs réservent le même créneau et que le système gère mal le conflit, c’est la cata côté utilisateur. »

L’organisation où vous travaillez semble souffrir de nombreux défauts. Toutefois, quels sont les points forts que vous lui trouvez ?

Effectivement, Tekmanyax n’est pas l’entreprise modèle, ni pour le test, ni pour la méthode agile, ni pour l’organisation de manière générale ! En revanche, voici quelques points sur lesquels que nous avions noté et que vous pourriez capitaliser si vous y travailliez :

• L’entreprise s’intéresse activement aux tests non fonctionnels
  • Sécurité (embauche de RSSI)
  • Utilisabilité (stratégie d’accessibilité)
• Des compétences en test sont déjà présentes (cf Yves Olanda)
• Plusieurs mails montrent une bonne volonté, une disponibilité et une collaboration active :
  • Yves (QA) est un bon soutien.
  • Le RSSI est disponible et ouvert à la discussion
  • Un service communication existe, qui pourrait éventuellement être mobilisé pour passer des informations sur les tests.
  • Les remerciements et les encouragements sont fréquents, même s’il existe par ailleurs des conflits.

Vos réponses

D’autres points ont été soulevés en complément, en anonyme encore :

• L’implication du Tofu Fou, même si elle pourrait être améliorée
• “Y’a des vraies rétros, des sprint reviews, du feedback client. Anna ramène des muffins au daily. C’est con mais ça compte.”
• “Y’a de la transversalité. Le QA bosse avec les devs, le PO, le client. C’est pas chacun dans son couloir…”
• “L’accessibilité est une priorité affichée. C’est pas encore clair sur le niveau WCAG mais au moins c’est sur la table. Y’a un stagiaire UX dédié et un responsable identifié.”

« Les noms des collabs » a aussi été noté comme un atout, nous vous remercions pour cette appréciation de notre humour 😋

Quel facteur d’hygiène favoriserait la stabilité de l’équipe de test ?

Une rémunération convenable (c’est la frustration de Grégoire Ateau à ce sujet qui provoque son départ).

Vos réponses

Alexandrine rappelle : « L’absence de ces facteurs ne motive pas… mais leur présence évite la démotivation et le turnover ».

Que pensez-vous de la proposition de Grégoire en ce qui concerne l’outil d’accessibilité dont il parle ?

Un rappel de ce que dit Grégoire :

J’ai entendu dire qu’on allait enfin s’attaquer à la question de l’accessibilité. C’est une bonne nouvelle et je pense que ce serait bien qu’on utilise l’outil Accessilly. C’est vraiment pas une grosse dépense par rapport à ce que ça va nous apporter. La licence n’est pas chère du tout (100 € par an), et puis on peut tout installer sur notre SI, donc on serait autonomes pour gérer l’appli. Qu’est-ce que t’en penses ? T’en parles à Samuel à l’occasion ?

Grégoire n’évoque à aucun moment les exigences de l’organisation en termes d’outillage d’accessibilité. À ce stade, ces exigences sont d’ailleurs encore en chantier.

De plus, il a une vision très restreinte des coûts qu’implique un outil. La licence est une chose, les coûts de maintenance et de formation (notamment) en est une autre. Il y a également d’autres coûts initiaux à prendre en compte ; en effet, si le logiciel doit être intégré dans le SI, cela nécessite de faire intervenir l’équipe d’exploitation, ce qui n’est pas anodin. Demandez son avis à Jacques Okari !

Vos réponses

Se pose aussi, bien sûr, la question de la gouvernance.

Une personne commente en anonyme : « Grégoire est parti. Donc qui va installer, configurer, maintenir l’outil ? Qui a la compétence ? Lucas le stagiaire ? Léonard le responsable UX ? »

La conclusion d’Yves est-elle correcte au sujet de la maintenance des tests Dynoz ? Si oui, expliquez-la ; si non, expliquez pourquoi.

Voici un rappel de la problématique exposée par Yves :

Pour la maintenance des tests auto de l’appli Dynoz, ça risque d’être vraiment coûteux. Au vu des fois précédentes, je chiffre ça à 100 jours de travail. On comptait déléguer ça à la boîte de prestation habituelle à 500 € / jour, je te laisse faire le calcul… Les scripts de test ont tous été développés par cette boîte avec leur outil open-source qu’on ne connaît pas du tout, dans leur syntaxe zarbi qu’on ne connaît pas du tout non plus, mais je pense que ça vaudrait le coup (et le coût…) de monter en compétences dessus histoire d’être autonomes et de ne pas se ruiner. T’en parles à Samuel ?

Quelques jours plus tard, Yves revient, triomphal :

Ok, j’ai la réponse de la boîte de prestation au sujet de Dynoz. La formation à l’outil et au projet d’automatisation durerait 10 jours, toujours à 500 € la journée. On pourrait demander une formation pour toute l’équipe de test, donc 10 personnes (et pas pour Grégoire d’après ce que j’ai cru comprendre…) Autant te dire que pour 10 fois moins cher, on devient capables de maintenir les tests de Dynoz ! Super non ? Tiens, si tu veux des chiffres, je me souviens de comment on calcule le ROI.
(Bénéfices – Coûts récurrents) / Coût initial * 100
Soit : (50 000 – 0) / 5 000 * 100 = un ROI de 1 000 % !!!
Yves Olanda, QA
PS : Bon, pour être réaliste je pense que vu la complexité de la chose, même après une formation on ne pourra pas bosser aussi rapidement que la boîte de presta, en tous cas pas dès le début. Ce que la boîte fait en 2 jours, on le fera probablement en 3. Mais bon, c’est déjà top !

Aïe aïe aïe ! Bien sûr que c’était trop beau pour être vrai, et plus de la moitié d’entre vous ont bien flairé le piège.

Le coût de formation fournie par la société de prestation est bel et bien 10 fois inférieur au coût de la prestation. Toutefois, cette analyse est superficielle et doit être complétée.

2 éléments majeurs sont omis par Yves :

• Les coûts d’opportunité : pendant que l’équipe de test sera formée et maintiendra ces automates, elle ne pourra rien faire d’autre. Ce sont 150 jours-personne internes qui seront ainsi bloqués pour la maintenance, et 100 jours-personne (10 jours pour 10 personnes) qui seront bloqués pour la formation, soit 250 jours qui seront consacrés à ce sujet, et pas à autre chose.
  (150 jours sont prévus pour la maintenance et non 100, car 2 jours pour la société de prestation aguerrie = 3 jours pour le personnel interne selon l’estimation d’Yves)
• Le personnel interne a aussi un coût. Il faut mettre en balance les 500 € / jour-personne de la société de prestation, non pas avec une somme de 0 € / jour-personne pour les internes, mais comme l’indique Jacques dans son mail, plutôt 200 €.

Le coût de la prestation est donc de 50 000 €, mais si la formation et la maintenance en interne était choisie à la place, cela pourrait tout de même coûter… 55 000 € !

Ce nombre est calculé ainsi :

• 25 000 € de coût initial
  • 5000 € de coût de formation, fournie par la société de prestation
  • 10 jours * 10 personnes * 200 € pour la main d’œuvre interne en formation : 20 000 €
• 30 000 € de coût récurrent
  • 150 jours * 200 € par personne pour la maintenance = 30 000 €

Selon ce calcul plus réaliste, le ROI de l’internalisation des 100 jours de test est le suivant :

(Bénéfices – Coûts récurrents) / Coût initial * 100

(50 000 – 30 000) / 25 000 * 100, soit… 80 %, bien inférieur aux 1 000 % estimés par Yves.

80 % de ROI, ce n’est bien sûr pas mauvais. Toutefois, choisir ce scénario demanderait tout de même une analyse approfondie.

Facteurs favorables	Facteurs défavorables
L’appli Dynoz va avoir régulièrement besoin de maintenance	L’appli Dynoz risque d’être décommissionnée à moyen terme.
Le personnel interne a exprimé son souhait d’être formé sur cette technologie (facteur de motivation)	Le personnel interne considère dans sa majorité que Dynoz et tout son environnement technique sont vieillissants et peu enthousiasmants. On sait déjà que c’est un outil avec une « syntaxe zarbi », propre à cette société de prestation. Prudence…
Les décisionnaires déplorent les délais de mobilisation de la société de prestation ; bien souvent, il faut attendre plusieurs semaines avant qu’elle soit disponible	Le personnel interne, même s’il est formé, n’aura pas suffisamment de temps à consacrer à Dynoz. Dans sa majorité, il apprécie de pouvoir s’appuyer sur des compétences externes qui permettent d’alléger sa charge de travail.
Les équipes internes connaissent bien le périmètre fonctionnel de Dynoz.	Les équipes internes ne connaissent pas du tout le périmètre fonctionnel de Dynoz, et la documentation est à ce jour lacunaire. Des coûts supplémentaires en transfert de connaissances et en documentation seraient nécessaires.
Les équipes de test sont relativement stables dans le temps et partagent efficacement les connaissances.	Les personnes restent en moyenne 2 ou 3 ans dans l’entreprise, ce qui nécessiterait d’autres formations régulièrement.

Vos réponses

Une personne anonyme suppose qu’Yves n’a pas bien compris les modalités des coûts de formation : « La formation c’est 10 jours à 500 euros par jour pour 10 personnes. 10 x 500 x 10 ça fait 50 000 euros, pas 5 000. Il a oublié un zéro quelque part. » Il est possible en effet qu’Yves ait mal compris la réponse de la société de prestation, à la faveur sans doute d’un biais de confirmation !

_____________________________

Merci à toutes les personnes qui ont participé au jeu ! Souhaitez-vous qu’on en prépare un autre sur une thématique différente ?

Introduction

Nous vous proposons une expérience interactive inédite ! 🤩

Voici un jeu dont vous serez l’illustre détective…

En 2024, l’ISTQB a publié une nouvelle version du syllabus sur le management des tests. Un document très riche en ressources, et dont les questions d’examen sont assez exigeantes. D’une durée de deux heures (contre une heure pour les examens de niveau Fondation et Spécialiste), l’examen propose des questions à 1, 2 ou 3 points.

La longueur des questions est parfois intimidante. De notre côté, nous les trouvons particulièrement bien faites : bien souvent, « trop » d’informations sont données, et il faut faire le tri pour trouver l’indice véritablement pertinent. Et ça, c’est tout à fait représentatif d’un quotidien de test manager !

Il y a quelques mois, nous vous proposions un QCM pour réviser les notions du syllabus ISTQB CTAL-TM (Certified Tester Advanced Level – Test Management). Ce genre de format de révision est pratique pour revoir rapidement les concepts. Toutefois, ces questions de révision ne donnent qu’un nombre assez limités d’informations sur le contexte, et ne ressemblent pas vraiment aux longues questions qu’on peut trouver lors de l’examen.

Pour compléter cette ressource, nous vous proposons donc aujourd’hui un jeu d’immersion !

Cette immersion se présente comme une boîte de réception fictive, dans laquelle vous trouverez des mails contenant des informations dispersées, utiles pour répondre aux questions.

Les réponses sont disponibles ici.

Et maintenant, place au jeu !

Contexte

Vous êtes test manager au sein de la société Tekmanyax. Hier soir, pendant votre promenade, vous avez senti une fleur mystérieuse. Son odeur capiteuse a troublé votre esprit, et vous avez perdu une bonne partie de vos souvenirs. Votre médecin traitant vous assure que les effets vont se dissiper en 24 heures. Elle vous recommande de poser un arrêt de travail, mais vous avez l’intuition qu’on va avoir particulièrement besoin de vous aujourd’hui, et que vous allez très bien vous en sortir même avec ces troubles de la mémoire. Vous vous dites même que ce serait l’occasion de porter un regard nouveau sur votre quotidien !

Vous arrivez au travail sans rien dire à personne au sujet de votre amnésie. Heureusement, vous avez toujours votre boîte de réception pour vous fournir des informations précieuses, et vous savez que le syllabus ISTQB CTAL-TM vous donnera les bonnes clés pour avancer dans la compréhension de votre contexte…

Pour découvrir la boîte de réception, 💌 cliquez ici !

À vos réponses ! Nous avons hâte de les lire 😀

Il est courant de confondre les notions de faux positifs, faux négatifs, vrais positifs et vrais négatifs.

Dans cet article, nous proposons quelques astuces pour bien s’en souvenir. Ces notions ne sont pas seulement utiles lors d’un examen ISTQB, mais aussi dans son quotidien de QA !

Positif ou négatif ?

Concentrons-nous d’abord sur la première partie de l’expression.

Un test positif, c’est un test qui déclare qu’il a trouvé quelque chose. Un test de grossesse positif déclare “Il y a un embryon”. Un test PCR positif déclare “Il y a un virus”. Et un test logiciel positif déclare “Il y a un bug” !

Plusieurs moyens mnémotechniques peuvent être utilisés.

Moyen mnémotechnique 1 : les couleurs

La première voyelle de “positif” est la même première voyelle que “rouge”.

La première voyelle de “négatif” est la même première voyelle que “vert”.

Quand on exécute un test logiciel et qu’on considère qu’il nous a permis de détecter un bug, on lui met un statut “KO”, qui s’affiche bien souvent avec une pastille rouge. Positif = rouge !

De même, quand on exécute un test et qu’on ne trouve rien, on le met en “OK”, et c’est à ce moment-là une pastille verte qui s’affiche. Négatif = vert.

Moyen mnémotechnique 2 : une présence… ou une “n’absence” ?

Un test Positif déclare la Présence d’un bug.

Un test Négatif déclare qu’il N’y a pas de bug.

Vrai ou faux ?

Aucun résultat de test, que ce soit un test médical ou logiciel, n’est fiable à 100 %.

Ainsi, un test “en rouge” l’est peut-être à tort.

Prenons un exemple.

Adèle se base sur une spécification pour écrire des tests pour une application mobile. Or, cette spécification a été mise à jour, mais personne ne lui a transmis la dernière version. Au moment où elle exécute les tests, 10 tests échouent. Ces tests sont donc positifs (en rouge). Plus tard, elle découvre que sur ces 10 tests échoués, 8 sont en réalité conformes à des règles de gestion présentes dans la nouvelle version de la spécification. Les 8 tests sont donc positifs (rouges) à tort ; ils donnent un résultat faux : ce sont de faux positifs.

Les 2 autres tests positifs (rouges) expriment en revanche de réels écarts entre le comportement observé et le comportement attendu. Ces 2 tests positifs (rouges) disent donc vrai : ce sont des vrais positifs.

Inversement, un test OK, un test négatif (vert), peut passer à côté d’un bug. C’est donc un négatif qui dit faux ; un faux négatif.

Et enfin, le dernier, c’est le test qui annonce une bonne nouvelle (vert, négatif), et qui a raison de le faire : le vrai négatif !

	Test en rouge	Test en vert
Il y a un défaut	Vrai positif	Faux négatif
Il n’y a pas de défaut	Faux positif	Vrai négatif

Conclusion

Nous espérons que vous y voyez plus clair dans ces expressions. On vous souhaite beaucoup de vrais négatifs !

Note : cet article a été mis à jour la dernière fois le 28 novembre 2025. Publication initiale : 12 décembre 2021.

_

Il y a quelques années encore, il était relativement difficile de recruter des QA, y compris au niveau junior. Aujourd’hui, le marché a évolué et est devenu bien plus concurrentiel. Les pratiques d’automatisation des tests ont gagné en maturité, la généralisation des usages de l’IA est passée par là également… les exigences sont désormais assez élevées et aucun coup de pouce ne doit être négligé pour se lancer !

Voici donc quelques pistes à l’usage des personnes qui aspirent à entrer dans le métier.

Dans cet article, nous employons le terme « QA » au sens générique du terme ; cela englobe beaucoup de dénominations particulières que l’on peut retrouver par ailleurs (testeuse / testeur, automaticien / automaticienne, analyste qualité, spécialiste en test logiciel, test manager, gestionnaire de la qualité, etc).

Sommaire

• Quelles sont les activités des QA ?
• Quels prérequis pour devenir QA ?
• Quels sont les outils des QA ?
• Quelles sont les formations pour devenir QA ?

Quelles sont les activités des QA ?

Que font les QA de leurs journées ? C’est la première question que nous vous proposons d’aborder, car c’est aussi grâce à ça que vous pourrez vous projeter au mieux dans cette nouvelle profession.

Il n’y a pas de réponse unique. Les activités de test varient d’une entreprise à l’autre et même d’un poste à l’autre. Cela dépend du type de projet, du mode de développement, du domaine métier et d’autres facteurs encore. N’oubliez pas l’un des 7 principes généraux du test : les tests dépendent du contexte !

Voici tout de même une liste de quelques tâches qui brossent, dans les grandes lignes, un schéma plausible du quotidien d’un grand nombre de QA.

L’exécution des tests manuels à partir d’un référentiel de tests

L’exécution des tests manuels est la partie la plus visible de l’iceberg du test. Selon les cas, elle représente 0 à 99% du temps de travail. Vous avez bien lu : 0%. C’est la première idée reçue à combattre sur le métier : on ne passe pas notre temps à cliquer sur des boutons en suivant minutieusement d’austères modes opératoires.

Quoi qu’il en soit ; quand cela se présente, les QA se trouvent devant une fiche de test (ou, bien plus souvent, devant un outil de gestion des tests) qui détaille un scénario de test à exécuter. Un scénario de test décrit d’une part les actions à réaliser, d’autre part les vérifications à effectuer.

Un exemple de cas de test : « Se rendre sur la page d’accueil et cliquer sur le bouton « En savoir plus ». Une popup doit s’ouvrir, dont le contenu doit être défilable verticalement mais pas horizontalement. »

Les QA lisent la fiche de test et exécutent le scénario indiqué. Si le logiciel fait ce qui est demandé, on signale et passe au test suivant. Sinon, on rédige un rapport d’anomalie en respectant le format en vigueur dans son organisation.

Le risque de s’ennuyer existe, car les tests sont souvent répétitifs. Mais il faudra plus que de la patience pour exceller en tant que QA : il faudra faire en sorte de toujours tester comme si c’était la première fois !

Si vous débutez, il est possible qu’on vous demande de suivre à la lettre les scénarios de tests du référentiel. Cependant, si le contexte vous le permet, n’hésitez pas à sortir des scénarios indiqués pour faire des tests en complément. Au fur et à mesure, vous allez « flairer » les bugs de mieux en mieux ! L’exécution des cas de tests est une activité qui peut être fastidieuse, mais qui sera d’autant plus efficace que vous vous autoriserez à être créatif.

À noter que l’exécution des tests manuels à partir d’un référentiel est l’une des activités de test les plus susceptibles d’être prises en charge, à terme, par l’intelligence artificielle. De nos jours, il serait périlleux d’orienter sa carrière uniquement sur cette activité. Toutefois, elle nécessitera toujours un regard humain pour s’assurer que les tests ont été correctement exécutés et que les anomalies créées ne sont pas des faux positifs.

La conception des tests

La conception des tests est l’activité qui permet de construire le référentiel de tests, qui est utilisé pendant l’exécution des tests.

Cette conception se fait à partir d’un cahier des charges ou de tout autre document décrivant comment un logiciel devra fonctionner (spécifications, user stories… ce qui constitue ce qu’on appelle la base de test). À partir de ces documents faisant autorité, on imagine des scénarios à exécuter. La rédaction de cas de test est bien souvent outillée, de manière à améliorer la productivité de cette activité.

Les QA, pendant la conception des tests, doivent garder à l’esprit le fait que le temps alloué à l’exécution des tests est limité. Il faut donc bien cibler l’effort de test sur les fonctionnalités qui demandent le plus de test. Cela nécessite d’avoir une vue d’ensemble sur le logiciel à tester, et de définir, seul ou le plus souvent en équipe, une véritable stratégie de test.

Les tests exhaustifs sont impossibles, mais des tests excessifs sont bel et bien possible ; c’est ce qu’on appelle la surqualité.

Tester, c’est un travail d’équilibre !

La conception des tests est, au même titre que l’exécution manuel des tests à partir d’un référentiel, une activité pouvant être en bonne partie prise en charge par l’intelligence artificielle. La valeur ajoutée principale le cas échéant est de savoir exprimer correctement le besoin en conception des tests, fournir une relecture rigoureuse de ce qui est produit par l’IA, et apporter les éléments manquants. La conception des tests est un travail intellectuel exigeant qui ne sera pas « remplacé » de sitôt, si tant est que l’on développe un esprit critique affuté.

La gestion des anomalies

Créer des rapports d’anomalies est une chose ; faire en sorte que les bugs soient corrigés en est une autre. Les QA ne déboguent pas, c’est-à-dire ne corrigent pas les bugs). Il doit donc les prioriser, les rendre faciles à reproduire, bref orchestrer au mieux le travail de correction. Ce travail se fait souvent en bonne intelligence avec d’autres acteurs du projet.

La gestion des anomalies est un travail effectué tout au long d’un projet ; la criticité, la priorité et les étapes de reproduction d’un bug peuvent évoluer au fil du temps. Il est important d’avoir toujours des informations fiables sur la qualité du logiciel.

Les QA doivent donner une visibilité sur les anomalies ouvertes. Il s’agit de créer notamment des rapports indiquant les informations importantes sur le nombre et la nature des anomalies ouvertes. Ces rapports sont très importants, car ils permettent de prendre des décisions impactant la vie du projet (changement de priorités, décalage de la mise en production du logiciel).

La gestion des anomalies est un travail de compromis entre ce qu’il faut corriger et ce qu’il faut laisser tel quel à court terme. Cette activité présente un certain nombre de pièges organisationnels à anticiper autant que possible.

Les tests exploratoires

Quand on parle d’exécution des tests, un référentiel formel de tests n’est pas toujours utilisé. La conception des tests a parfois lieu… en même temps que l’exécution ! On parle alors de test exploratoire, qui représente un sous-ensemble important de méthodes de test. Ces pratiques permettent de sonder les produits en profondeur en se basant sur des hypothèses et problématiques spécifiques (exemple : « nos internautes se plaignent du moteur de recherche ; passons 40 minutes à explorer à fond cette fonctionnalité »).

L’automatisation des tests

Ah, là on s’attaque à un gros morceau !

Jouer les tests à la main encore et encore, ça a un coût et ça prend du temps. En tant que QA, il vous sera peut-être (probablement !) demandé d’automatiser une partie de vos tests.

Concrètement, vous allez écrire des scripts qui, une fois lancés, vont exécuter, comme en imitant une vraie personne, le scénario au sein du logiciel à tester. Un petit exemple en vidéo ?

Cela demande encore une fois de mettre en place une stratégie : on ne peut pas tout automatiser. Pour cette activité, on vous demandera certainement des compétences techniques (souvent, des connaissances en développement orienté objet). Vous devrez aussi faire preuve d’esprit critique afin de mettre au mieux à profit ce temps d’automatisation.

L’automatisation des tests est un autre domaine où l’intelligence artificielle apporte beaucoup. Toutefois, attention à ne pas trop lui déléguer, sous peine de ne pas savoir réellement ce que font vos scripts. Prenez le réflexe de relire rigoureusement tout le code produit, de vous assurer que vous le comprenez et qu’il réalise bien ce dont vous avez besoin.

Le management des tests

Cette famille d’activités est plutôt prise en charge par des profils aguerris en test. Au sein du processus standard de test, elle comporte le pilotage et le contrôle des tests, la planification des tests et la clôture des tests. Elle nécessite aussi d’avoir une vue d’ensemble sur les activités de test au sein du projet, voire de l’organisation.

En bref : un métier polyvalent

Bien d’autres activités encore pourraient être évoquées. Le métier de QA est un métier largement polyvalent. Vous aurez parfois l’opportunité d’inventer, de modeler votre poste selon les besoins en qualité que vous identifierez. L’esprit d’initiative sera valorisé, et il vous faudra développer vous-mêmes des stratégies, des tactiques et des astuces pour vous adapter à un grand nombre de situations ! Cela sera d’autant plus vrai dans les équipes agiles.

Ci-dessous, à titre d’exemple, voici la répartition du temps d’un QA sur une de nos dernières missions. Ce n’est pas un exemple à suivre absolument, simplement une illustration parmi d’autres de ce qu’il est possible de vivre dans le monde du test.

Pour finir, rien de tel que d’échanger avec d’autres QA pour se rendre compte des multiples facettes du métier ! Et pour ce faire, nous conseillons de rejoindre le groupe LinkedIn « Le métier du test ».

Quels prérequis pour devenir QA ?

Compétences professionnelles

Disposer d’une formation en informatique, que ce soit en formation initiale ou continue, paraît aujourd’hui indispensable, alors que c’était moins le cas il y a quelques années. Au cours de votre formation, il est très probable que vous passiez une ou plusieurs certifications, qui vous aideront à trouver votre premier emploi dans le test.

Savoir-être

Outre les compétences professionnelles propres au métier du test lui-même, les qualités ci-dessous sont également recherchées :

• Rigueur
• Curiosité
• Adaptabilité
• Aisance relationnelle
  • Diplomatie
  • Humilité
  • Assertivité…
• Goût pour l’apprentissage continu
• Aisance rédactionnelle

Le contexte est important et les compétences et qualités requises dépendront d’un environnement à l’autre !

Authentique motivation

Pour vous épanouir dans cette carrière, il est avant tout important… d’en avoir envie ! A noter tout de même que beaucoup de QA le sont devenus « par hasard » et ne le regrettent pas. Ce choix de carrière est tout à fait pertinent dans une démarche de reconversion. Un passé dans la biologie, la comptabilité, l’enseignement, la traduction… ne peut être qu’un atout dans ce métier. Premièrement, parce que votre expertise peut vous être directement utile (connaissance fonctionnelle de l’applicatif à tester). Deuxièmement, parce qu’en tant qu’« outsider », vous porterez un regard neuf sur les process, les produits et tout ce qui gravite autour. Et cette prise de recul est bénéfique à toute entreprise !

Les outils des QA

C’est une question récurrente, surtout de la part des étudiants. Pour maîtriser le métier du test, il est important d’en maîtriser les outils principaux. Toutefois, nul besoin de suivre tous les cours en ligne de tous les outils de test les plus utilisés ! Maîtriser un outil de chaque type vous donnera suffisamment d’aisance pour pouvoir évoluer et en maîtriser d’autres par la suite.

Les outils de gestion des tests

Peut-on organiser une campagne de test sur un fichier Excel ? Ce n’est sans doute pas impossible, mais nous conseillons d’utiliser plutôt un outil optimisé pour cet usage. Les outils de gestion des tests permettent de concevoir les tests, de les rédiger, de les maintenir, d’organiser les campagnes de test (qui fait quoi ?), de suivre les résultats de celles-ci et, souvent, de générer des rapports.

Chez Hightest, nous sommes fans de Squash TM, un outil français (cocorico !), open source et simple d’utilisation. Si vous découvrez l’outil, nous vous conseillons de vous penchez sur ces quelques bonnes pratiques.

Les outils d’automatisation des tests

Difficile de citer ne serait-ce que tous les différents types de tests qui peuvent être automatisés ! Toutefois, lorsqu’on parle de « tests automatisés », il est souvent question de tests fonctionnels dynamiques automatisés ; c’est-à-dire d’automates qui vont parcourir l’applicatif comme s’ils étaient des utilisateurs, réaliser des parcours clients, vérifier ce qui est affichés sur l’écran à l’issue d’une transaction, etc.

Il existe cependant beaucoup d’autres outils de tests automatiques : des scans de vulnérabilité, des outils de scripting de tests de performance, de charge, de stress, des outils permettant d’identifier les problèmes d’accessibilité, des plateformes permettant de mesurer la qualité d’un code source…

Chez Hightest, nous utilisons toutes sortes d’outils de tests automatisés ; cela dépend notamment du contexte, du besoin et des acteurs impliqués dans la démarche d’automatisation des tests.

Bien que l’ensemble des QA ne fassent pas d’automatisation, nous ne pouvons que vous encourager à découvrir cette importante facette du métier.

Les outils transverses

Beaucoup d’outils qui ne sont pas spécifiquement des outils de test pourront vous être utiles. Pensez à toutes les tâches transverses que vous devrez effectuer :

• reporting
• brainstorming
• rédaction, synthèses
• communication interne, voire externe
• gestion du temps, gestion de la productivité
• prise de notes

Nous vous invitons à rester en veille sur les outils transverses (notamment les plugins de navigateur si vous testez des sites web) qui pourraient vous aider dans vos multiples tâches de QA.

Et surtout…

Un seul outil vous manque, et tous les autres ne servent à rien. Il s’agit d’un freeware que tout le monde a sur soi ! C’est notre capacité d’attention et de réflexion. Si vous abordez chaque projet de test avec un regard neuf, que vous posez toutes les questions qui vous viennent, et que vous gardez toujours à l’esprit les enjeux réels de votre activité de test, vous aurez avec vous le meilleur outil de la place.

Les formations

Si les activités que nous avons citées vous ont fait envie, voici quelques pistes pour vous préparer avant de candidater à un poste de QA junior.

Les formations universitaires

Note du 28/11/2025 : cette section n’a pas encore été entièrement mise à jour.

Il est important de noter qu’à l’heure actuelle, sur le territoire français, l’offre de formation universitaire en test logiciel est peu fournie.

Licence professionnelle Test et Qualité Logicielle (LP-TQL)

Proposée par l’IUT de Laval, cette formation est accessible à niveau bac +2 (filières informatiques ou scientifiques), en formation initiale, continue ou VAE. Elle existe depuis 2009 et accueille une trentaine de personnes par an. Classiquement, à l’issue de cette formation, les personnes l’ayant suivie rejoignent le monde du travail sans besoin de passer par la case master.

16 semaines de stages sont obligatoires (+ 150 heures de projet tuteuré), à moins que vous ne choisissiez d’augmenter ce nombre en optant pour l’alternance.

Merci à Lahcen Ouhbassi, responsable de cette formation, d’avoir répondu à nos questions.

Master Ingénierie du Test et de la Validation Logiciels et Systèmes (ITVL)

Le master ITVL, proposé par Polytech Angers (anciennement ISTIA) en collaboration avec l’Université de Franche-Comté, offre un cursus de deux ans comprenant un stage de 6 mois, 50 heures de projet et le passage de plusieurs certifications reconnues (dont ISTQB et IREB).

Ce master est ouvert uniquement en formation continue. Il se déroule 75% à distance et 25% en présentiel, à Angers. Les promotions oscillent pour l’instant entre 8 et 10 personnes par promotion, mais la formation pourrait à l’avenir accueillir davantage de personnes (pour un total de 16 à 18 étudiants). La formation en est à sa troisième promotion en 2019, et à ce jour le taux d’obtention du diplôme est de 100 %. A l’issue de cette formation, la très grande majorité des personnes ont obtenu des évolutions importantes de poste, soit dans la même entreprise, soit dans une autre entreprise. Deux personnes ayant suivi la formation se sont mises à leur compte.

Pour ce qui est du processus d’entrée, les responsables de la formation organisent un entretien individuel pour comprendre les motivations du projet professionnel du candidat ainsi que ses compétences, son expérience métier et son niveau d’études – en relation ou non avec le métier. L’éventuelle prise en charge financière par l’entreprise est également évoquée, de même que l’organisation de cette formation et le travail à fournir pendant les 2 années. Suite à cet entretien, les responsables de la formation expriment leur avis sur cette candidature et la personne postule ou non à la formation.

Merci à Alexis Todoskoff, responsable de cette formation, de nous avoir communiqué ces éléments.

Les formations éligibles au CPF

Si vous êtes en poste, il vous est peut-être possible d’utiliser votre CPF pour bénéficier d’une formation au test logiciel. Si celle-ci prépare à passer la certification ISTQB de niveau Fondation, cela pourra donner un vrai plus à votre CV. En tant que QA qui débute, vous devez savoir que les certifications ISTQB, s’ils ne sont pas obligatoires pour trouver un emploi, sont tout de même une excellente manière de montrer patte blanche dans le monde du test !

Comme elles sont assez nombreuses et que leur liste est amenée à fluctuer, nous ne listerons pas ici l’ensemble des établissements proposant ces formations.

La POE

La POE (Préparation Opérationnelle à l’Emploi, aussi appelée POEIC pour « individuelle et collective ») est un dispositif permettant d’acquérir une formation professionnalisante avec un emploi à la clé. Elle est particulièrement intéressante pour les entreprises recherchant des profils rares, et les QA avec de l’expérience sont en effet très recherchés.

L’auto-formation

Des MOOCs en français sur le test logiciel ? Il y en a quelques-uns sur la plateform OpenClassroms. Des MOOCs en anglais abondent également sur plusieurs plateformes.

Pensez aussi à Test Automation University, une plateforme qui contient notamment des cours débutants en automatisation. Si vous partez de zéro, ce site vous aidera à acquérir de précieuses notions ! Pour en savoir plus, jetez un oeil à l’article que nous avons écrit sur cette plateforme.

A noter qu’il est possible de passer la certification ISTQB en candidat libre ; voir la liste des prochaines sessions. Il est également possible de passer l’examen en distanciel. À ce jour, la plupart des certifications sont d’ailleurs passées en distanciel, avec un système de surveillance à distance.

Un autre axe, non certifiant, mais qui permet de faire un premier pas dans le métier, est le crowdtesting. Même si cela ne vous occupera pas forcément à plein temps, l’expérience acquise peut être très riche et valorisante. Vous serez en contact avec un nombre important d’applications dans des domaines différents, ce qui représente autant d’opportunités de monter en compétences. Nous vous encourageons à découvrir Testeum, qui vous permettra de vous initier à cette activité.

Conclusion

Beaucoup de routes mènent au test, et vous trouverez la vôtre si tel est votre ambition !

Pour poursuivre votre lecture, nous vous conseillons les ressources suivantes :

• Nos conseils pour réussir son premier entretien d’embauche en tant que QA (On croise les doigts pour vous 🍀)
• Une sélection de témoignages de personnes travaillant dans le test après une carrière dans un domaine très différent.

Faut-il se certifier pour construire une belle carrière dans le test logiciel ? Pas forcément. Est-ce qu’on le recommande ? Si vous le pouvez, oui ! Dans cet article, nous faisons le point sur les (bonnes) raisons de se certifier, et vous offrons quelques conseils pour faire des certifications des atouts riches de sens, plutôt que de simples documents administratifs !

Pourquoi (continuer de) se certifier ?

Depuis de nombreuses années, en France, la plupart des nouvelles personnes qui arrivent dans le monde du test logiciel suite à un dispositif de reconversion passent une, voire plusieurs certifications via leur organisme de formation. C’est une bonne chose, car cela assure un socle commun, une compréhension qui leur permet de maîtriser certaines notions essentielles. La certification ISTQB Fondation est la plus couramment présentée comme une sorte de passeport pour Testland.

Toutefois, une fois le premier emploi décroché, continuer de se certifier apporte un grand nombre de bénéfices. En voici quelques-uns !

1. Se démarquer sur le marché de l’emploi 🏅

Tout d’abord, d’un point de vue purement pratique, le marché de l’emploi du test tend à devenir plus concurrentiel. Les certifications permettent de rendre un profil plus attractif en y apportant un capital symbolique, c’est-à-dire une reconnaissance légitime et facilement reconnaissable. Elles agissent comme un signal auprès des personnes qui doivent parcourir de nombreux CV, surtout s’il s’agit de certifications réputées comme étant difficiles à obtenir.

Les certifications permettent aussi d’acter certaines spécialisations. Par exemple, une personne travaillant comme testeuse « généraliste » et détenant à la fois de l’expérience en tests de performance ET une certification portant sur ce type de test, rend visible cette appétence. Elle augmente ses chances d’être recrutée en tant que spécialiste en tests de performances.

2. Maintenir une habitude d’apprentissage 🧠

Si vous êtes en poste, il peut arriver de traverser des périodes où vous ne développez plus de nouvelles connaissances et compétences. Ce n’est pas grave en soi et c’est même assez courant. Faire de la veille et essayer de nouveaux outils sont de bonnes idées pour se tenir à jour, mais ces habitudes se retrouvent souvent enterrées sous le fourbi des autres activités « prioritaires ». Avoir en ligne de mire le passage d’une certification motive à dégager des plages de temps pour apprendre. Implémenter cette habitude au plus tôt dans sa carrière aide à garder un état d’esprit d’apprentissage constant !

3. Apprivoiser les situations stressantes 💥

Passer une certification est un moment susceptible de provoquer un panel d’émotions pas toujours des plus agréables au premier abord. Elles peuvent rappeler d’autres moments stressants de son parcours professionnel : examens de fin d’études, entretiens d’embauche… La différence importante, c’est qu’il y a souvent beaucoup moins d’enjeux. Typiquement, si vous ratez une certification, vous pouvez en général la passer de nouveau quelques jours plus tard.

Provoquer une exposition graduée à ce genre de situation permet à terme de les apprivoiser. Il est possible même que cela vous donne envie de les rechercher. Vous connaissez l’expression galvaudée « sortir de sa zone de confort » ; d’année en année, vous soumettre à des situations de stress contrôlées a plutôt tendance à élargir cette zone de confort, et à rendre ce stress synonyme de croissance et de progression.

Nos conseils

Créer un plan de vol précis

Quelle forme souhaitez-vous donner à votre carrière ? Qu’est-ce qui vous fait le plus vibrer : développer une spécialité en particulier, ou cultiver un profil touche-à-tout ?

Si vous souhaitez vous spécialiser, il existe des dizaines de certifications utiles au métier du test. Réfléchissez à ce qui vous plaît, à ce qui vous intéresse ; il y a certainement une ou plusieurs certifications qui peuvent vous accompagner dans cette voie. D’ailleurs, il est possible que votre prochaine certification utile ne soit pas forcément une certification orientée vers le test !

Par exemple, si les tests d’utilisabilité vous passionnent, des certifications spécifiques à l’UX peuvent être la piste pertinente à suivre.

Si vous souhaitez développer un profil généraliste, il est évidemment possible de « piocher » des certifications qui ne soient pas centrées vers le même objectif. Exercez-vous cependant à créer un fil rouge entre toutes ces certifications ; pourquoi les avez-vous choisies, celles-là en particulier ? Cela donnera davantage de cohérence à votre profil.

En parler à votre organisation

Selon l’organisation où vous travaillez, votre direction n’est pas forcément au courant de toutes les certifications qui existent ainsi que de leur utilité. Vous pouvez les sensibiliser, non seulement pour pouvoir passer vous-mêmes des certifications, mais aussi pour construire une approche plus globale qui pourra profiter à toute votre équipe.

Privilégier les certifications récemment mises à jour

La thématique d’une certification est évidemment importante, mais regardez aussi de quand date son contenu. Certains domaines, comme l’intelligence artificielle, évoluent très rapidement ces dernières années. Même si la plupart des certifications sont valables « à vie », cette caractéristique ne doit pas cacher le fait que les contenus peuvent devenir obsolètes ou incomplets.

Rester humble

C’est une évidence mais il faut le rappeler : une certification seule ne garantit pas l’expertise. Quand on découvre un domaine par le simple biais de supports théoriques associés à une certification, on peut avoir l’impression que le domaine est plus simple qu’il ne l’est réellement. Cette tendance, en tant que novice, à surévaluer ses compétences, s’appelle l’effet Dunning-Kruger.

Pour vous en prémunir, lisez attentivement le contenu d’une certification : vous remarquerez souvent une grande variété de sources et de pistes à explorer. Même une fois votre certification obtenue, il vous reste énormément de choses à étudier et à maîtriser pour justifier d’une véritable expertise.

C’est d’ailleurs assez paradoxal : dans une logique parfaite, on ne passerait de certifications que pour formaliser une compétence préexistante, alors qu’il peut arriver qu’on commence par la certification (et donc la reconnaissance sociale) avant d’avoir réellement pratiqué. Ce qui nous amène au conseil suivant…

Varier les approches

Quand vous étudiez un sujet en vue de passer une certification, complétez les enseignements du syllabus par des recherches personnelles. Cela vous permettra de développer une vision d’ensemble du sujet et de le contextualiser avec des exemples pratiques.

Ancrer les connaissances sur la durée

Pendant vos études, vous avez peut-être remarqué que ce que vous connaissiez quasiment par cœur à un moment donné, vous l’aviez oublié l’année d’après. La courbe de l’oubli a tôt fait de catapulter les connaissances dans le néant. Le risque ici, c’est de détenir une certification valable à vie… et de ne plus pouvoir s’en souvenir quelques mois plus tard !

Mobiliser régulièrement les connaissances acquises permet de les mémoriser durablement. Se forcer à relire régulièrement les documents de la certifications n’est pas forcément l’approche la plus efficace, ni la plus simple à mettre en œuvre. Utiliser un outil d’organisation des connaissances, comme Obsidian, peut être plus adapté pour assimiler durablement ce qu’on apprend.

Voici une capture d’écran du graphe Obsidian d’une des collaboratrices d’Hightest. Les notes prises lors des révisions de la certification ISTQB CTAL-TM (Management des Tests) sont éclatées en notes atomiques, chaque note étant consacrée à un concept précis. Elle a obtenu cette certification il y a des mois, mais peut rapidement mobiliser ces connaissances car elles sont intégrées à un ensemble de connaissances plus larges, et propre à son parcours spécifique.

Quelques ressources en libre accès

Qui dit certification dit entraînement… En plus de nos formations en présentiel, nous proposons en libre accès des questions de révision pour quelques certifications.

ISTQB GenAI – Tester avec l’IA générative

Notre dernier quiz porte sur la certification ISTQB GenAI. Le contenu du syllabus offre quelques bases théoriques pour comprendre le fonctionnement de l’IA, et une palette importante d’application de l’IA génératives dans la pratique des activités de test.

Nous pensons que cette certification va rapidement s’imposer et peut-être avoir un succès comparable à la certification ISTQB Fondation.

Pour vous entraîner sur ISTQB GenAI

ISTQB CTAL-TM – La certification de niveau avancé pour le management des tests

Attention, pour passer cette certification il est nécessaire de détenir la certification ISTQB Fondation.

Au niveau Fondation, les 7 activités principales du processus de test standard sont abordées ; avec la certification CTAL-TM, on se concentre sur 3 d’entre elles qui concernent spécifiquement le management des tests. Le pilotage et le contrôle des tests, la planification des tests et la clôture des tests sont ainsi approfondis.

Cette certification est particulièrement intéressante, car elle permet de comprendre la véritable portée de l’un des 7 principes généraux des tests : « Les tests dépendent du contexte » !

Pour vous entraîner sur ISTQB CTAL-TM

TMMi Professional

Cette certification n’est pas une certification ISTQB. Toutefois, les dialogues sont nombreux entre l’univers TMMi et ISTQB, et TMMi Professional est une certification qui complète parfaitement un bagage ISTQB. Inversement, pour pouvoir prétendre à des certifications supérieures de TMMi, certaines certifications ISTQB sont requises !

TMMi Professional aborde la gestion du processus de test à l’échelle de l’organisation, quand la certification CTAL-TM est plutôt pensée à l’échelle du projet ou du produit.

Pour vous entraîner sur TMMi Professional

Conclusion

Les certifications ne sont pas une fin, mais un outil puissant pour vous aider à progresser dans vos compétences, vos connaissances et votre carrière. À vous de vous approprier cet outil et de lui donner le maximum de sens !

Mettre en place une politique de test est une étape importante dans la vie d’une entreprise concernée par la qualité logicielle. Toutefois, il existe peu de ressources qui expliquent concrètement comment procéder. Au travers de ce retour d’expérience, nous souhaitons proposer un exemple, à reprendre et adapter. 

Mais pour commencer, faisons un rappel de vocabulaire ! 

Qu’est-ce qu’une politique de test ? 

La politique de test est un document qui vise à orchestrer la gestion des tests d’une organisation. Le glossaire CFTL/ISTQB (dont vous pouvez retrouver le contenu ici) la définit ainsi : 

Un document de haut niveau décrivant les principes, l’approche et les principaux objectifs de l’organisation en matière de tests. 

C’est un document qui peut être très concis, tant qu’il répond correctement à ces questions élémentaires : 

• « Pourquoi teste-t-on ? » 

• « Qu’est-ce qui est important quand on teste ? » 

À l’inverse, ce document ne contient d’éléments temporels ou de bas niveau. Par exemple, si vous voulez lister les outils de test préconisés par l’entreprise, ce n’est pas dans la politique de test qu’il convient de le faire ! 

De la politique de test vont découler les autres documents importants qui concernent les tests : 

• la ou les stratégies de test 

• les différents plans de test 

La politique de test est en général unique au sein d’une entreprise.

La mise en œuvre d’une politique de test est préconisée par TMMi aussi bien que par l’ISTQB. 

Une ressource méconnue 

Cela étant dit, regardons les choses en face : quelle minime pourcentage d’organisations possède effectivement une politique de test ? Et celles qui en ont une l’utilisent-elles vraiment ?

Marc Hage Chahine témoignait ainsi en 2021, dans un très bon article de La Taverne du Testeur : 

Je vais être honnête, je n’ai jamais connu, dans aucune de mes missions à ce jour, de politique de test. 

Chez Hightest, nous avons pu faire le même constat. Se pose alors la question… 

Pourquoi réhabiliter la politique de test ? 

Car en effet, on peut faire de très bons tests dans une organisation qui n’a pas de politique de test. 

Toutefois, la politique de test est un symbole fort. Elle atteste du fait que la direction de l’organisation se soucie de la qualité logicielle et la traite comme un levier de performance à part entière. Elle permet de faire de lien entre la raison d’être de l’organisation, et la pratique (parfois inconnue des hautes couches de la hiérarchie) des tests logiciels. Bref, de mettre en lumière ce qui est souvent invisible ! 

En découlent deux effets. 

La politique de test symbolise un engagement 

Si une organisation déclare faire du test un sujet important, alors elle doit aligner les moyens nécessaires à leur bonne mise en œuvre.

Mettons qu’une entreprise ait un comité de direction très sensible aux tests. Des moyens sont fournis année après année. Mais un jour, le comité de direction change du tout au tout, et compte désormais des personnes peu renseignées sur le test. La politique de test est la porte d’entrée qui permet de comprendre la logique de ce qui se pratique concrètement. Elle fait le lien entre ce qui intéresse vraiment la nouvelle direction, et les pratiques concrètes de test que l’on va retrouver dans d’autres documents (stratégie de test, plans de test maître, plans de test de niveau…) En l’absence de politique de test, le sujet restera peut-être trop obscur au yeux du nouveau comité. Les moyens qui seront alloués au test déclineront peut-être.

La politique de test aide à mieux tester 

Toutes les activités de test doivent découler de la politique de test : il y a une recherche de cohérence, ce qui est déjà un début d’harmonisation des pratiques. 

Mettons qu’une autre entreprise possède une stratégie de test et un respectable troupeau de plans de test en tous genres. En l’absence d’une politique de test qui récapitule les véritables enjeux du test, une nouvelle recrue pourrait se sentir un peu perdue, et tester sans vraiment comprendre ce qu’on attend d’elle, l’intention du test dans cette entreprise. C’est un peu comme si on enlevait les nuances d’une partition ! 

On comprend donc bien pourquoi TMMi insiste sur l’importance de mettre en place, en tout premier lieu, une politique de test. Celle-ci doit être validée par la direction de l’organisation, être dûment diffusée, et périodiquement révisée. 

When an organization wants to improve its test process, it should first clearly define a test policy.

(TMMi v 1.3, p. 24. C’est nous qui mettons en italique.) 

Mais alors, comment faire une politique de test ? 

C’est le moment de faire notre REX ! 

Dernièrement, nous avons animé une démarche de création de politique de test avec l’une de nos sociétés clientes. Voici comment nous avons procédé.

Sensibilisation du personnel 

Tout d’abord, il est à noter que cet atelier s’inscrivait dans une démarche globale visant à améliorer les pratiques de test de l’entreprise. En amont de la planification de la réunion, nous avions en effet mené un état des lieux des pratiques de test de cette société. Lors de la restitution, nous avions notamment expliqué la nécessité de partager une même vision, et pour ce faire, que la société se dote d’une politique de test. 

Il est essentiel de donner du sens à cet exercice, sous peine de se retrouver avec un document qui sonne creux. 

Mobilisation de personnel concerné par les tests 

Afin de réaliser cette politique de test, nous avons identifié des personnes clés, fortement impliquées dans les tests. Nous avons ajusté la forme de l’atelier en fonction du nombre d’individus ayant accepté l’invitation, afin de garantir des échanges à la fois fluides et riches. 

Collecte des valeurs de la société 

En amont de la réunion, nous avons demandé à ce qu’on nous transmette des documents résumant les valeurs de la société. Nous avons « ratissé large » afin d’avoir le plus de matière possible. Ceci pouvant inclure : 

• Des livrets d’accueil distribués aux nouvelles recrues 

• Des publicités orientées vers la clientèle 

• Des présentations globales de l’entreprise 

• Tout autre document de haut niveau reflétant l’entreprise et ses valeurs 

Cette étape nous paraissait indispensable. Nous avons d’ailleurs décalé une première fois l’atelier, ayant collecté trop peu de documents pour avoir une vision suffisamment précise des valeurs de l’organisation. 

Pour un peu plus de contexte, cette organisation étant complexe, plusieurs « systèmes de valeurs » y coexistent, ce qui a conduit à une liste d’une dizaine de valeurs. 

Préparation de l’atelier 

Une partie du groupe de travail se situant dans une autre zone géographique, il était important d’inclure tout le monde en proposant un atelier au format numérique. C’est ainsi que nous avons prévu, au lieu de traditionnels post-its, un atelier sur l’outil Draft.io. 

À noter que cet outil est gratuit pour une utilisation légère ; au-delà d’un certain nombre d’éléments créés, il est nécessaire de prendre un abonnement. 

En amont de la session, nous avons créé un tableau blanc dans Draft.io. Dans ce tableau, chacune des valeurs identifiées possède une colonne.

Nous avons également prévu (en bleu sur le schéma) des postits vierges, à disposition des membres de l’équipe le jour J.

Animation de l’atelier

Le jour de l’atelier, nous avons eu soin de réexpliquer les enjeux de la politique de test, et avons utilisé une variante du Bingo des Recettes à la Noix pour briser la glace et aider les personnes à rassembler des souvenirs, bons ou mauvais, relatifs à la qualité logicielle.

Après cela, le tableau blanc a été passé en revu et rempli d’idées. Il était initialement prévu de laisser les personnes remplir les post-its elles-mêmes sur leur PC ; l’ambiance étant plutôt à l’échange à bâtons rompus, nous avons proposé de plutôt prendre le rôle de scribe tandis que les personnes discutaient ensemble à l’oral au sujet des différentes colonnes.

Cet atelier a duré une heure et demie.

Synthèse suite à l’atelier

Pour la suite, nous avons proposé deux choix aux personnes ayant participé à l’atelier :

• Organiser un autre atelier pour synthétiser les idées
• Organiser une réunion de revue de la politique de test, proposée par nous suite à un travail de synthèse de notre côté.

C’est la deuxième solution qui a été retenue.

Nous avons donc passé en revue toutes les idées et créé un document très concis (une page A4) les regroupant.

Les idées non retenues pour le document :

• Les idées d’applications très spécifiques (exemple : l’utilisation de tel ou tel outil)
• Celles qui nécessiteraient des décisions nouvelles (exemple : organiser un recueil systématique des opinions de la population utilisatrice)
• Celles qui coulaient de source (exemple : tenir compte du décalage horaire quand on s’adresse à des personnes d’autres zones géographiques)

Nous avons également procédé à une synthèse des valeurs, afin de n’en conserver que 3 : ambition, solidarité et efficacité. Elles permettent de classer les idées ayant émergé, tout en fournissant un rappel des valeurs initiales.

Réunion de revue de la politique de test

Une fois ce travail de synthèse terminé, une nouvelle réunion a eu lieu afin de revoir ensemble le brouillon. Nous avons réalisé quelques changements et ajouté 2 items. La politique de test est désormais prête, mais l’aventure n’est pas finie !

La politique de test… et après ?

La prochaine étape est de faire valider officiellement la politique de test par la direction de l’entreprise.

NB : idéalement, il aurait fallu que la direction prenne part directement aux ateliers, mais cela n’était pas envisageable pour des raisons d’organisation.

L’étape finale, et non des moindres : la diffusion ! Divers canaux sont envisageables, tous étant cumulables :

• Diffusion initiale par mail
• Mise à disposition pérenne via l’intranet de l’entreprise
• Distribution à chaque nouvelle recrue impliquée dans les activités de test
• Affichage physique dans des lieux appropriés

Il faudra également songer à revoir périodiquement cette politique de test. Il est important que ce document évolue au rythme de l’organisation. Ainsi, il continuera de donner du sens aux activités de test au fil du temps.

Conclusion

La politique de test n’est pas un document qui s’improvise. Comme il engage l’organisation dans une démarche de qualité logicielle, il est essentiel qu’il soit coécrit par des personnes à la fois représentatives, impliquées et influentes.

Sa forme finale n’a pas besoin d’être imposante : inutile d’écrire un épais document. Bien au contraire, une politique de test concise a beaucoup plus de chances d’être bien assimilée par toutes les parties prenantes.

Encore une fois, notre retour d’expérience n’est pas un exemple « parfait », mais une possibilité dont vous pouvez vous inspirer.

Et vous, avez-vous des expériences de mise en place de politique de test à partager ?

Nous vous conseillons de compléter cette lecture avec celle d’un autre article de la Taverne du Testeur. Vous y trouverez quelques exemples de politiques de test actionnables et qui ne prendront pas la poussière !