J'ai porté plusieurs casquettes dans ma carrière : développeur frontend, backend, chef de projet, scrum master, expert Wordpress... et aussi QA Manager ! Honnêtement, je ne sais pas trop comment je me suis retrouvé là, mais j'ai fini par passer presque 4 ans dans ce rôle.

Finalement, avec cette expérience, j'ai appris pas mal de choses sur la qualité, et je ne peux plus vraiment me permettre de pousser du code sans tests. 😅

Bref, au moment de clore ce chapitre de ma vie, je voulais partager avec vous, dans cet article, ce que j'ai appris pendant ces années en tant que QA Manager. Les trucs bien, les trucs moins bien.

Qu'est-ce qui m'a amené dans le monde de la QA

J'ai choisi un poste de QA avant tout pour rejoindre une entreprise en particulier, pour ses valeurs, sa culture et sa façon de travailler (100% télétravai).

J'avais la possibilité d'aller vers un rôle de Product Owner, mais comme je l'avais déjà fait, j'ai décidé d'explorer quelque chose de différent. Je suis tout autant un personnage curieux qu'un curieux personnage. Je n'avais encore jamais été QA, alors j'y suis allé.

Le rôle de QA a la particularité d'être à cheval entre le métier et la technique. Et moi, qui avait envie d'explorer l'agilité sous toutes ses formes, ça m'a tout de suite branché.

Les enjeux clé de la QA

Alors pour rappel, la QA, pour Quality Assurance, désigne toute pratique visant à vérifier qu'un produit est "conforme". C'est-à-dire :

• Qu'il fait ce qu'on attend qu'il fasse
• Qu'il satisfasse les exigences
• Qu'il n'y ait pas de bugs ou d'anomalies

On pense toujours aux bugs en premier. L'idée qu'on se fait des "testeurs" qui composent l'équipe QA, c'est qu'ils jouent un peu avec le logiciel que les développeurs ont fourni, et qu'ils notent tous les bugs qu'ils trouvent.

Pourtant, une des grosses missions de ces équipes, c'est de faire en sorte de les éviter, le plus possible. Et ça commence en amont.

La communication

