4 clés pour réussir son premier entretien d’embauche de testeur

Dans un précédent article, nous vous donnions des pistes pour vous aider à devenir testeur logiciel. Vous avez désormais obtenu un premier entretien d’embauche et votre nouvelle carrière de QA vous tend les bras : félicitations ! Problème : le syndrome de l’imposteur vous guette, et vous redoutez que l’entreprise ne vous retienne pas. Pas de panique, dans cet article on partage avec vous quelques astuces pour que ce moment se passe bien. Mettez toutes les chances de votre côté !

#1 – Partagez votre enthousiasme

Beaucoup de personnes découvrent le test par hasard, par exemple suite à un entretien avec des conseillers Pôle Emploi. Il n’y a aucun mal à ça, le métier est encore relativement méconnu et tous les moyens sont bons pour le faire connaître ! Merci d’ailleurs, au passage, aux personnes qui, sans l’exercer, font connaître ce beau métier.

Toutefois, si vous êtes dans ce cas, il est important que votre discours dépasse cette dimension “hasard de la vie”. Sans cela, votre interlocuteur se demandera, à juste titre, si vous avez choisi le test logiciel par envie ou par dépit.

  • Qu’est-ce qui fait qu’aujourd’hui, vous avez envie de faire du test ?
  • Cette activité vous plaît-elle authentiquement ?
  • Si oui, quelles sont les activités ou les situations précises qui vous font le plus vibrer ?

Vous aurez beau être authentique dans votre motivation, ce qui va compter avant tout c’est de l’exprimer d’une façon que votre recruteur puisse vous croire.

Plus vous serez spécifique et plus vous paraîtrez authentique. 

Par exemple, “Je veux devenir QA car ça me plaît d’améliorer la qualité des logiciels” sonne un peu fade. “J’adore constater qu’un des bugs que j’ai découverts a été parfaitement corrigé”, ou encore “Ca me fait pétiller le cerveau de rechercher la petite configuration qui provoquera une défaillance” c’est tout de suite plus savoureux !

Si vous montrez votre motivation et que celle-ci est sincère, votre enthousiasme aura toutes les chances de gagner votre interlocuteur.

#2 – Assumez toutes les cordes à votre arc

Vous avez un passé de littéraire ? De comptable ? De biologiste ? De prof ? De standardiste ? De cuistot ? De parent au foyer ?

Félicitations, vous faites donc partie de l’écrasante majorité de personnes qui ont débuté leur carrière autrement que dans le test logiciel. Vous avez tout à gagner à assumer pleinement vos expériences passées. Elles ont façonné chez vous un certain regard sur le monde, des exigences qui vous sont propres, une manière d’apprendre, de vous organiser, de communiquer.

C’est une richesse et il est important que vous en preniez conscience !

Vous gagnerez à expliquer à votre interlocuteur les ponts qui existent entre les différentes expériences et disciplines qui jalonnent votre carrière, et le métier du test. Dans le prochain article, nous donnerons la parole à une myriade de QA aux parcours extrêmement variés, qui vous parleront des apports de leurs premières disciplines. Préparez-vous !

#3 – Démontrez vos qualités de testeur

Emna Ayadi, spécialiste en test logiciel, a mis en lumière 4 catégories de compétences indispensables aux testeurs du XXIème siècle (les 4C) :

  • Esprit critique
  • Collaboration
  • Communication
  • Créativité

Même si vous débutez dans le monde de la qualité logicielle, vous avez déjà certainement des “success stories” à partager en rapport avec ces soft kills, que ce soit dans votre passé étudiant, professionnel, associatif, ou de loisirs.

En lien avec les qualités citées ci-dessus, illustrez celles dans lesquelles vous vous reconnaissez le plus par des actions que vous avez pu mener précédemment.

#4 – Faites part de votre curiosité

La curiosité est une qualité extrêmement valorisée dans le monde de la qualité logicielle. C’est normal ; vous allez devoir vous intéresser à des domaines fonctionnels que vous ne maîtrisez pas encore, faire l’effort d’aller dans le détail, apprendre à utiliser des outils qui changeront d’année en année…

Et le hack, c’est que la curiosité s’appuie justement sur ce qui, en tant que débutant, peut aujourd’hui vous faire peur : le fait de ne pas tout savoir !

Au cours de l’entretien, faire part d’éléments précis qui éveillent votre curiosité permettra à votre interlocuteur d’en savoir davantage sur votre motivation et ce sur quoi votre profil tend. Encore une fois, plus vous serez spécifique, plus vous irez loin dans les questions, et plus vous aurez de l’impact. Un exercice possible est de préparer une question, et de trouver une question supplémentaire pour l’approfondir. Par exemple, après avoir posé la question “Quels outils utilisez-vous ?”, vous pouvez aller plus loin : “Selon quels critères les avez-vous choisis ?”

Ou encore, après la question “Combien de personnes constituent l’équipe de test ?”, demander “Quel ratio visez-vous entre les devs et les QA ?”.

Une curiosité sincère démontre également, sans qu’il y ait besoin de le formaliser ou de forcer le trait, une certaine humilité.

Développer une attitude de curiosité est donc “tout benef”, lors de l’entretien mais aussi tout au long de votre parcours… que nous espérons riche en succès !

D’autres ressources pour aller plus loin

Cet article s’adresse aux testeurs débutants, qui veulent décrocher leur tout premier poste de testeur. Il existe cependant d’autres articles que nous vous conseillons de lire également, même s’ils ne se focalisent pas sur le cas particulier de la première embauche. Nous souhaitons partager avec vous deux d’entre eux :

Il ne nous reste plus qu’à vous souhaiter un entretien agréable et enrichissant. Tirez-en le maximum, et n’oubliez pas qu’une réponse négative ne signifie pas que l’histoire est terminée ! Si le courant est passé, gardez contact ; cela pourra mener, quelques années plus tard, à de belles collaborations. You never know!

Tests non fonctionnels : quelques ressources pour vous lancer

« Les compères dans leur Fiat font sécher leurs mains en utilisant les portes. »

Qu’est-ce que c’est ? Une formule magique ? Une chaîne aléatoire générée par une IA ? Un extrait de chanson absurde ?

Rien de tout ça : c’est notre moyen mnémotechnique pour se souvenir des 8 aspects de la qualité logicielle définis par ISO 25010 !

Les com(patibilité)per(formance)es dans leur Fia(bilité)t fon(ctionnalité)t sec(urité)her leurs main(tenabilité)s en utilisa(bilité)nt les port(abilité)es.

Compatibilité, Performance, Fiabilité, Fonctionnalité, Sécurité, Maintenabilité, Utilisabilité, Portabilité.

Ces 8 aspects sont tous importants, mais l’un d’entre eux est comme un arbre qui cache la forêt : l’aspect fonctionnel. Eh oui : quand un produit numérique est créé, on veut avant tout savoir “s’il fonctionne” !

Toutefois, il est important d’avoir en tête les 7 autres aspects, qui se focalisent sur comment le produit fonctionne : rapidement, joliment, sécuritairement, compréhensiblement, simplement…

Cet article donne quelques clés pour comprendre ces types de test avant de vous lancer. Les ressources partagées sont issues de nos propres travaux ainsi que d’autres ressources francophones, pertinentes et faisant autorité dans le domaine de la qualité logicielle. Nous étofferons avec plaisir cette liste avec vos suggestions, alors n’hésitez pas à nous en partager.

Bonne lecture !

Compatibilité

Portrait robot du problème de compatibilité

L’applicatif fonctionne bien sur la machine du développeur (héhé !) mais rencontre des problèmes dès qu’il se trouve sur le même environnement qu’un autre logiciel du système d’information ? Il a du mal à communiquer avec d’autres systèmes dont il dépend ? Il présente certainement un problème de compatibilité !

A quoi ressemblent des tests de compatibilité ?

Bien souvent, les problèmes de compatibilité sont découverts “par hasard”, ou plutôt “par nécessité”, quand l’applicatif est installé dans son environnement cible. Mais en fonction du produit (notamment ceux nécessitant une installation locale chez chaque client), il peut être nécessaire de procéder à des tests systématiques. Cela consiste à imaginer différentes configurations que pourrait rencontrer l’applicatif, et vérifier si chacune d’elle permet un comportement nominal de celui-ci. Des tests de portabilité sont alors souvent également nécessaires (voir la section dédiée).

Pour aller plus loin :

Fiabilité

Problèmes de fiabilité : kézako ?

Les utilisateurs ne font pas confiance à l’applicatif ? Il plante à chaque fois qu’on saisit une valeur qu’il n’attend pas ? Il est régulièrement indisponible ? Il est incapable de se rétablir après avoir “crashé” suite à une forte affluence ? Il y a certainement un problème de fiabilité !

Comment tester la fiabilité ?

La fiabilité donne lieu à des tests de diverses natures.

Certains tests visent à mettre l’applicatif et son environnement en difficulté (coupure réseau, indisponibilité d’une ressource tierce…) afin de vérifier l’adéquation de son comportement et sa capacité de récupération.

Des dispositifs de monitoring peuvent également être mis en œuvre afin de vérifier la disponibilité de l’applicatif au fil du temps.

Pour aller plus loin :

Performance

La performance, qu’est-ce que c’est ?

L’applicatif est trop lent ? Il ne tient pas plus de 15 utilisateurs simultanés ? Il y a certainement un problème de performance !

La performance regroupe un certain nombre de termes utilisés au quotidien au sein des DSI : charge, robustesse, stress, rendement… 

Pourtant, chaque terme a une signification différente et peut mener à des types de test différents.

Vous vous perdez dans la sémantique ? Pas de panique, faites un petit tour par cet article de désambiguïsation qui vous permettra d’y voir plus clair grâce aux définitions de l’ISTQB !

Quels types de tests pouvez-vous réaliser ?

Les tests les plus courants pour cet aspect de la qualité sont les “tirs de charge”, qui consistent à simuler l’utilisation de l’applicatif par un certain nombre de personnes. Le type d’utilisation peut être spécifié, et des rapports sont générés de façon à comprendre quelles ressources sont les plus susceptibles de créer des lenteurs voire des indisponibilités en production.

Quelques outils connus : JMeter, Neoload, Gatling.

Pour aller plus loin :

Sécurité

Bugs de sécurité : des bugs pas comme les autres ?

Les bugs de sécurité, aussi appelés “failles”, ont une place un peu à part dans l’inconscient collectif, car ils mettent en jeu non seulement l’applicatif, son environnement et ses utilisateurs, mais aussi des acteurs bien spécifiques, communément désignés sous le noms de hackers, pirates ou utilisateurs malveillants !

Ces anomalies peuvent être de natures très différentes. On distingue communément les défauts présents dans l’applicatif (on parle tout simplement de “sécurité applicative”), et ceux qui concernent son environnement ou son réseau.

Techniques de tests de sécurité

Parmi les techniques spécifiques les plus courantes pour effectuer des tests de sécurité, on compte le pentest ou penetration testing (des tests souvent outillés qui consistent à s’introduire dans un système) et les scans de vulnérabilité, qui comparent un existant avec une bibliothèque de failles connues et plus ou moins communes. Tandis que les pentests nécessitent souvent des connaissances assez poussées, il est possible de mettre en œuvre rapidement et à peu de frais des scans de vulnérabilité. Toutefois, l’un ne remplace pas l’autre.