La communication, c'est selon moi le gros truc de la QA, à mettre tout en haut. Et en fait, c'est vrai aussi dans le développement, ou la MOA (Maîtrise d'Ouvrage).

Un des gros problèmes dans le monde du développement logiciel, en général, c'est, selon moi, la définition du comportement attendu.

Pour une équipe QA en particulier, ça pourrait se résumer avec cette phrase : "Qu'est-ce qui doit être testé ?".

Tout ça passe par une communication entre les équipes de PO¹ ou d'AMOA² et les équipes techniques. Le gros boulot du QA, à ce moment-là, est donc d'être un facilitateur dans les discussions préalables au démarrage des développements, pour expliciter ce qui doit être testé, lever au maximum les ambiguïtés, et faire en sorte que sa propre impacte sur la suite du projet soit la plus faible possible. C'est-à-dire, qu'il ait le moins de bugs à remonter après la livraison de la feature.

L'un des débats, tout à fait légitime, que j'ai pu avoir avec ma direction, portait sur le fait de ne pas faire intervenir la QA trop tôt dans le processus. Effectivement, il faut tester quand c'est testable, mais avant même les premiers travaux, la QA peut participer à vérifier que les spécifications répondent aux critères de qualité attendus. C'est d'autant plus vrai dans un contexte agile. À ce titre, la séance des 3 amigos est un outil apprécié pour compléter la spécification et lever les ambiguités.

Et comme un exemple vaut mieux qu'une longue explication, imaginons une équipe agile composée d'un PO, d'un QA et de plusieurs développeurs. Comme c'est une équipe disciplinée et bien élevée, le workflow prévoit plusieurs étapes entre le moment où l'US est imaginée et le moment où elle est prête à être développée par l'équipe. Le PO crée donc son ticket d'US, qui exprime son besoin, son incrément produit, qu'il va ensuite faire passer dans une séance de 3 amigos, qui va viser à creuser le sujet entre PO, Développeur et QA. Cette séance est animée par le QA, qui joue là son rôle de facilitateur, et permet d'obtenir en bout de ligne tous les tests d'acceptation. Après cette séance, l'équipe, qui aura une meilleure vision, va pouvoir faire son estimation, avant que le ticket arrive enfin dans la colonne "PRÊT".

Vous trouvez ça long ? Si vos process amènent les tickets plus rapidement que cela dans l'étape du développement, alors vous avez sans doute des problèmes ailleurs dans votre flux de travail.

La communication ne s'arrête pas là. Si vous êtes amené à être testeur, je vous encourage à parler directement avec l'auteur du ticket que vous allez tester. Et je dis bien parler, pas échanger 2 messages du genre "Comment je test lol?". N'hésitez pas à tester avec lui. Ça fait économiser un temps incroyable et en plus, cette communication directe va peut-être vous permettre de voir des choses que vous n'auriez pas vues.

Le testeur, c'est avant tout quelqu'un qui échange avec les autres.

La stratégie de tests

Bien, maintenant qu'on sait qu'il va falloir communiquer, on va pouvoir parler de la fameuse Stratégie de test.

Alors, comme je suis autodidacte, j'imagine qu'il doit exister des cadres bien précis pour ces questions-là, mais sur le terrain, ce que j'en retiens, c'est qu'il faut s'entendre sur :

• Qui décide de ce qui doit être testé ? Typiquement, certaines parties du logiciel peuvent être plus critiques que d'autres. Qui est capable de l'identifier correctement ? Quel est le niveau de couverture souhaité ?
• De quelle manière et à quel moment les choses doivent être testées ? Avant ou après avoir versé le code sur le tronc commun ? Sur quels types d'environnements ?
• Qui rédige effectivement le ou les tests ? Le QA tout seul ? Le PO pour les tests d'acceptation ? Un peu tout le monde ?
• Quelle approche est-ce qu'on adopte pour les tests ? BDD ? ATDD ? Quelle différence ?
• Qu'est-ce qu'on fait si c'est non conforme ? Est-ce qu'on reporte la date de livraison ? Pour tout types de problèmes ?
• Quels niveaux de tests est-ce qu'on met en place ? (voir plus bas)
• Qu'est-ce qu'on automatise et qu'est-ce qu'on automatise pas ?
• Qu'est-ce qu'on fait avec la suite de tests qu'on a écrit, une fois qu'on a livré la nouvelle feature ? Où est-ce qu'on la garde, comment on fait en sorte de pouvoir la rejouer au besoin dans le futur ? D'ailleurs, à quel moment on déprécie nos tests (manuel et auto) ?

Je vous jure que cette dernière partie est un enfer. On a perdu un temps fou à tenter de rentrer notre patrimoine dans un logiciel qu'on a sous-utilisé, des tests qu'on a écrit sous des formes assez varié, ça a donné un patrimoine compliqué à réutiliser et très couteux à maintenir. Sacré chantier, et pas le plus passionnant.

Du coup parlons plutôt d'un sujet un peu plus sympa.

Les niveaux de test

En débutant dans le métier, j'avais déjà une vague idée des différents types de tests, mais niveau nommage, c'était flou. Et pour cause : le vocabulaire utilisé dans le monde du développement web, sur ce sujet, est flou, de base. Selon le contexte, selon les gens, parfois selon le framework, on va utiliser le même mot pour désigner des choses différentes. Si on s'entends a peu prêt bien sur les Tests Unitaires (et encore...), les tests d'intégration vont parfois simplement désigner un test à plus haut niveau sur une brique logiciel, pour s'assurer que le code fonctionne bien avec le reste de l'application, quand d'autres vont plutôt penser à l'intégration de la brique logiciel avec les autres briques.

Les tests de l'interface peuvent être confondus avec les tests e2e, bien qu'ils aient tous les deux un rôle vraiment différent des tests e2e. Mais bon, certains frameworks Javascript parlent de tests e2e pour de l'outillage qui permet surtout de faire du test d'interface (mockez vos API, ceci est un ordre).

Il existe un graphique bien pratique pour illustrer les niveaux de tests, et mettre en avant le fait qu'il faut plus de tests de bas niveaux que de tests de haut niveaux.

Comme j'ai ajouté la gestion des images sur mon blog, et que je fais des graphiques vraiment dégueulasse, je vous partage ce graphique :

Eh bien, faites quand même une recherche Google sur "pyramide des tests" (allez, je suis pas chien, cliquez ici). Vous remarquerez que pas une pyramide n'utilise exactement le même vocabulaire que les autres. C'est pas mal lié au fait que ça dépend en réalité beaucoup du socle technique utilisé. Sur un bon vieux code source interprété, on va pouvoir faire des tests unitaires super facilement, mais j'imagine que sur des gros environnements intégrés, avec du code compilé, le test de plus bas niveau ne sera pas le même.

En tout cas, ce qu'il faut retenir, c'est que les tests de bout-en-bout seront plus lents à executer. Ils demandent un déploiement complet de l'application et simulent un comportement humain, des clics, etc. Ils vont donc dépendre de la vitesse de la requête réseau, des animations éventuelles, etc. Donc c'est lent, et en plus, c'est pas forcément fiable. Sur de très long runs, vous n'êtes pas à l'abri d'un problème avec le navigateur par exemple. Notre équipe avait un nightly qui prenait jusqu'à 10h à s'executer entièrement, pour un faible niveau de couverture. Donc, il faut toujours privilégier des tests de plus bas niveau. Si on cherche à voir si un composant se comporte comme on l'attend en fonction des retours faits par l'API : on fait un test d'interface en mockant l'API. Si on cherche à savoir si l'API répond correctement quand on lui soumet des données : on fait des tests d'API. Etc.

Tant que j'y suis, je vais évoquer très rapidement le quadrant de test agile : Il ne sert à rien. Voilà.

Outillage

Une fois qu'on a tout ça, c'est comme quand on vient de passer sa visite médicale qui nous autorise à la pratique du lancer de marteau : on s'équipe !

À commencer par l'outil pour la rédaction de test (X-Ray pour JIRA ou SquashTM par exemple).
Puis les outils pour exécuter les tests : là, il est plutôt question d'environnements de test, qu'il faut pouvoir mettre à jour avec le code à tester (en général ce sont plutôt les DevOps qui s'occupent de ça).

Les outils d'automatisation. Historiquement, c'est souvent Selenium qui est choisi, avec un framework qui va bien par-dessus. Mais Cypress fait largement parler de lui, on peut dire qu'il est à la mode. Si on pratique le BDD, on aura peut-être envie d'utiliser un framework qui permet de jouer les tests au format Gherkin : les différentes implémentations de Cucumber répondent à ce besoin (Cucumber pour Java, JS ou Ruby, Behate pour PHP, Behave pour python, et on m'a parlé de pytest-bdd qui fait ça avec pytest, ce qui présente potentiellement des avantages).

Cypress, c'est sympa, ça permet à des tas d'équipes QA de tester en boite noire. Mais ne négligez pas les outils proches de vos frameworks, s'ils existent. Par exemple, en Django, utiliser Behave et une de ses extensions behave-django ou django-behave (quelle histoire...) présente de gros avantages, avec un couplage avec le code qui permet de bénéficier ouf-of-the-box des bases de données de tests et des systèmes de fixtures de Django.

C'est-à-dire qu'on veut que le test, en lui-même, se fasse en boite noire, mais la mise en place des conditions du test, elle, c'est une autre histoire.

Bon après, si la pile technique utilisée dans votre projet ne prévoit rien pour le test, tester en pure boite noire avec une techno totalement décorrélé fait très bien l'affaire. Il peut y avoir tout un tas de raisons qui peuvent amener à cette situation, qui n'a rien d'exotique.

Voilà, ça fait un assez long paragraphe pour parler de choix du marteau. Passons à la suite.

Le rôle du QA

On a parlé de l'équipe QA jusque-là, et tout ce qu'on a dit aurait pu être du ressort d'une seule personne. Mais, comme le dirait si bien Ronaldo : "Les QA, c'est comme le ketchup : quand ils arrivent, ils viennent tous en même temps".

Alors, qu'est-ce qu'ils font, ces membres de l'équipe QA, dans l'organisation ?

Je pense qu'il ne faut pas voir l'ingénieur QA comme "quelqu'un qui va écrire beaucoup de tests et les automatiser". Oui, il va avoir un rôle de validation / exploration, au même titre qu'un développeur et qu'un PO d'ailleurs, avec son regard particulier, orienté à 100% sur la qualité. Mais, ça ne représente qu'une partie de son travail. Si le souci de la qualité est descendu suffisamment bas, alors cette partie-là ne devrait pas nécessiter trop de temps.

Comme je l'ai dit, le QA va avoir un rôle de facilitateur. Il va permettre de mettre en lumière très tôt où se situe le risque, favoriser l'échange au sein des différents rôles dans l'équipe.

Il va préparer des réunions visant à lever les ambiguïtés. Il va aller vers le développeur pour essayer de comprendre la raison qui a amené à la présence d'un bug pendant le développement, et réfléchir à améliorer les choses pour éviter les mêmes problèmes à l'avenir. Il va faire en sorte que les développeurs et les PO puissent s'approprier les outils de tests, les rapports de tests, pour être autonomes et pouvoir contrôler eux-mêmes la qualité. Il fait la promotion de la qualité. Etc.

D'ailleurs, je suis persuadé qu'un QA qui a la fibre agile peut aussi faire un très bon Scrum Master en parallèle de son rôle. (Scrum Master n'est pas et ne sera jamais un rôle à temps plein, il y a un formulaire de commentaire pour m'expliquer le contraire en bas de cette page)

Les pièges à éviter

Le rôle du QA au sein de l'organisation

Le rôle de QA peut être un rôle compensatoire. Par exemple :

• Si vous ne disposez pas de PO dans votre équipe (ou de qui que ce soit qui écrit de la spécification), alors le QA ira naturellement remplir ces tâches-là, parfois rétroactivement. Ce qui fait perdre un vrai temps.
• Si les développeurs livrent sans tests automatisés, et qu'on fait porter tout le poids de l'automatisation sur l'équipe QA, alors le QA peut vite se retrouver à être un développeur de tests (on appelle ça un automaticien) toujours en retard, dans le sens où les tests automatisés devraient être livrés en même temps que le code. (Note : si vous faites du test auto au niveau de l'équipe de développement, ça n'empêche pas l'équipe QA de rédiger du test d'acceptation automatisé après livraison, mais dans un but bien différent)
• L'équipe peut facilement adopter le comportement suivant : "Je livre vite des trucs et les testeurs me diront ce qui ne va pas". C'est une mentalité assez contre-productive. Je ne vais pas vous mentir, je l'ai déjà fait en tant que développeur. Maintenant, je sais à quel point c'est moche.
• Si votre organisation est plutôt réactive que proactive, l'équipe QA peut se retrouver à gérer des bugs en production, et donc faire beaucoup de Support. Il manque peut-être du helpdesk de niveau 3 dans votre organisation. L'équipe QA a un rôle à jouer avec les tickets de bugs clients, mais ce n'est pas spécifiquement à eux de traiter les entrants.

Un bon indicateur pour savoir si quelque chose cloche, c'est le ratio développeur/QA dans la boite. Je ne crois pas qu'il y ait de règle absolue. Après tout, chaque organisation est différente et les personnes au sein de cette organisation font peut-être d'autres choses. Mais, si le ratio se rapproche de 1 pour 1, ou même 1 pour 2 en vérité, il y a peut-être un truc qui cloche, et vous êtes peut-être dans une des situations citées plus haut. Le ratio qu'on prend souvent en référence est de 1 QA pour 3 à 5 développeurs.

Évidemment, tout cela n'est que mon avis d'agiliste.

Dans le métier du testeur

Concernant le monde du test en général, je dirais que le plus gros souci avec lequel j'ai dû jongler concerne l'indépendance des tests, et la prise d'abstraction suffisante au moment de rédiger son test. Je m'explique : quand on fait un test, on se met dans une condition initiale, un jeu de données de départ, qu'on précise en partant. Entre chaque test, on est censé revenir à cette situation initiale. Les tests doivent être indépendants entre eux. Cet engagement n'est parfois pas évident à tenir techniquement, ce qui peut amener l'équipe à faire des choses bizarres.

Illustrons le problème par l'exemple :

Scénario : Ajouter un items
Etant donné que j'ai 4 items présent dans la base de données
Quand j'ajoute un item
Alors j'ai 5 items dans la base de données

Scénario : Supprimer un item
Etant donné que j'ai 5 items présents dans la base de données
Quand je supprime un item
Alors j'ai 4 items dans la base de données

Plusieurs problèmes ici :

• On part du principe qu'on a 4 items au départ dans la base. Peut-être que c'est le jeu de données de départ. Le jour où on change ce jeu de données, il faudra repasser sur tous les tests qui explicitent ce chiffre.
• Le second test prend en compte le fait que le premier a ajouté un item. Qu'est-ce qu'il se passe si on doit jouer ce test de manière isolée pour le tester ? Ou si on supprime le test du dessus ? Le test casse.

Ça a l'air de rien, mais sur un patrimoine de plusieurs milliers de tests, ça pose vite un problème.

On préfèrera donc adopter une approche plus agnostique :

Scénario : Ajouter un items
Etant donné que j'ai un certain nombre d'items présent dans la base de données
Quand j'ajoute un item
Alors j'ai un item de plus dans la base de données

Scénario : Supprimer un item
Etant donné que j'ai au moins 1 item présents dans la base de données
Quand je supprime un item
Alors j'ai 1 item de moins dans la base de données

Dans le premier scénario, le nombre d'item peut-être égal à 0, à 4 ou à 5000, dans tous les cas, on commence par regarder combien il y en a, et à la fin, on s'assure qu'il y en a un de plus.

Dans le second scénario, on s'assure qu'il y a au moins 1 item dans la base. Si ce n'est pas le cas, on va le créer pour le test.

Ça semble facile, mais encore une fois avec un patrimoine de plusieurs milliers de tests, faire cohabiter ce genre de scénarios avec d'autres est vite compliqué.

Qu'est-ce qui cloche avec la QA

Pourquoi, alors que j'ai acquis une certaine expertise sur le sujet, est-ce que je ne suis plus dans une équipe QA et que je n'ai pas prévu d'y retourner ?

Si je devais retenir une seule raison : la qualité est l'affaire de tous !

C'est-à-dire que j'ai l'occasion de faire de la qualité dans chaque rôle que j'occuperai à l'avenir. Comme je l'ai dit, le QA est un facilitateur, mais la qualité doit reposer sur l'ensemble de l'équipe.

Dans un contexte agile, j'ai tendance à penser que l'on a tous l'occasion de remplir ces tâches. Si je devais monter une équipe agile demain, je ne suis même pas certain d'y mettre un QA. Les tâches peuvent être remplies par l'ensemble de l'équipe. Selon moi, l'ingénieur QA est un ingénieur en développement logiciel spécialisé.

L'autre gros point noir, à mon goût, c'est la place qui est encore faite aux équipes QA. Les profils des testeurs peuvent être variés, avec des approches tantôt fonctionnelles, tantôt techniques, mais le ressenti global que j'ai eu, c'est que les QA sont généralement mal considérés. Ils ont la réputation de ne pas être assez technique d'une part, de ne pas être assez métier d'autre part. Leur rôle est mal compris. J'ai vécu ces fins de projet où l'ont dit : "bravo le développeur pour la feature, bravo le PO et merci à la QA", comme si le QA était le seul de la chaîne à ne rien avoir produit. Et, pourtant, j'en ai soulevé, des trous dans la specs, des oublis dans l'implémentation.

Il y a aussi ce truc, quand un bug passe en production sans qu'on le voie. Cette impression que les gens se disent : "bah, ils sont payés à trouver les bugs, ils n'ont que ça à faire, comment ça se fait qu'ils n'y arrivent pas ?".
Je n'ai jamais réussi à trouver le truc, en termes de communication, pour valoriser un peu le travail effectué. Parler de l'évolution du patrimoine de test était trop abstrait, dire "on a testé ce que les développeurs ont fait" sans intérêt. Parler des projets d'outillage trop "fil rouge".

Après 4 ans dans ce rôle, j'avais aussi l'impression d'en avoir fait le tour. Et, pour appuyer un peu mon point sur la valorisation du métier, j'ai pu sentir à quel point ça pouvait nuire à ma carrière de rester sur ce rôle, dans la mesure où j'ai envie de garder un pied sur une sphère technique. J'ai eu droit à des "ça fait 4 ans que vous ne faites plus de développement, vous devez être rouillé", des "ha bon, tu as été testeur ?!" un peu condescendant.

Pourtant, l'expérience que j'ai eu a contribué à faire de moi un meilleur développeur, un meilleur concepteur. J'ai eu la chance de bosser dans une boite qui a fait de la qualité un de ses chevaux de bataille, qui a obtenu de super résultats, j'ai travaillé avec une super équipe. On a pu faire bouger beaucoup de choses. J'ai développé de l'outillage python qui n'a rien à envier à ce qui peut se faire dans certains produits destinés à être commercialisés.

Donc pour tout ça : So long, and thanks for all the vegetables.³

[1] : Product Owner
[2] : Assistance à Maitrise d'Ouvrage
[3] : Les légumes font références aux comcombres et aux cornichons