Des tests de sécurité peuvent être facilement mis en œuvre lors de la conception de tests d’API ; il suffit alors d’imaginer des scénarios “interdits” (exemple : essayer de changer le prix d’un article en utilisant l’API en étant connecté en tant que simple client !)

Pour aller plus loin :

Maintenabilité

Repérer les problèmes de maintenabilité

L’applicatif connaît de nombreuses régressions ? L’intégration de nouveaux développeurs se fait lentement et dans la douleur ? Les devs historiques rechignent à retourner sur le projet ? Ca sent la problématique de maintenabilité !

Comment gérer les défauts de maintenabilité ?

La qualité de code est étroitement liée à cet aspect de la qualité logicielle ; toutefois, ce n’est pas parce que la qualité de code est essentiellement une responsabilité des développeurs, que les testeurs n’ont pas de rôle à jouer pour faciliter la consolidation de la maintenabilité.

Les outils de qualimétrie peuvent être des alliés dans la détections de problèmes de maintenabilité. SonarQube par exemple détecte 3 types de problèmes de code : les bugs, les vulnérabilités et les “code smells”. Cette troisième catégorie permet de détecter des aspects qui trahissent un manque de maintenabilité au sein du code.

Un travail collaboratif de définition de bonnes pratiques de développement est également un investissement très intéressant pour la qualité à long terme du produit. Cela peut prendre la forme de revues de code classiques (simple et efficace !), mais cela peut aussi être outillé avec des solutions telles que Promyze.

Pour aller plus loin :

Utilisabilité

Le spectre des problèmes d’utilisabilité

L’utilisabilité est un aspect passionnant de la qualité logicielle, qui s’intéresse avant tout à l’expérience subjective de l’utilisateur. Et “subjective” n’est pas un gros mot ! Cela signifie simplement qu’il est nécessaire ici de se positionner dans une situation spécifique. Celle, par exemple, d’une personne qui n’a pas forcément les mêmes informations que nous, le même vécu ou encore les mêmes caractéristiques physiques (dans le cas des tests d’accessibilité).

Comment obtenir des retours d’utilisabilités crédibles ?

Une des grandes difficultés qu’un testeur peut rencontrer au moment de rapporter un bug d’utilisabilité est le risque de se voir rétorquer “C’est subjectif” (sous-entendu “Cela n’est pas un bug, cela ne sera pas corrigé”). Il est donc important de s’appuyer sur des arguments solides et si possible soutenus par des ressources tierces (états de l’art, témoignages utilisateurs…)

Comme pour la portabilité (voir section suivante), le crowdtesting (ou test participatif) est en mesure d’apporter rapidement des informations qualifiées sur l’utilisabilité des applicatifs.

Pour aller plus loin :

Portabilité

Les signes de problèmes de portabilité

L’applicatif fonctionne bien sur Windows 10 mais pas sur MacOS ? Sur Chrome mais pas sur Firefox ? Le design est magnifique sur écran d’ordinateur mais horrible sur smartphone ? Quand on parle de portabilité, il s’agit exactement de ce type de problèmes !

Démarrer une démarche de tests de portabilité

L’ennemi n°1 de la portabilité, c’est… de ne pas faire de tests de portabilité. Certes !

L’ennemi n°2, c’est de se disperser.

En effet, la combinatoire des environnements (système d’exploitation, version d’OS, navigateur, taille d’écran…) empêche la plupart du temps de tout tester. La portabilité donne une belle illustration du principe général du test “Les tests exhaustifs sont impossibles” !

Pour asseoir une stratégie de tests de portabilité efficace, il est nécessaire de s’appuyer sur des chiffres. Quelles sont les configurations les plus plausibles dans notre cas ? Quels sont les 20 % de configurations (à la louche !) qui nous permettront d’être confiants sur 80 % des cas ?

Des outils de tracking des utilisateurs sont alors très utiles (par exemple, Google Analytics pour un site web permet de connaître quelques éléments sur les habitudes de navigation des utilisateurs).

Une fois cet état des lieux réalisé, c’est le moment de se lancer. Plusieurs possibilités peuvent alors être envisagées :

  • Avoir recours à des fermes de devices ou de navigateurs (des services en ligne qui mettent à disposition des environnements dédiés à ce type de tests)
  • Investir dans de nombreux devices de test (c’est beaucoup plus onéreux ; la plupart du temps nous déconseillons cette pratique)
  • Faire appel à des crowdtesteurs. L’avantage ici étant que les retours ne concerneront pas seulement la portabilité, mais aussi d’autres aspects de la qualité logicielle.

Pour aller plus loin :

  • Comprendre les enjeux liés à la compatibilité : Article sur la Taverne du testeur
  • Nous avons testé pour vous deux services cloud permettant de mettre en œuvre des tests de portabilité : pCloudy et BrowserStack.
  • L’extension Lighthouse de Chrome permet de passer en revue des aspects tels que la performance, la portabilité et l’accessibilité.
  • La portabilité et la compatibilité sont souvent étroitement liées, car elles s’intéressent toutes deux à la variété des configurations logicielles et matérielles dans lesquelles l’applicatif va être utilisé. Toutefois, ce sont deux notions à distinguer. Voici donc un paragraphe (en anglais) sur la différence entre compatibilité et portabilité.

Par où commencer ?

Eh oui, cela fait beaucoup d’infos ! 

Connaître les 8 aspects de la qualité logicielle est un bon début. Pour la suite, nous vous conseillons ces étapes pour faire de vous un cador des tests non-fonctionnels :

  • Faire connaître ces 8 aspects à votre équipe (en partageant cet article par exemple !)
  • Discuter collégialement des différentes facettes de la qualité vis-à-vis des applicatifs que vous testez au quotidien
  • Identifier les tests non fonctionnels prioritaires pour chaque applicatif
  • Vous former et mettre en œuvre ces tests au sein de votre stratégie globale !

Tout cela étant dit, nous vous souhaitons bon courage dans votre périple ! Si vous avez des questions ou besoin d’aide, nous vous conseillons de poster un message sur le groupe LinkedIn francophone très réactif Le métier du test. Au plaisir de vous y retrouver !

Bon courage dans votre exploration et souvenez-vous que le test regorge toujours d’occasions d’apprendre !

7 signes que vous faites de la sur-qualité, et comment vous en sortir

La sur-qualité est l’ennemie sournoise de la qualité ; elle se déguise pour lui ressembler, mais ne manque pas de nuire aux projets dans lesquels elle s’invite. Voici quelques signes qui vous permettront de l’identifier dans vos pratiques et dans celles de vos équipes !

Dans son acception la plus simple, la sur-qualité consiste à allouer à la qualité des moyens supérieurs aux besoins réels.

Dans cet article, nous montrerons que la sur-qualité peut également provenir d’une mauvaise gestion de moyens alloués à la qualité, même si ces moyens sont originellement bien dimensionnés.

Afin d’illustrer des comportements extrêmes à éviter, les traits sont volontairement un peu forcés ! 🙂

Signe 1 : Vous rejouez toujours tous les tests de régression

Contexte : vous avez passé du temps à écrire un test d’importance moyenne à faible en 2020 à l’occasion de l’implémentation d’une nouvelle fonctionnalité. Aucune anomalie n’a été détectée en exécutant ce test. La fonctionnalité s’est avérée très stable au fil du temps.

Ce test s’est pourtant retrouvé rejoué VINGT-HUIT FOIS, à l’occasion de chacune des campagnes de test qui ont eu lieu depuis.

Vingt-huit fois.

Pourquoi ?

Par habitude ? Parce que vous avez décidé, ou bien votre entreprise a décidé, que la qualité était une priorité, et que dans cette mesure il fallait rejouer à chaque campagne l’ensemble des tests de régression ?

Des leviers plus forts que vous sont certainement en jeu (biais cognitifs, management, etc), mais c’est contre-productif. Au mieux, cela dépense silencieusement un budget énorme qui avait été prévu à cet endroit. Au pire, cela contribue à construire une mauvaise réputation des activités de test. Ainsi pourrez-vous entendre les discours suivants :

  • « Les tests, ça coûte cher »
  • « Les recettes sont de plus en plus longues et créent un goulet d’étranglement »
  • « On fait de plus en plus de tests mais on ne trouve pas de plus en plus de bugs »
  • « Les testeurs doivent s’ennuyer, ils font toujours la même chose ».

Comment éviter ça ?

Le meilleur moyen d’éviter cet écueil est de prendre le temps de revoir sa stratégie de test, et de trouver un équilibre entre rapidité et couverture de test.

Signe 2 : Vous conservez tous les cas de tests écrits depuis le début du projet

« Ce cas de test a bien été écrit pour une raison… »

C’est le seul motif que vous avez pour conserver ce cas de test, et le rejouer respectueusement campagne après campagne.

La personne qui l’a écrit est partie depuis des mois, d’autres tests ont été écrits depuis qui couvrent peut-être encore mieux cette partie, mais dans votre esprit, il est hors de question de supprimer ce cas de test.

Or, un référentiel de tests en bonne santé est comme un serpent ; il grandit certes, mais lentement, et se débarrasse régulièrement de sa peau morte. Comme l’indique avec humour le wiki Fan de Test, conserver, par principe, la totalité des tests écrits depuis le début du projet, relève de la syllogomanie.

Comment éviter ça ?

Effectuer régulièrement une revue des tests, pour éventuellement en supprimer ou en fusionner, est une bonne pratique. Il y a de quoi hésiter avant de supprimer un cas de test, mais si vous utilisez un outil de gestion des tests qui intègre une gestion des versions, cela devient beaucoup moins intimidant.

Signe 3 : La combinatoire vous contrôle plus que vous ne la contrôlez

Vous voulez tester toutes les configurations, TOUTES.

Un produit peut être de 10 couleurs différentes et de 5 tailles différentes ? Boum, vous prévoyez 50 tests pour vérifier que ce produit s’affiche correctement dans le panier quelle que soit sa couleur et sa taille.

Vous souhaitez que le site web fonctionne correctement sur les 3 navigateurs les plus utilisés du marché ? Allez : 50 tests multipliés par 3, 150 tests.

Et ainsi de suite.

C’est une caricature évidemment, mais pourrait-elle être votre caricature ?

Comment éviter ça ?

Découvrez des techniques, par exemple Pairwise, qui vous permettront de réduire le nombre de jeux de données tout en conservant une couverture satisfaisante.

Et pour éviter le paradoxe du pesticide, changez de temps à autre les jeux de données !

Il est important également de voir les cas d’utilisation au-delà de la combinatoire. S’il est possible, dans un formulaire d’inscription, de saisir un pays de résidence et une devise préférée, il est important de proposer l’euro aux utilisateurs ayant choisi la France comme pays de résidence. Le dollar des Tuvalu (archipel de 11 000 habitants)… un peu moins. Inutile donc de fournir le même effort de test sur les deux cas !

Signe 4 : Vous avez des lubies

Un jour, vous avez trouvé un bug de sécurité sur un applicatif A, qui pouvait être reproduit en modifiant malicieusement le contenu de listes déroulantes. Vous avez donc mis en place des tests très poussés sur cette partie, ce qui s’est révélé parfaitement pertinent dans le contexte. Quel bonheur de faire une si belle moisson de bugs ! Quel génie !

Depuis, à chaque fois que vous vous retrouvez sur un nouveau projet, vous mettez en œuvre ce type de test. La sécurité des listes déroulantes est systématiquement testée de fond en comble. C’est votre dada. Et peu vous importe que cela prenne du temps, peu vous importe que les risques ne soient pas les mêmes ; ça a marché une fois, ça devrait marcher de nouveau !

Bref, il est facile d’oublier les 7 principes généraux du test logiciel, et un en particulier : « Les tests dépendent du contexte ».

Comment éviter ça ?

Votre expérience de testeur doit vous bonifier avec le temps, ouvrir vos perspectives et vous permettre de vous adapter à toujours plus de situations. Si vous pensez constamment à ce qui a fonctionné sur vos précédents projets, vous risquez de tomber dans la sur-qualité sur certaines parties anodines et d’utiliser le temps dédié aux tests à mauvais escient.

Le mieux est alors, à chaque fois que l’on intervient sur un nouveau projet de test, de s’efforcer à adopter un regard neuf. Presque comme si on voyait un logiciel pour la première fois… tout en capitalisant sur l’expérience passée. Un exercice d’équilibriste, mais qui en vaut la peine !

Signe 5 : La loi de Murphy est votre seule crédo

« Tout ce qui est susceptible d’aller mal ira mal. »

L’applicatif à tester est mis en production toutes les deux semaines ? Pas de problème : toutes les deux semaines, vous faites non seulement des tests sur des cas passants, sur des cas non-passants, mais aussi sur des scénarios abracadabrantesques. Toujours les mêmes, par sécurité, parce qu’on ne sait jamais.

Hé oui, car que se passerait-il en production si un utilisateur essayait de changer sa date de naissance de manière à indiquer qu’il est né après-demain, en passant par l’inspecteur parce que l’interface web ne permet pas cette manipulation ?

Quelle question brûlante, cela vaut vraiment la peine de faire ce test tous les 15 jours ! (Ironie)

Comment éviter ça ?

La loi de Murphy n’est pas dénuée de bon sens, mais la plupart du temps, il est important d’obtenir d’abord des informations sur ce qui est le plus probable d’arriver.

Pensez avant tout au besoin métier, recentrez-vous sur le cœur des exigences.

Dans la mesure du possible, collectez également des informations sur les utilisateurs finaux : quels sont leurs besoins les plus fréquents ? Quelles sont les fonctionnalités qu’ils utilisent le plus ? Quelles sont leurs habitudes de navigation ? Cela aide à redonner à la loi de Murphy sa juste place.

Signe 6 : Vous testez comme des fous mais il y a tout de même des bugs découverts en prod

Le temps passé à couper les cheveux en quatre, consciemment ou inconsciemment, sur des fonctionnalités triviales, représente un manque à gagner. C’est du temps confisqué aux questions essentielles, celles qui s’intéressent à ce qui pourrait vraiment mal tourner.

La sur-qualité sur certaines parties n’empêche donc en rien… la sous-qualité sur d’autres !

Comment éviter ça ?

Prendre conscience du décalage entre l’important effort de test fourni, et les résultats infructueux, est la première étape. Cela permet ensuite de marquer une pause pour revoir la stratégie. L’étape suivante : recentrer les activités de test autour des fonctionnalités les plus fragiles, celles qui regroupent le plus de défauts (pensez Pareto !)

Signe 7 : Ajouter davantage de tests ne réussit pas au projet

« Les tests, c’est comme le fromage : plus il y en a et meilleur c’est ! »

Oui… mais dans les mêmes limites !

Ne niez pas : vous ne voudriez pas d’une pizza recouverte d’une couche de 4 centimètres de fromage. (Si ? Bon ok, mais à ce moment-là on a de très bons cardiologues à vous conseiller.)

Il existe de même un seuil à partir duquel ajouter des tests ne réussit plus au projet, au contraire.

Jusqu’à un certain point, augmenter les moyens alloués aux tests est bénéfique au projet : les anomalies sont trouvées plus tôt, et leur coût de correction est donc moindre.

Au-delà d’un certain point, les tests continuent de déceler des anomalies, mais plus suffisamment pour assurer le ROI de cette activité.

Comment éviter ça ?

Observez comment se déroulent vos campagnes de test.

Mettons qu’une campagne se déroule sur 4 jours ; si très peu d’anomalies majeures sont découvertes pendant les trois premiers jours, qu’aucune n’est découverte lors du quatrième, et que la nouvelle version ne révèle aucune nouvelle anomalie une fois en production, interrogez-vous collectivement : serait-il possible la prochaine fois de réduire le temps alloué à la campagne de tests ?

Ce temps gagné pourrait être utilisé autrement : en effectuant des revues de spécifications, en automatisant davantage de tests, en optimisant l’outil de gestion des tests…

Résultat : au fil de l’eau, les tests permettent de livrer de plus en plus vite en production, et deviennent un facteur visible de succès.

En conclusion

La surqualité est l’ennemie de la qualité, mais aussi de l’image que vos interlocuteurs se font des activités de test. Pire encore, elle cohabite volontiers avec la sous-qualité.

Elle met en péril l’efficience (faire bien les choses), et parfois aussi l’efficacité (faire les bonnes choses), des tests. Heureusement, des solutions existent !

Et vous, quels signaux utilisez-vous pour déceler la sur-qualité au sein de vos projets ?

test logiciel-video-bug d'expérience

[VIDEO] Un bug d’UX est-il un bug ?

Un bug, c’est « toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. » (Glossaire CFTL, ISTQB).
Si on se contente de lire la première partie de cette définition (jusqu’à « etc »), le positionnement général vis-à-vis du bug est tout à fait confortable puisque cela permet pour les testeurs de définir deux parties de leur activité assez clairement :
  • Vérifier que les exigences forment un ensemble cohérent
  • Tester si l’application est conforme à ces exigences
Par contre, pour la seconde partie, « les perceptions ou expériences de quelqu’un », c’est une autre histoire :
  • Qui est quelqu’un ?
  • Qu’est-ce qu’un bug d’UX ?
  • Quelles perceptions ? Quelles expériences ?
  • Quels biais entrent en jeu ?
  • Comment gérer ces bugs ?
Zoé vous apporte des réponses cette vidéo sur les Bugs d’expérience (UX).
Et vous alors, quels bug d’UX avez-vous pu trouver dernièrement ? Dans vos organisations, comment procédez-vous pour les trouver / corriger ?

 

 

 

 

8 choses essentielles à savoir pour tester un serveur d’autorisation

Que se passe-t-il vraiment lorsqu’on retire de l’argent à un distributeur de billets, quand on paie par carte bleue chez un commerçant ou qu’on réalise une transaction en ligne ? Le monde de la monétique est passionnant et donne lieu à son propre arsenal de tests. Aujourd’hui, Coralie Ipotesi, experte du domaine, vous donne un premier aperçu de ces problématiques ! Bonne lecture !

Imaginez-vous à l’autre bout du monde, en face d’un distributeur automatique qui refuse de vous délivrer des billets. Vous ressentez un état de solitude profonde, car sans ces billets vous ne pourrez pas payer le bouiboui qui vous sert d’hôtel (et qui évidemment n’accepte pas la carte bleue). Eh bien, vous êtes sans doute en train de faire l’expérience d’un serveur d’autorisation qui s’amuse à vous titiller. Pourquoi ? Les raisons peuvent être multiples :

  • dépassement de plafond à l’étranger,
  • absence d’autorisation d’utilisation de la carte dans tel pays,
  • problème sécuritaire,
  • décalage horaire mal calculé…

Bref, il y a une boîte noire située à plusieurs milliers de kilomètres qui, si elle est mal gérée, peut causer de gros dégâts. Attardons-nous un peu sur ce serveur pour mieux le connaître !

1) Le serveur d’autorisation agit dans l’ombre

Personne ne le connait, mais pourtant tout le monde l’utilise au quotidien. Le serveur d’autorisation est au cœur du monde de la monétique, et il est capable de traiter des millions de transactions quotidiennes.

Si un paiement refusé sur le terminal provoque toujours un état de panique chez l’acheteur, c’est souvent à tort qu’on s’en prend à la carte ou au terminal : c’est en réalité bien souvent le serveur d’autorisation qui a rendu son verdict dans l’ombre d’une salle obscure. Son but : s’assurer qu’autant l’acheteur que le commerçant sont en mesure d’honorer la transaction.

Le serveur d’autorisation est en fait un applicatif qui implémente un ensemble de règles de gestion permettant l’acceptation ou le refus d’une transaction par carte bancaire. L’ensemble des données échangées lors de cette transaction répond à un ou plusieurs protocoles de communication. Ces données peuvent être aussi bien des données sécuritaires de la carte que des informations liées au marchand, en passant par des données contextuelles relatives à l’achat et bien d’autres encore. Le serveur d’autorisation va s’appuyer sur cet ensemble de paramètres et sur le contexte client ou commerçant pour déterminer si la transaction peut avoir lieu.

2) Il existe 2 types de serveurs d’autor’

Une transaction bancaire se produit toujours entre un acheteur et un vendeur. C’est pourquoi il y a 2 types de serveurs d’autorisation qui entrent en jeu : un pour le porteur de la carte (le serveur d’autorisation émetteur, ou SAE) et un pour le commerçant (le serveur d’autorisation acquéreur, ou SAA). Chacun sa tâche, chacun ses vérifications avant de passer la main à l’autre. Là où l’un va s’attarder sur les règles métier, l’autre va surtout s’atteler à convertir des protocoles. Des approches de test complètement différentes pour un but commun : s’assurer de la complétude de la transaction. On vous explique tout ça un peu plus loin ! En attendant, voici le schéma de fonctionnement général pour un paiement par carte bleue sollicitant à la fois le SAE et le SAA :

3) Les serveurs d’autorisation s’appuient sur des réseaux bancaires

Les serveurs d’autor’ c’est bien, mais il faut bien que la transaction soit véhiculée de l’un à l’autre. C’est là que les réseaux bancaires entrent en jeu. On parle ici par exemple de VISA ou MasterCard, les plus connus, mais il existe en réalité une multitude d’autres réseaux bancaires, chaque pays ayant plus ou moins le sien : JCP pour le Japon, UPI pour la Chine, Diners ou American Express aux Etats Unis, ou plus proche de nous, le réseau CB en France. Dans le monde des serveurs d’autorisation, c’est ce que l’on appelle « le règlementaire ». Il faut en effet voir chaque réseau comme un chef d’orchestre, qui définit un protocole de communication auquel les serveurs d’autorisation vont devoir s’adapter pour utiliser le réseau. Par exemple, si un commerçant souhaite accepter les cartes Diners de ses clients, le serveur d’autorisation auprès duquel il a souscrit doit au préalable avoir signé un contrat avec Diners pour l’acquisition de ce flux. Cela implique une période de certification, qui permet au réseau de s’assurer que les données véhiculées sont conformes à son protocole. Une fois la certification acquise, le serveur d’autorisation est autorisé à traiter les cartes Diners.

Si la plupart des réseaux répondent à la norme ISO8583 qui définit la structure des messages pour des transactions financières par carte bancaire, d’autres, comme NEXO par exemple, ont adopté un format complètement différent (ISO 20022) qui, s’il vise à uniformiser les règles du paiement en Europe, oblige les acquéreurs à revoir complètement les règles de conversion avec les réseaux internationaux.

4) La sécurité avant tout

Le serveur d’autorisation, c’est aussi une myriade de cryptogrammes, clés et autres données sécuritaires qui vont garantir la fiabilité de la transaction. Tout un arsenal est mis en place notamment via la puce de la carte pour éviter toute forme de malveillance. Les tests sur ces aspects sécuritaires sont souvent complexes et chronophages, un paramètre important à prendre en compte en phase de test. En effet, si des outils existent pour décrypter les échanges entre la puce de la carte et le TPE, la complétude des tests sécuritaires ne peut souvent se faire qu’à l’aide de « cartes blanches ». Ces cartes de test vont reproduire l’environnement technique et sécuritaire de la carte finale sans en avoir le visuel ou l’embossage (oui, c’est comme ça qu’on appelle les petits reliefs sur une carte !). En reproduisant un environnement commerçant à l’aide de TPE de test, il sera alors possible de s’assurer que les paramètres sécuritaires des cartes sont correctement traités, par exemple que les clés échangées sont comprises par les deux parties et qu’elles ne provoqueront donc pas d’erreur lors des transactions.

Un autre aspect de la sécurité des paiements par carte bancaire passe par la mise en œuvre de la norme PCI DSS (Payment Card Industry Data Security Standard) qui vise à protéger les clients contre l’utilisation frauduleuse de leurs données. Celle-ci va fortement influencer les tests, car elle impose notamment que les données sensibles ne soient plus accessibles directement dans les systèmes mais fassent l’objet de cryptages. Cryptages qu’il va falloir être en mesure de reproduire sur les environnements de test tout en s’assurant que les données restent utilisables par les équipes de test.

5) Le serveur d’autorisation est un système temps réel

Le paiement d’une marchandise via un terminal ou un site internet interroge en direct les serveurs d’autorisation et délivre immédiatement l’autorisation. Qui pourrait imaginer en effet s’entendre dire par le commerçant : « Bon je saurai demain si votre paiement a été accepté, revenez à la même heure et je vous donnerai vos achats ! » Comme tout système fonctionnant en temps réel, cela implique un haut niveau de disponibilité de l’applicatif, qui ne peut jamais être au repos. C’est pour cela que ce type de logiciel est le plus souvent dupliqué afin d’éviter une panne générale en cas de pépin. Cependant, dans le cas où un système de backup est effectivement présent, il sera important de vérifier les processus de duplication des données en temps réel entre les différents sites, qui peut être source de bugs importants en cas de bascule. Par ailleurs, comme tout système temps réel, la supervision de la production va être primordiale afin d’assurer une qualité de service optimale.

6) Le serveur d’autorisation acquéreur est un super-traducteur

Vous l’aurez compris, le serveur d’autorisation peut être autant notre allié que notre pire ennemi lors d’un achat. Mais alors comment s’assurer qu’il prendra toujours des décisions mûrement réfléchies ?

Plaçons-nous d’abord du côté de l’acquéreur, c’est-à-dire la banque du commerçant. Le plus grand défi d’un serveur d’autorisation acquéreur va être de savoir jouer l’interprète. En effet, comme nous l’avons déjà évoqué, la transaction va devoir transiter par un réseau bancaire avant d’atteindre le serveur d’autorisation émetteur, mais le terminal de paiement ou TPE, lui, parle son propre langage. Il s’agit donc ici d’effectuer des conversions de protocole tout en gardant intacte l’essence du message transactionnel. Le monde de l’acquisition est de ce fait fortement dépendant des contraintes protocolaires imposées par les réseaux, et va devoir s’adapter en continu aux évolutions de ces derniers. Celle-ci font en effet l’objet de certifications indispensables et régulières de la part des réseaux : pas de certification, pas de flux transactionnel. Ces évolutions règlementaires peuvent survenir plusieurs fois par an dans certains cas et nécessitent donc une constante évolution des serveurs d’autorisations qui les implémentent, et donc un effort de test conséquent et régulier.

7) Le serveur d’autorisation émetteur respecte une collection de règles métiers

Regardons maintenant de plus près côté émetteur, c’est-à-dire la banque du porteur de carte. Contrairement à l’acquéreur, l’émetteur, lui, parle en général le langage du réseau auquel il est connecté. La dépendance protocolaire est donc moins complexe à prendre en compte, même s’il reste soumis aux évolutions règlementaires. En revanche, parce que les banques souhaitent fournir toujours plus de services à leurs clients, c’est au niveau des règles fonctionnelles qu’il va falloir concentrer l’effort de test. Une des causes de refus courantes sur un serveur d’autorisation est le dépassement des plafonds. La multitude des plafonds proposés, en montant, durée ou type de transaction peut en effet relever du défi en termes de tests. Ces dernières années, de nouveaux types de paiement ont également fait leur apparition, notamment le paiement mobile, qui ont nécessité la mise en place de nouvelles règles de gestion sur les serveurs d’autor’, et donc de nouveaux tests.

8) Des outils de tests spécifiques sont nécessaires

L’utilisation de simulateurs transactionnels disponibles sur le marché (par exemple Galitt ou FIS) est indispensable lors des tests d’un serveur d’autorisation, elle permet de générer des transactions en appliquant les règles protocolaires et sécuritaires spécifiques à un réseau et à un type de transaction donné. L’idée ici est de se substituer au réseau bancaire, soit d’un point de vue acquéreur, soit d’un point de vue émetteur, par exemple en paramétrant un type de transaction particulier (paiement sans contact, avec ou sans code PIN, paiement internet, etc.). Ces simulateurs sont notamment utilisés lors des phases de certification avec les réseaux, où ils permettent d’assurer la cohérence des données transmises, chaque réseau favorisant l’utilisation d’un simulateur préalablement certifié par ses soins.

S’agissant de systèmes fonctionnant en temps réel, les phases de tests de régression, nécessitant un pool de transactions significatif, seront également cruciales afin de s’assurer que la mise en production d’une nouvelle évolution ne bloquera pas les porteurs aux quatre coins du monde. Une approche courante est la création de templates déclinés par type de transaction et qui représenteront un ensemble significatif de cas métier. On peut par exemple imaginer que cet ensemble serait constitué de transactions de type paiement contact, sans contact, mobile, avec ou sans saisie du code pin, etc. Toutes ces caractéristiques vont influer sur les règles de gestion mises en œuvre sur les serveurs d’autorisation et sont donc indispensables à prendre en compte lors de tests de régression.

Conclusion

Comme vous l’aurez compris, même s’il n’est pas visible du grand public, le serveur d’autorisation est un élément particulièrement sensible de la chaîne du paiement électronique et nécessite donc une attention toute particulière pour le testeur. Que ce soit en phase de tests unitaires, d’intégration, d’acceptation ou lors de phases de certification ou de régression, il devra être capable d’anticiper les comportements des futurs utilisateurs afin de prévenir les défauts qui pourront avoir des conséquences pour l’acheteur (impossibilité d’obtenir sa marchandise ou ses billets) ou le commerçant (impossibilité de se faire payer). Une bonne connaissance des moyens de paiements et de leur spécificité sera alors un atout particulier pour le testeur, et lui permettra d’avoir une vision globale du système et de ces interactions pour en déceler au plus tôt les failles potentielles.

~ Coralie Ipotesi, ingénieure test applicatif chez Hightest

Si vous voulez aller plus loin dans la découverte de la monétique, nous vous conseillons de faire un tour sur ce blog.

Et si vous avez soif de découvrir d’autres univers de la qualité logicielle, nous vous conseillons notre notre saga des tests audiovisuels !

Un-jour-je-serai-le-meilleur-testeur

Comment devenir testeur logiciel ?

Note : cet article a été mis à jour en décembre 2021

Le monde du test fait face à un paradoxe.

D’une part, peu de formations initiales proposent de se lancer dans la profession, et le métier, quoique de plus en plus recherché en entreprise, peine à sortir de l’ombre. A l’heure actuelle, il est relativement difficile d’attraper un testeur logiciel dans son Pokédex.

D’autre part, un nombre croissant de personnes se tournent vers les métiers du test en ayant une vision très floue des activités auxquelles elles devront prendre part, ou qui ont des attendus parfois complètement erronés. Un exemple vécu ? « Je souhaite quitter mon poste de développeur pour un emploi de testeur car c’est moins difficile et il y a moins de responsabilités ! »

Plus fréquemment, nous recevons des candidatures de la part de profils divers, plus ou moins intrigués par le métier, mais sans notions de test logiciel.

Pour essayer de faire coïncider un peu mieux offre et demande, voici donc quelques pistes à l’usage de l’aspirant testeur.

Avertissement : dans cet article, nous employons le terme « testeur » au sens générique du terme ; cela englobe beaucoup de dénominations particulières que l’on peut retrouver par ailleurs (QA, ingénieur test applicatif, technicien qualité logicielle, test manager, etc).

Sommaire

  • Quels prérequis pour devenir testeur ?
  • Quelles sont les tâches du testeur ?
    • L’exécution des tests manuels à partir d’un référentiel de tests
    • La conception des tests
    • La gestion des anomalies
    • Les tests exploratoires
    • L’automatisation des tests
    • En bref : un métier polyvalent
  • Les outils du testeur
    • Les outils de gestion des tests
    • Les outils d’automatisation des tests
    • Les outils transverses
    • Et surtout…
  • Les formations
    • Les formations universitaires
    • Les formations éligibles au CPF
    • La POE
    • L’auto-formation
  • Premier entretien !
  • Pourquoi le métier de testeur est-il si peu connu ?
    • Une famille de métiers, une multitude de dénominations
    • Une communication insuffisante auprès du grand public
    • Comment faire connaître le métier du test ?

Quels prérequis pour devenir testeur ?

Le métier du test est un métier complexe et passionnant, et peu de prérequis sont strictement exigés. Outre un goût pour l’informatique et le travail d’équipe, il est toutefois souhaitable d’avoir quelques-unes des qualités ci-dessous :

  • 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 !

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 testeurs 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 !

Quelles sont les tâches du testeur ?

Mais tout d’abord, à quoi faut-il s’attendre quand on candidate à un poste de testeur ? Cette section s’adresse à tous les curieux de test logiciel qui sont attirés par cette activité et souhaitent savoir, concrètement, ce à quoi s’adonne un testeur.

Il faut garder à l’esprit le fait que l’activité de test varie d’une entreprise à l’autre, en fonction du type de projet, du mode de développement, du domaine métier et d’autres facteurs encore.

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

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

L’exécution des tests 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 machinalement sur des boutons en suivant minutieusement d’austères modes opératoires.

Quoi qu’il en soit ; quand cela se présente, le testeur se trouve 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. »

Le testeur lit la fiche de test et exécute le scénario indiqué. Si le logiciel fait ce qui est demandé, le testeur le signale et passe au test suivant. Sinon, il 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 être un bon testeur : 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.

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.

A partir d’un cahier des charges ou de tout autre document décrivant comment un logiciel devra fonctionner, 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é.

Le testeur, quand il conçoit les tests, doit garder à l’esprit le fait que le temps alloué à l’exécution des tests est limité. Il doit donc 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.

La gestion des anomalies

Ce n’est pas tout de créer des rapports d’anomalies ; il faut aussi faire en sorte que les bugs soient corrigés. Le testeur ne corrige pas lui-même 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.

Le testeur doit donner une visibilité des anomalies ouvertes. Il crée 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).

Les tests exploratoires

On parlait précédemment de l’exécution des tests à partir d’un référentiel. Sachez qu’un référentiel formel de tests n’est pas toujours utilisé, et que 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 utilisateurs 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 testeur, 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 simuler le scénario utilisateur 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.

Conseil : pour avoir bien en tête les tenants et les aboutissants de l’automatisation des tests, n’hésitez pas à parcourir cette ressource, qui a vocation à fournir un tour d’horizon assez complet sur le sujet.

En bref : un métier polyvalent

Bien d’autres activités encore pourraient être évoquées. Le métier de testeur 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 testeur 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.

repartition-activité-du-testeur-logiciel

Pour finir, rien de tel que d’échanger avec d’autres testeurs 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 ».

Les outils du testeur

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 tous les testeurs ne soient pas des automaticiens, 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 testeur.

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

Les-formations-pour-devenir-testeur

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 testeur junior.

Les formations universitaires

Il est important de noter qu’à l’heure actuelle, sur le territoire français, l’offre de formation universitaire en test logicielle 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 28 étudiants 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.

Quelques outils étudiés : Selenium, Jenkins, MaTeLo, TestLink, JavaUnit, PHPUnit, Squash, Android Studio. La formation comprend un passage de la certification ISTQB de niveau Fondation.

Voir la présentation de ce cursus.

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.

Ecole Française du Test Logiciel et de la Cybersécurité (EFTL-CYBER)

Cette école se situe à Rennes et propose 3 formations autour de la qualité logicielle :

Autres formations

Le site de l’association QTL-Sup mentionne quelques autres formations ; voir cette liste.

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 qu’aspirant testeur, 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 ! Si vous souhaitez vous faire une idée du type de questions du test ISTQB de niveau Fondation, vous pouvez faire dès à présent notre test en ligne.

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 testeurs qualifiés sont en effet très recherchés.

Acial notamment propose des parcours de POE qui permettent d’acquérir les fondamentaux du test logiciel en 10 semaines, pour devenir ensuite consultant dans ce domaine. Deux parcours sont disponibles : un parcours axé sur l’automatisation et un autre parcours plus généraliste.

L’auto-formation

Des MOOCs en français sur le test logiciel ? Il y en a quelques-uns sur la plateform OpenClassroms, notamment :

Deux autres cours sur le sujet devraient être disponibles à l’été 2019 : « Testez en continu avec Jenkins » et « Testez vos fonctionnalités avec Selenium et Python ».

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, pour les très débrouillards, de passer la certification ISTQB en candidat libre pour 250 euros (prix pour un passage en France métropolitaine). Voir la liste des prochaines sessions. Il est également possible de passer l’entretien en distanciel.

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 avons créé une plateforme de crowdtesting nommée Testeum, qui vous permettra, si cela vous intéresse, de découvrir cette activité.

Premier entretien !

Votre formation va bientôt s’achever et votre premier entretien d’embauche pour devenir testeur se profile ? Nous vous recommandons de jeter un œil à l’article que nous avons dédié à ce grand moment ! On croise les doigts pour vous 🍀

Pourquoi le métier de testeur est-il si peu connu ?

Nous espérons que cet article a pu permettre à certains d’avoir une idée plus précise sur le métier. Avant de se quitter, nous proposons de se pencher sur le problème de fond qui a mené à cet article : la méconnaissance importante dont souffre le métier de testeur.

Une famille de métiers, une multitude de dénominations

Le métier de testeur ne cesse de se développer et de se spécialiser, ce qui conduit à une diversification des dénominations. Rares sont les offres d’emploi qui se contentent du mot « testeur », comme l’explique cet article de la Taverne du Testeur.

Cependant, selon nous, ce phénomène n’explique qu’une petite partie du problème.

Une communication insuffisante auprès du grand public

En effet, un nombre important de sources d’informations grand public donne une vision parcellaire voire erronée du métier de testeur.

A titre d’exemple, la nomenclature 2018 du Cigref (EDIT : celle de 2021 aussi !) réserve le métier de testeur aux « Bac + 2 (BTS ou DUT) » ou aux « ingénieurs débutants », avec comme possibilités d’évolution une bifurcation vers les « fonctions études » ou la maîtrise d’ouvrage. L’automatisation des tests n’est pas mentionnée, ni les multiples spécialisations possibles dans le domaine de la qualité (test management, test de performance, test de sécurité, UX, SDET…). Vu comme ça, le métier peut donc ressembler à une « seconde chance » pour ingénieurs médiocres, en attente de trouver mieux. Quel dommage de réduire le métier à cela !

Le site « Etudiant » du Parisien relève-t-il le niveau ? Un petit peu, même si dès la première phrase, on grince un peu des dents : « Le testeur repère et relève les anomalies et bugs présents dans un logiciel ou une application avant sa publication. » La partie la plus intéressante n’apparaît qu’en troisième dans la liste des activités qui incombent au testeur : « Établir une tactique opérationnelle, créer des outils de test et d’analyse des résultats trouvés, dans le but de rédiger des bilans précis des logiciels étudiés. »

En 2019, le site de l’Apec ne mentionnait tout simplement pas le métier de testeur dans sa liste des fiches métier de l’informatique, même si on le retrouvait en filigrane sur les pages « Consultant maîtrise d’ouvrage », « Responsable de la maîtrise d’ouvrage bancaire / MOA » et « Ingénieur qualité/méthodes (informatique) ».

En 2021, ça y est, on trouve une fiche dédiée ! Celle-ci ne mentionne pas encore l’automatisation à proprement parler, mais rend tout de même justice à la polyvalence du métier, alors merci à l’Apec.

Comment faire connaître le métier du test ?

Nous espérons sincèrement que le métier deviendra plus connu grâce aux efforts de la communauté du test francophone. Les différents groupes, meetups, événements et blogs existants pourront sans doute faire rayonner le métier à leur échelle.

L’apparition de personnages de testeurs dans la culture populaire pourrait également mettre notre métier sous le feu des projecteurs (comme c’est largement le cas pour les métiers de développeur et d’administrateur système !) Un grand nombre de métiers sont entourés d’un imaginaire épique et enthousiasmant ; et si c’était notre tour ?

3 questions essentielles pour bien démarrer en automatisation des tests

L’automatisation des tests est une piste que vous voulez investir. Vous souhaitez, par cette démarche, maîtriser les coûts associés à la qualité, bénéficier d’une meilleure couverture des tests, ou encore mettre en œuvre des recettes plus courtes et efficaces. Très bien, mais par où commencer ? Qui affecter à ce chantier ? Quels tests faut-il automatiser ? Quels KPI suivre ? Quel outil choisir ?

Une fois qu’on a répondu « oui » à la question « faut-il automatiser les tests ? » c’est effectivement une autre ribambelle de questions qui se présentent, comme si on avait ouvert une boîte de Pandore. Pire encore : en répondant mal à ces problématiques, l’automatisation des tests pourrait se solder par un échec.

Dans l’article précédent, nous donnions 10 bonnes raisons d’automatiser les tests. Aujourd’hui, nous vous offrons des clés pour mettre en œuvre concrètement un tel chantier. Accrochez-vous, car les pièges sont nombreux, mais le jeu en vaut la chandelle !

1) Quels challenges et difficultés pose l’automatisation des tests ?

Des challenges autant techniques qu’organisationnels, et la bonne nouvelle c’est qu’il est possible d’en anticiper certains avec un minimum d’effort.

Il est important, avant de se lancer, d’avoir en tête les principales difficultés associées à l’automatisation des tests. Commençons donc par cela, en nous basant sur l’édition 2020-2021 du World Quality Report.

Selon cette source, la problématique la plus fréquente (52 %) est le manque de personnel suffisamment qualifié pour mener à bien l’automatisation des tests. C’est la question du « QUI ».

La deuxième difficulté la plus fréquente (42 %), est liée aux lacunes au niveau des environnements de test et des jeux de données. Un exemple à la fois simple et très fréquent ? L’environnement dédié aux tests automatisés est parfois aussi utilisé par des testeurs humains, qui modifient ou suppriment des ressources dont les tests automatisés ont besoin. Ces actions peuvent provoquer des faux positifs et donner du fil à retordre au moment où on analyse les résultats des tests automatisés. Cette difficulté pointe du doigt une réalité : l’automatisation des tests est un enjeu d’équipe ; si des environnements spécifiques et des données séparées sont requises, il est important d’impliquer l’ensemble des parties prenantes concernées (administrateurs systèmes, métiers…) Automatiser « dans son coin » n’est pas envisageable.

Problème suivant ? 41 % des entreprises rencontrent des difficultés à définir une bonne stratégie d’automatisation. C’est la question du « QUOI ».

D’autres challenges sont également évoqués ; le classique « on n’a pas assez de temps ! » est invoqué par 37 % des entreprises (cela prend en effet du temps de s’arrêter au bord de la route pour remplacer ses roues carrées par des rondes !), juste avant « on n’a pas les bons outils » (32 %).

Au sein de cet article, nous aborderons spécifiquement les questions du QUI et du QUOI, qui constituent la base d’une bonne stratégie d’automatisation des tests.

2) Qui est responsable de l’automatisation des tests ?

Plusieurs leaders possibles

Bien plus de personnes qu’on pourrait l’imaginer de prime abord !

Nous disions plus haut que 52 % des entreprises déclarent manquer de personnel qualifié pour l’automatisation des tests. Les « testeurs automaticiens » sont en effet comme des trèfles à quatre feuilles : ils existent (contrairement aux moutons à 5 pattes…), mais il y en a peu. Restent donc, classiquement, 3 possibilités.

  • Faire monter en compétences les testeurs en automatisation des tests
    • CONTRE :
      Le développement n’est pas la tasse de thé de tous les testeurs ; une telle montée en compétences nécessite des efforts importants et une bonne dose de motivation
    • POUR :
      L’automatisation des tests produit des informations dont les testeurs seront en général les premiers bénéficiaires, et ce sont les mieux placés pour savoir ce qui doit être automatisé
  • Déléguer l’automatisation aux développeurs
    • CONTRE :
      L’automatisation des tests est une activité de test, les développeurs peuvent avoir du mal à adopter l’état d’esprit critique qui rend les tests efficaces
    • POUR :
      L’automatisation des tests est une activité de développement, les développeurs sont naturellement en mesure de s’y adonner
  • Externaliser la mise en place de l’automatisation des tests
    • CONTRE :
      Cette démarche peut être moins féconde si vous la décorrélez totalement des autres activités de test ; même « externes », les automaticiens auront besoin de s’immerger dans la vie du projet
    • POUR :
      Les prestataires aguerris connaissent les principaux écueils et les évitent plus facilement ; leur œil extérieur leur permet de questionner la démarche et de proposer une solution sur mesure.

Mais il ne suffit pas de répondre à cette question pour se tirer d’affaire ; c’est un arbre qui cache une forêt. Il faut ouvrir un autre tiroir de questions !

Des responsabilités multiples

En effet, l’automatisation des tests recouvre une multitudes d’activités, et l’implémentation des tests automatisés n’est qu’une d’entre elles.

Nous préconisons de réaliser une matrice des responsabilités (ou matrice RACI) afin d’établir, en amont du projet, qui interviendra sur quoi, et de répondre aux questions suivantes :

  • Qui choisira les tests qu’il faudra automatiser ?
  • Qui implémentera les tests automatisés ?
  • Qui lancera les tests automatisés ?
  • Qui analysera les résultats et rapportera les anomalies ?
  • Qui consommera les reportings des tests automatisés ?
  • Qui maintiendra les tests automatisés ?
  • Qui assurera la disponibilité des environnements dédiés aux tests automatisés ?
  • Qui produira les jeux de données nécessaires ?
  • (Et enfin, la question qui tue !) Qui sera responsable de la réussite de la démarche d’automatisation des tests ?

Il est important de répondre à ces questions, car elles permettent également de se rendre compte qu’il y a souvent plus de personnes qu’on l’imagine qui sont impliquées dans la démarche.

3) Quels tests faut-il automatiser ?

Pour trouver la meilleure liste de tests à automatiser, il faudra encore une fois se poser les bonnes questions.

Cette partie est dédiée aux 41 % qui peinent à établir une stratégie d’automatisation efficace !

Comme de bons tests prennent leur source dans de bonnes questions, voici celles que nous préconisons pour aider à définir le périmètre des tests automatisés :

Quels tests sont les plus critiques ?

Cette question est la plus évidente. Les tests révélateurs de la santé de l’application sont souvent les premiers que l’on souhaite automatiser. On les appelle les « smoke tests », par analogie à des tests que l’on ferait sur une machine industrielle par exemple : si vous appuyez sur le bouton de marche et que de la fumée sort de la machine, vous aurez détecté un bug bloquant en quelques secondes.

Quels sont les modules ou fonctionnalités qui, historiquement, sont les plus buggées ?

Cette question vaut surtout quand on initie tardivement le projet d’automatisation, et qu’il faut sécuriser les « nids à bugs ».

Quand on lance le projet d’automatisation en même temps que le projet de développement (une bonne pratique permettant de maximiser le ROI des tests automatisés), on peut se baser sur son expérience de projets similaires, puis étudier a fil de l’eau les modules où les bugs se concentrent.

Quels sont les tests les plus répétitititititi…tifs ?

Vous avez peut-être en tête ce formulaire qui compte 36 champs, ces champs pouvant être remplis de diverses manières, et chacune de ces manières devant être testée. L’œil est vigilant au premier remplissage, il persiste au deuxième, tient encore bon au troisième, puis il se perd, on ne sait plus ce qu’on a déjà rempli, on se trompe, on s’ennuie, et on a vraiment envie de passer à autre chose. Dommage, c’est à ce moment-là qu’on aurait pu détecter un joli bug.

Ces problèmes sont étrangers aux scripts de tests automatisés, c’est pourquoi les tests très répétitifs sont souvent de bons candidats à l’automatisation.

Quels sont les tests les plus rejouables ?

Il y a des tests qu’on ne peut jouer qu’une fois par an, qu’une fois par trimestre, ou encore une fois par jour. Il y a le fameux « batch de 4 heures du matin », la « moulinette du dimanche soir » et le « programme du 31 décembre ». Est-il vraiment intéressant d’automatiser les tests associés ? Pas sûr. Autant que possible, il est intéressant d’automatiser les tests facilement rejouables.

Quels sont les tests les plus difficiles à comprendre ?

Dans l’article précédent, nous parlions du fait que les tests automatisés constituent une documentation vivante du fonctionnement de l’applicatif. C’est un avantage quand ce fonctionnement est complexe. Un test difficile à comprendre sera peut-être mal effectué par un humain néophyte ; en l’automatisant, on se prémunit contre ce risque, et on donne en même temps plus de visibilité sur le fonctionnement précis du système à tester. Coup double !

Quels sont les tests qui seraient les plus faciles à implémenter ?

Il est souvent mal vu de commencer par le plus facile, de « choisir la facilité ». Ce n’est effectivement pas le premier critère à prendre en compte, mais la facilité d’implémentation est tout de même un élément important à avoir en tête. On veut des quick wins, pas des challenges insurmontables qui pourraient décourager l’équipe !

Synthèse des 6 questions

Comment utiliser efficacement ces 6 questions ? Afin de définir le périmètre à automatisés, il est nécessaire de :

  • Pondérer l’importance de chacune des questions
  • Répondre, pour chaque test ou suite de tests, à ces questions (sur une échelle de 1 à 5 par exemple)

En faisant une moyenne de ces scores, pondérée par l’importance des questions, on est alors en mesure de construire un périmètre à automatiser de manière solide et argumentée.

Chez Hightest, nous nous servons d’un modèle de tableur afin d’effectuer ce travail ; nous le partageons avec plaisir sur simple demande.

Tant d’autres questions…

Au sein de cet article, nous nous sommes concentrés sur QUI intervient dans la démarche d’automatisation des tests, et QUOI automatiser.

Nous pensons sincèrement que ces trois questions sont trop peu souvent posées, et que cela constitue une source importante d’échecs dans les projets d’automatisation des tests.

D’autres questions viendront ensuite, mais attention à ne pas mettre la charrue avant les bœufs ! En voici quelques-unes :

  • Quels KPI mettre en œuvre pour mesurer l’efficacité de la démarche d’automatisation des tests ?
  • Quelles mesures qualitatives surveiller en complément ?
  • Et le grand classique, la question qu’on a tendance à poser en premier et qui détrône toutes les autres… Quel outil choisir ?

« Quel outil choisir »… Il faudrait un article dédié (voire, plutôt, une série d’articles) pour répondre à cette question ! En attendant, voici quelques articles de notre blog qui vous donneront des éléments.

Nous espérons que cet article vous aura apporté des éléments utiles à votre démarche. A bientôt pour de nouveaux articles sur ce sujet passionnant qu’est l’automatisation des tests !

10 bonnes raisons d’automatiser les tests

Nos organisations reposent d’ores et déjà presque toutes sur des systèmes d’informations ou d’autres outils numériques sans qui elles ne peuvent clairement plus fonctionner correctement.

Au-delà des enjeux professionnels, quand une population entière repose sur un logiciel, les enjeux deviennent parfois des enjeux de santé publique (santé, énergie, télécommunication, etc).

C’est de cette dépendance aux outils numériques et aux risques associés qu’est née la notion de qualité logicielle et la discipline du test logiciel.

Pourquoi automatiser ses tests ?

Recettes à rallonge, coûts non maîtrisés, testeurs épuisés, résultats de test insatisfaisants, difficiles à interpréter, incomplets… Sortir une application ou un logiciel est trop souvent douloureux au sein des organisations.

L’automatisation des tests a le vent en poupe et fait fantasmer un avenir où les bugs seront gommés, sans aucun effort. Au-delà de l’utopie, de nombreuses raisons peuvent effectivement interroger sur la pertinence de cette démarche dans un contexte d’amélioration de sa qualité logicielle.

Vous êtes impactés au quotidien par la non-qualité et cherchez désespérément une solution pour limiter ses effets sur votre équipe et votre portefeuille ? Cet article liste 10 bonnes raisons d’engager une démarche d’automatisation des tests.

Les 10 raisons d’automatiser ses tests

L’automatisation des tests est une pratique susceptible de décupler l’efficacité des tests, de multiples façons différentes. Si l’on reprend le document de référence de la certification d’automatisation des tests A4Q Selenium Tester Foundation, ainsi que l’édition 2020-2021 du World Quality Report, les avantages de l’automatisation des tests sont les suivants :

#1 – Réduction du temps nécessaire à l’exécution des tests

C’est le plus évident, et le plus impactant pour les structures où les compétences et la charge coûtent cher, avec des délais pas forcément en adéquation avec les ressources ! Certaines vérifications longues et répétitives qui seraient effectuées en quelques heures par un humain, peuvent l’être en quelques secondes par un robot.

Le World Quality Report, qui se base sur 1750 témoignages d’entreprises du monde entier, tous secteurs confondus, a démontré que 65 % des entreprises constataient un réel gain de temps grâce à l’automatisation des tests.

#2 – Réduction des erreurs humaines

Lors de la répétition des tests de régression notamment (vous savez, ceux qu’il faut jouer et rejouer à chaque fois pour s’assurer que les nouveaux développements n’ont pas cassé les anciens !), des erreurs peuvent être commises par des testeurs lassés ou distraits. On ne peut d’ailleurs pas leur jeter la pierre, des biais cognitifs puissants sont à l’œuvre, qui rendent très difficile de se concentrer sur des tâches répétitives ! Par chance, les scripts de tests automatisés répètent inlassablement et minutieusement les mêmes actions, avec un meilleur résultat : 57 % des organisations constatent une meilleure détection des défauts grâce à l’automatisation des tests (World Quality Report 2020-2021).

#3 – Réduction des coûts alloués aux tests

La réduction des coûts : cette raison fait partie des motivations récurrentes pour se lancer dans l’automatisation des tests ; selon le World Quality Report, ce bénéfice est constaté par 62 % des organisations.

Attention, cela ne signifie pas que le test dit « manuel » soit rendu caduc par l’automatisation des tests ; simplement, l’automatisation va aider à se concentrer sur les tests des nouvelles fonctionnalités, tester de manière plus ciblée et plus créative.

#4 – Augmentation de la confiance envers le produit

Une version testée automatiquement permet d’augmenter la confiance que nous portons au produit. Ce niveau de confiance évoluera au fil du temps : les premiers tests automatisés permettront en quelques minutes de confirmer qu’une version est testable ; un arsenal plus complet pourrait aller jusqu’à justifier un déploiement continu.

#5 – Exécution de tests impossibles à jouer manuellement

C’est le cas, par excellence, des tests de charge ou de performance. L’automatisation rend presque infinie les possibilités de scenarios de test, sans à avoir à se soucier de la charge humaine.

#6 – Gain de valeur pour les testeurs humain

Eh oui, l’époque où les machines domineront le monde est encore loin. Néanmoins, libérés d’une partie des tests de régressions, les testeurs peuvent exécuter des tests manuels plus intéressants et plus complexes. Ils peuvent par exemple s’adonner à des sessions de test exploratoire, qui permettent de quadriller l’application à tester de manière ciblée et intelligente.

#6 – Exécution des tests plus tôt

Grâce à l’automatisation, les tests peuvent être exécutés plus tôt dans le processus. C’est typiquement le cas quand les tests sont joués dans la chaîne d’intégration continue ; si on le souhaite, dès que de nouveaux « bouts de code » sont déployés, immédiatement des tests sont déclenchés. Cela répond à un des 7 principes généraux du test logiciel : « Tester tôt » !

#7 – Tester en-dehors des heures de travail !

Il est satisfaisant de commencer sa journée sachant que des tests ont « tourné » pendant la nuit et qu’il n’y a plus qu’à analyser leurs résultats. En outre, il peut être commode de libérer un environnement en journée, pour n’y effectuer de tests que lorsque personne ne travaille dessus.

#8 – Augmentation de la fréquence d’exécution des tests

Le temps imposé aux tests peut contraindre à laisser certains cas de côté quand les délais sont courts ; les tests automatisés permettent d’éviter ou raréfier ces raccourcis. Ils permettent même d’augmenter le périmètre de ce qui est testé (c’est ce qu’on appelle la couverture des tests).

Selon le World Quality Report, 58 % des organisations interrogées constatent que l’automatisation des tests leur a permis d’augmenter la couverture de leurs tests.

#9 – Transparence accrue des activités de test

Les tests automatisés produisent des rapports de test générés à la volée, qui sont souvent partagés automatiquement aux parties prenantes concernées. Le niveau d’information est alors le même pour tout le monde et cela contribue à créer un climat de confiance au sein de l’équipe. Ce gain est constaté par 69 % des organisations interrogées pour le World Quality Report.

#10 – Création d’une documentation vivante

Les tests automatisés ne se contentent pas de constituer un inestimable filet de sécurité ; ils représentent aussi, à un instant T, une documentation fine de la façon dont une application est censée fonctionner. Convenablement mis à jour et versionnés, les tests automatisés gardent ainsi la trace des différentes façons de fonctionner du système concerné. Un bénéfice inattendu, qui peut s’avérer bien utile !

L’automatisation des tests, une pratique désormais standard

La discipline a déjà derrière elle des dizaines d’années, puisqu’il existait déjà des outils d’automatisation des tests à la fin des années 1990. Astra Quicktest, l’ancêtre d’UFT, un des logiciel d’automatisation des tests les plus connus, a été créé en 1998.

A ce jour, selon le State of Testing de 2020, 89 % des entreprises ayant une démarche qualité logicielle pratiquent l’automatisation des tests.

Bien que les formations initiales en automatisation des tests soient rares, il existe des certifications qui permettent de standardiser les pratiques. La certification A4Q Selenium Tester Foundation, créée en 2018, en est un bon exemple, de même que les certifications ISTQB Analyste technique de test et Automatisation des tests.

L’automatisation des tests est donc aujourd’hui une pratique fortement implantée dans le paysage de l’IT, et on comprend pourquoi.

Comment initier l’automatisation des tests dans ma structure  ?

Si vous souhaitez vous lancer, de nombreuses ressources sont disponibles pour vous aider. Nous recommandons la lecture du syllabus A4Q Selenium évoqué plus haut, car ce document fournit une première vue d’ensemble des problématiques propres à l’automatisation des tests.

Prochainement sur notre blog, nous partagerons des bonnes pratiques pour mettre en œuvre l’automatisation des tests au sein de votre structure.

Et surtout n’oubliez pas, la question n’est pas de savoir si l’automatisation fournit réellement des avantages, mais plutôt de savoir quels sont les objectifs que vous souhaitez atteindre au sein de votre projet en utilisant l’automatisation des tests. Tous les bénéfices ne s’appliquent pas, ou du moins pas immédiatement, à tous les projet. C’est en les ciblant spécifiquement que vous multiplierez vos chances de les atteindre !

A bientôt !

Crédit image : Miguel Á. Padriñán

7 principes généraux : oui, mais…

Dans le métier du test, les 7 principes généraux du test logiciel sont un peu comme les 7 nains de Blanche Neige ; sympathiques, familiers, on s’amuse parfois à tous les citer.

Toutefois, ces principes peuvent donner lieu à des extrapolations parfois dangereuses ; cet article vise à mettre en garde contre celles-ci.

Les tests montrent la présence de défauts… mais ils ne sont pas les seuls !

Les tests montrent la présence de défaut dans l’applicatif, et il est impossible de prouver l’absence de défaut. Très bien, vous connaissez maintenant ce refrain par cœur ! C’est d’ailleurs un refrain consolant, un peu comme « personne n’est pas parfait » ou « l’erreur est humaine ».

Et maintenant, si on changeait de perspective ?

Les défaillances d’un applicatif en production montrent la présence de défauts… dans les tests. Dans cette optique, il est logiquement impossible de prouver que des tests sont dénués de défauts, et sont parfaitement adaptés à une application.

Il est donc dommage de penser « Une défaillance a eu lieu en production, mais ce n’est pas notre faute, car les tests montrent la présence de défaut, pas leur absence. »

Il est plus utile de se dire « Une défaillance a eu lieu en production, les défaillances montrent la présence de défauts dans les tests ; corrigeons maintenant notre façon de tester. »

Comme le dit la locution, l’erreur est humaine, mais persévérer dans l’erreur est diabolique !

Les tests exhaustifs sont impossibles… oui, mais ne partons pas défaitistes

Ce deuxième principe, au même titre que le premier, peut être utilisé comme un bouclier pour contrer les attaques de décideurs ou de clients mécontents.

Les tests exhaustifs sont impossibles, certes. Le périmètre des tests est limité, car le temps alloué à la qualité est limité.

Mais ce temps est-il utilisé au mieux ?

Les tests exhaustifs sont impossibles, mais des tests pertinents sont possibles.

Tester tôt… oui, mais restons calmes

Il est important de tester tôt.

Il est important aussi de savoir quand il est trop tôt pour tester.

  • Un produit est en cours de réflexion. Des cas d’utilisation ont été écrits. Des réunions de brainstorming ont lieu régulièrement, les plans changent au fur et à mesure… Il n’est pas trop tôt pour se pencher sur une stratégie de test, voire sur un début de conception des tests, mais il est bien trop tôt pour rédiger les cas de test en détail.
  • Un MVP est en cours d’implémentation. Des interfaces sont disponibles. Cette première mouture donnera peut-être lieu à un projet à long terme, mais ce n’est pas sûr. Il n’est pas trop tôt pour réaliser des tests ad hoc, voire des tests exploratoires, mais il est beaucoup trop tôt pour se lancer dans l’automatisation des tests !

Le principe « Tester tôt » doit toujours être conditionné par l’exigence de « Tester utile ». Il est infiniment utile de décortiquer des spécifications avec un œil de QA avant l’écriture de la moindre ligne de code. Il est infiniment inutile d’écrire des tests qui ne seront peut-être jamais exécutés.

Les défauts se regroupent… oui, mais il convient de qualifier ces regroupements

Tu préfères rapporter 1 bug ou 10 bugs ?

Formulée comme ça, « la question elle est vite répondue ». Voici maintenant une variante :

Tu préfères rapporter 1 bug majeur qui importe vraiment aux parties prenantes, ou 10 bugs mineurs qui n’embêteront que toi et qui seront corrigés à la Saint-Glinglin ?

Quand on tombe sur un « nid à bugs », il est tentant d’y passer du temps et de remonter consciencieusement tout ce qu’on trouve anormal. Pour autant :

  • Tous les bugs ne se valent pas
  • Si certaines zones de l’application sont et restent buggées version après version, c’est peut-être qu’elles n’importent pas tant que ça

Autre point à noter : il arrive que l’on croie tomber sur un « tas de bugs », alors qu’il s’agit d’un même défaut qui provoque plusieurs défaillances.

Un champ entier d’orties est moins dangereux qu’un seul piège à loup.

Le paradoxe du pesticide existe… oui, mais cette image doit être bien analysée

Rappelons d’abord ce qu’est le paradoxe du pesticide, un principe qui n’est pas si simple à comprendre.

Qu’est-ce que cette histoire d’antimoustique ?

En France actuellement, l’été arrive, avec son lot agréable de soleil, sorbets et transats, et aussi son lot désagréable de moustiques.

Mettons qu’un laboratoire mette au point un antimoustique révolutionnaire, le Blanuin3000, qui dissuade 99,99 % des moustiques de piquer les humains qui s’en aspergent la peau. Cet antimoustique fait ses preuves, et pendant tout l’été les humains sont quasiment débarrassés des nuisances associées.

En parallèle, les 0,01% de moustiques résistants profitent d’un avantage certain : comme ils peuvent profiter des proies humaines, ils sont moins susceptibles de mourir de faim ou de manquer des éléments nutritifs qu’apporte le sang humain.

L’été suivant, une nouvelle génération de moustiques arrive. Certains ont légèrement muté, et ne sont plus indisposés par l’odeur du Blanuin3000. Quant aux descendants des 0,01%, ils sont un peu plus nombreux, grâce à l’avantage évoqué. Le Blanuin3000 n’est donc plus efficace qu’à 70 %. Scandale !

Le paradoxe est le suivant : on ne peut pas se contenter d’une solution, même si celle-ci est efficace à près de 100% à un instant T.

Le paradoxe du pesticide dans le monde du test

Mettons qu’un cas de test vérifie 100 configurations sur 1000 configurations possibles. Ces 100 configurations auront été sélectionnées pour être les plus représentatives possibles, par exemple en réduisant la combinatoire avec des techniques de type Pairwise.

A la première exécution des tests, 10 configurations sont en échec ; toutes donnent lieu à un correctif.

Après la découverte des bugs de la version 1 et leur correction, des tests unitaires ont pu être mis en place pour vérifier les cas ayant donné lieu à des défaillances ; il est donc extrêmement improbable de retrouver les mêmes défaillances sur les jeux de données. Il serait profitable de couvrir d’autres jeux de données, de même que le Blanuin3000 pourrait contenir de nouveaux principes actifs pour repousser encore plus de moustiques.

A la deuxième exécution, après correction, les 100 mêmes configurations sont vérifiées avec succès. Félicitations, enfin un « logiciel sans bug » ! Ou pas. La vraie question à se poser : parmi les 900 cas non testés, est-il possible que certains soient en mesure de trouver des régressions non identifiées par les tests existants ? Si oui, alors nous sommes face au paradoxe du pesticide.

Les araignées n’ont que faire de l’antimoustique

Bien que les bugs ne se multiplient pas à la manière des moustiques, ils se cachent parfois dans des jeux de données particuliers.

Mais quand un bug passe entre les mailles du filet, cela peut être à cause du paradoxe du pesticide… ou bien à cause d’une mauvaise conception des tests.

Le paradoxe du pesticide se comprend dans la durée ; de même, une régression est un écart qui se constate dans la durée, d’une situation A en succès à une situation B en échec.

  • Si une régression n’est pas détectée par des tests dont les jeux de données sont comparables, nous sommes en présence du paradoxe du pesticide. Il aurait été utile de modifier un peu les tests existants.
  • Si cette régression n’aurait pu être détectée que par un test spécifique, qui n’a jamais été imaginé, on est tout simplement face à un problème de conception des tests.
  • Si le bug n’est pas une régression, on ne peut pas parler de paradoxe du pesticide, tout simplement parce qu’il n’y a pas de notion de durée.

Bref : à chaque bug son pesticide. Modifier un test X ne sert à rien quand il faudrait écrire un nouveau test Y. Les deux prennent du temps : à quoi choisirez-vous de vous consacrer ?

Les tests dépendent du contexte… oui, mais « le contexte » n’est pas un mot magique

Avez-vous déjà participé à un projet adoptant des processus et méthodes brinquebalantes, utilisant des termes Scrum à tort et à travers, et dont les membres se félicitaient d’avoir mis l’agilité à leur sauce ? (Avant de se rendre compte quelque mois plus tard que cela ne tenait pas, et de conclure avec amertume que « finalement l’agilité ce n’est pas si efficace que ça »…) « Le contexte » est souvent pris comme excuse pour se laisser aller à des pratiques peu efficaces, mais qui offrent une satisfaction immédiate.

Quelques exemples :

  • « Nous avons adopté le cadre Scrum pour ce projet. Dans ce contexte, toute documentation doit être bannie. » Quelle mésinterprétation courante, et quelle aubaine pour les personnes qui détestent écrire de la documentation ! Rendez-vous quelques mois plus tard, quand de nouveaux devs arriveront et demanderont où sont le README et les règles de gestion détaillées.
  • «  Nous développons un produit interne, dans ce contexte nous n’avons pas besoin d’une interface responsive. » La bonne occasion d’économiser des bouts de chandelle et de râper un peu les coûts de développement. Rendez-vous à la mise en prod, quand les utilisateurs découvriront avec horreur qu’ils ne peuvent pas travailler en réduisant la taille du navigateur.
  • « C’est un petit projet, on n’est que 5 dans l’équipe Scrum. Dans ce contexte, on n’a pas forcément besoin de faire un daily tous les jours… »

En 1977, à Harvard, Ellen Langer a démontré le pouvoir du « parce que ». Un complice devait s’adresser à des personnes faisant la queue devant une photocopieuse en formulant une de ces deux phrases :

  1. « Excusez-moi, puis-je utiliser la photocopieuse ? »
  2. « Excusez-moi. Puis-je utiliser la photocopieuse parce que j’ai des photocopies à faire ? »

La première phrase a obtenu 60 % de succès, contre 93 % pour la suivante. Bien que totalement redondante, l’excuse « parce que j’ai des photocopies à faire » est quasiment aussi efficace que « parce que je suis pressé » (94 % de réussite).

De même que « parce que », le « contexte » semble agir comme un mot magique permettant de faire tomber les objections alors même qu’il reste très vague. Restons à l’affût : apprêtons-nous toujours à demander des précisions sur ce contexte, et interrogeons-nous nous-mêmes sur sa véritable signification au moment où nous invoquons cette raison.

L’illusion d’absence d’erreur est un risque courant… oui, et la responsabilité est partagée

L’illusion d’absence d’erreur est celui des 7 principes qui est le moins contestable. Non seulement il permet à chaque membre de l’équipe de garder un œil critique sur l’applicatif en cours de développement, mais il permet aussi de guider les tests. L’illusion d’absence d’erreur met le focus sur les utilisateurs finaux et leurs besoins réels ; avoir à l’esprit ces personnes à tout moment nourrit la conception et la priorisation des tests.

Cette notion gagne à être connue ; elle n’est pas seulement un principe général du test logiciel, mais de manière plus large, un principe général du monde de l’IT.

Et vous, avez-vous déjà constaté des dérives possibles des 7 principes généraux des tests logiciels ? Si oui, indiquez-les en commentaire !

Autres articles sur les 7 principes généraux

[Invité] Un jeu pour sensibiliser à l’importance de la stratégie de test

Aujourd’hui, le blog Hightest a l’honneur de donner la parole à Antoine Brebant, test leader chez Open, qui a mis au point un astucieux atelier gamifié permettant de sensibiliser aux problématiques de stratégie de test et de test basé sur les risques. Un grand merci à lui pour l’inventivité de cet atelier, que nous avons pu nous-mêmes expérimenter : la démonstration est brillante et extrêmement efficace. Bonne lecture !

Objectifs du jeu

Des articles de gamification ont déjà été publiés sur le blog Hightest, notamment la fiche explicative d’un jeu de carte. Ce jeu, je l’ai repris puis adapté sur Klaxoon, une suite d’outils collaboratifs numériques, et c’est ce qui m’a donné l’idée de concevoir d’autres jeux sur Klaxoon. Il est bien sûr possible de mettre en œuvre le jeu présenté aujourd’hui sur un autre support que Klaxoon, aussi bien au format numérique que physique.

Dans certaines organisations et équipes projet on agilise à tout va, en oubliant parfois que l’agilité demande de la méthode et qu’il ne faut pas négliger les fondamentaux du test. Parmi ces fondamentaux, il y a les stratégies de tests ! Une stratégie de test permet de guider l’effort de test tout au long du projet et apporte un cadre précieux. Il est important que les décideurs comprennent précisément l’intérêt d’un tel outil.

Le jeu présenté ici permet de sensibiliser à cette problématique. Il va être question de repérer non pas des anomalies, mais des bateaux ! Je me suis inspiré du blog de Nick Berry et j’ai conservé le modèle en deux parties utilisé dans le jeu de cartes d’Hightest 😉

Le jeu : « Le défi de l’Amiral »

Nombre de joueurs

Entre 2 à N. Idéalement limiter entre 4 et 10 personnes par instance Klaxoon. La limite réside dans le nombre d’animateurs/facilitateurs.

Matériel

En physique, un jeu de bataille navale par table, le facilitateur d’un côté, les joueurs de l’autre.

En distanciel, Klaxoon ou tout autre support vous permettant de reproduire le fonctionnement.

Naturellement, il faut de quoi expliquer/montrer les règles aux participants (présentation PowerPoint ou Meeting dans Klaxoon).

Voici à quoi ressemble votre terrain de jeu !

Déroulement du jeu

La partie se déroule presque comme une vraie partie, à ceci près que le facilitateur ne joue pas vraiment mais a plutôt un rôle de maître du jeu. Le but est très simple, il faut que les participants découvrent tous les bateaux cachés ; à la fin, on comptabilise le nombre de coups dans l’eau.

En moyenne, dans une partie « standard » (positionnement aléatoire et connaissances de base du jeu), il faut 77 coups, soit 60 ratés et 17 touchés, pour trouver tous les bateaux.

Dans Klaxoon, chaque case est une image verrouillée. Et derrière chaque case, il y a une icône elle aussi verrouillée. Les joueurs ont toutefois la possibilité de reculer la case mer pour faire apparaitre l’icône qui se cache derrière.

Tout est préparé à l’avance et tout est donc transparent : impossible pour le facilitateur de tricher ! 😉

Première session

Vous l’aurez peut-être déjà compris, la première session sert d’étalonnage et devrait permettre de confirmer la jauge des 60 coups ! 😉

Pour beaucoup de participants, les souvenirs de parties de bataille navale seront lointains ; il y a relativement peu de chances que cette première session donne des résultats fameux.

Entre les deux sessions

Avant la seconde session, il faut expliquer l’approche statistique de Nick Berry qui permet de descendre à une moyenne de 44 coups pour trouver tous les bateaux.

Nick Berry a en effet conçu un modèle qu’il nomme chasse (hunt) et ciblage (target).

La méthode la plus efficace conçue par Nick Berry utilise une fonction de densité de probabilité, qui prend en considération les différentes manières dont les cinq navires peuvent être déployés sur le plateau. L’algorithme de Nick Berry considère toutes les configurations possibles des cinq navires et calcule la probabilité, pour chaque case, d’être ou non occupée par un navire.

En début de partie, il y a de fortes chances de toucher un navire en ciblant le milieu.

Ensuite l’algorithme de Nick Berry calcule coup après coup l’évolution des statistiques.

Pour le jeu, j’ai simplifié le modèle en définissant un schéma de zones à risques inspiré de la méthode de Nick Berry et de ma propre expérience de ce jeu, dont je connais presque toutes les positions stratégiques. Mon record personnel à la version électronique : seulement 31 coups pour gagner.

La première phase de la méthode de Nick Berry est la « chasse », voici un exemple d’utilisation du modèle sans les bateaux :

Cela consiste à parcourir les zones en commençant par la zone en rouge puis allant progressivement vers le blanc jusqu’à trouver un navire.

C’est là que la seconde phase entre en jeu : celle de « ciblage ». En effet, le comportement va changer lorsque l’on va toucher : les cellules proches vont devenir plus intéressantes.

Enfin, voici un exemple de positionnement de navires et d’application de la méthode en simplifié :

Ici en utilisant la méthode de chasse et ciblage décrite précédemment, on trouve tous les navires en 41 coups malgré plusieurs coups dans l’eau !

Deuxième session

Une fois ces explications faites, la seconde partie se déroule comme la première mais avec un calque :

En physique, vous pouvez appliquer une feuille de papier calque avec le schéma ci-dessus et les trous prépositionnés.

Voici des exemples de positionnement de bateaux pour la seconde partie :

Normalement les joueurs devraient trouver vos bateaux plus rapidement… enfin, s’ils ne perdent pas de temps sur la première diagonale, qui a été évitée par fourberie xD !

Conclusion

J’ai emprunté cette image sur le blog ezyang, que j’ai traduite et très légèrement modifiée pour faire le parallèle entre :

  • l’océan et une application
  • les bateaux et les anomalies
  • les missiles et les tests
  • l’approche statistique et une stratégie de test 😉

Pour finir, il ne reste plus qu’à élargir le propos avec les différentes approches et stratégies de tests mentionnées dans le syllabus ISTQB de niveau fondation :

Connaître et combiner ces approches permet de concevoir des stratégies pertinentes rendant vos campagnes de test plus efficaces. De manière plus globale, être initié au contenu des syllabus ISTQB et en particulier du syllabus fondation permet aux membres d’une même équipe d’être plus efficace dans la recherche de la qualité !

Le mot de la fin, un grand merci à Zoé Thivet pour nos échanges, ses articles et ses interventions avec une approche innovante et inspirante.

Merci à mes collègues, Nelly, Emmanuelle, Tony et Alexandre qui ont bien voulu servir de cobayes pour ce jeu.

Merci enfin à Hightest de me permettre de publier ce billet sur leur blog.

Sources

https://datagenetics.com/blog/december32011/index.html

http://blog.ezyang.com/2011/12/bugs-and-battleships/

https://cliambrown.com/battleship/

L’auteur

Antoine BREBANT – Test Leader pour le groupe OPEN – 19 ans d’expérience dont 12 ans dans le test logiciel

  • Certifié ISTQB fondation et extension testeur agile
  • Certifié ISTQB niveaux avancés tests manager et automatisation des tests
  • Certifié IREB niveau fondation
  • Principaux Clients : SFR, Orange, Cedicam, BioMérieux
  • Lead Practice Testing OPEN région Est et Lyon
  • Animateur d’ateliers ludiques pour la Practice Testing
  • Formateur aux Fondamentaux du Tests (formation transposée dans Klaxoon)