Regards croisés sur la double casquette Test Analyst & Business Analyst de Rémy !

Rémy Dupilet, testeur chez SSID depuis 5 ans, nous partage son retour d’expérience sur une mission singulière chez son client : un rôle hybride mêlant l’exigence de la Qualité Logicielle (QA) et la vision stratégique du Business Analyst (BA).

Rémy, peux-tu te présenter et nous retracer ton parcours en quelques mots ?

Je suis QA depuis 5 ans chez SSID. Mon parcours est marqué par une reconversion en plein confinement dans la Qualité Logicielle où j’ai pu être formé en distanciel. Après une première mission en automatisation d’API, j’ai rejoint une autre entreprise en tant que Test Analyst fonctionnel. Depuis 2024, je suis en mission chez mon client avec un rôle hybride entre Business Analyst et Test Analyst car la mission ne permettait pas d’avoir un QA à 100% sur le périmètre. 

Quelle est la mission spécifique dont tu souhaites nous parler aujourd’hui ?

Il s’agit d’une mission calibrée à 70% QA et 30% BA. À mon arrivée, un nouveau sujet venait de démarrer : la traçabilité écologique des commandes. J’ai pris en charge ce périmètre qui s’articulait autour de la récupération de données de consommation environnementale des fournisseurs et des sous-fournisseurs. J’ai découvert cet aspect d’analyse et j’ai grandi en même temps que le sujet dans l’équipe.

Je suis devenu l’interlocuteur de référence sur ce sujet auprès des métiers et des Business Analysts qui se situent en Asie, pilotant notamment des points hebdomadaires en anglais avec un collègue en Inde.

Pour ces deux casquettes qui étaient pour moi une découverte, J’étais tout de même soutenu au quotidien par un autre membre de l’équipe, expérimenté sur le poste de BA, afin de m’assurer que ce que je réalisais était en phase avec les attentes.

Comment définirais-tu ce rôle de Business Analyst dans ton quotidien ?

En théorie, un Business Analyst seconde le Product Owner (PO) pour rédiger les spécifications demandées par le métier. Dans les faits, j’agissais presque comme un PO : je recueillais les besoins directement auprès du métier, je rédigeais les tickets et j’animais les échanges avec les équipes de développement.

À quoi ressemblait une semaine type avec cette double casquette ?

J’étais en position de QA sur le sprint, mais je m’organisais des temps de travail en tant que Business Analyst. 

Une fois par semaine, je passais en mode BA pour les réunions de cadrage, puis pour ne pas être parasité par les demandes de test, je me bloquais des créneaux de 3 ou 4 heures par semaine pour traiter mes sujets BA.

Le reste du temps j’étais QA dans l’équipe, où l’on testait sur 4 périmètres principaux où les applications sont fortement liées entre-elles.

Ce n’est pas facile de jongler entre les deux rôles qui demandent des réflexions différentes, il faut savoir détacher les deux postes pour être 100% objectif et prendre les bonnes décisions.

Cette vision « métier » a-t-elle changée ta façon de tester ?

Absolument. Le contact direct avec le métier supprime les intermédiaires : les demandes sont plus claires dès le départ et je comprends tous les sujets.

En rédigeant les spécifications avec ma casquette de testeur, je sais déjà exactement ce qu’il faudra valider.

J’intègre les contraintes techniques discutées avec les développeurs directement dans la spec, ce qui devient un guide précieux pour mes futurs tests.

Parfois, il y avait quand même quelques demandes complexes qui demandent de la réflexion plus technique. Dans ces cas là,  je n’ai pas hésité à demander de l’aide aux équipes pour savoir ce dont ils avaient vraiment besoin pour être carré dans les specs.

Dans certaines situations, la casquette BA était difficile à conserver car je rédigeais mes specs à la manière de cas de test (Gherkin) et ce n’est pas la meilleure solution pour faire comprendre les besoins aux équipes.

Avec le recul, tu as aimé cette mission ? Qu’est-ce que cela t’a apporté d’avoir une double casquette ?  

J’ai adoré travailler avec l’équipe et dans le large périmètre de la mission, mais j’ai préféré la vision QA que celle de BA. Dans les faits, je n’avais pas d’expérience comme BA, j’ai énormément été épaulé par l’équipe et par un autre BA avec plus d’expérience qui pouvait répondre à mes interrogations.

La double casquette m’a challengé sur mes compétences et ma capacité à m’améliorer dans mon travail. Cette expérience m’a appris à gérer le côté métier, à répondre correctement au métier en ayant en tête les capacités de l’équipe.

Aujourd’hui, je sais estimer la charge de l’équipe et le temps que chaque US prendra à réaliser. J’ai aussi appris à mieux communiquer avec d’autres personnes que celles de mon équipe, car en tant que QA, on n’est pas forcément en contact direct avec les métiers, c’est le PO qui fait l’intermédiaire.

Pour finir, le poste de Business Analyst m’a appris à me dépasser car ce n’est pas dans ma personnalité de trop communiquer et de négocier, ce qui doit être le cas pour un BA. Je suis très content d’avoir eu cette mission car j’étais ambitieux et curieux, j’ai réussi à gérer l’équipe et je suis très heureux d’avoir vécu cette expérience.

Au contraire, qu’est ce qui est, selon toi, un inconvénient dans la combinaison des 2 rôles ?

Ce sont 2 métiers totalement distincts qu’il faut savoir combiner. Certains matins, j’étais sollicité avec la casquette de BA mais j’avais des tickets à tester avec les échéances d’un engagement sur sprint, donc je n’avais parfois pas le temps de combiner les deux rôles.

De plus, le switch entre les deux postes peut rendre la charge confuse (nombre d’interlocuteurs, le ton et l’approche à adapter). Parfois il m’était difficile de répondre à des questions posées pour le BA car je ne savais pas si la question faisait partie de mon périmètre.

Pour finir, la double casquette était calculée, elle engendre aussi doubles responsabilités, doubles deadlines, doubles sollicitations, etc… Ce sont des paramètres à prendre en compte ! 

Si on te proposait une nouvelle fois de combiner les 2 métiers, est-ce que tu serais partant ?

Le défi était passionnant, mais il m’a prouvé que chaque poste est un métier à part entière. Si le sujet est trop vaste, le cumul devient impossible. Je reste un QA avant tout, c’est ce que je préfère.

J’avais bossé avec des PO et des BA, je les voyais comme des esprits lointains qui viennent nous demander des trucs et qui attendent que ce soit fait. Et finalement ça m’a permis d’avoir un ensemble de la chaîne de développement. J’ai mieux compris le métier en le pratiquant et j’ai vu son utilité au quotidien. 

Selon moi,  BA est une possibilité d’évolution logique pour un QA, car une fois que l’on a eu la casquette QA, c’est un atout d’avoir ce versant en tant que BA, si on a une appétence pour le social. 

C’est principalement de l’échange, de l’écoute, entendre les besoins, les nuancer, calmer certaines demandes trop importantes et transmettre un message sans perte d’infos et adapté aux profils à qui on parle

Quels conseils donnerais-tu à un testeur qui hérite d’une double casquette ?

Mon conseil principal : bloquez-vous des points dans votre agenda pour chaque fonction. Bloquez-vous des temps dédiés à chaque rôle pour ne pas vous éparpiller, car cette gymnastique peut vite devenir confuse si elle n’est pas cadrée.

Et surtout, gardez votre objectivité : même si vous avez écrit la spécification, essayez toujours de la challenger avec un regard neuf quand elle doit être testée, pour ne pas laisser passer de biais de compréhension.

Le biais du testeur sera toujours présent mais il faut le tamiser pour qu’il ne se ressente pas dans les décisions du BA.

Cette mission hybride est terminée. Quelle est la suite pour toi ?

Je suis ravi de revenir à 100% sur du test chez mon client ! Suite à une réorganisation, j’y rejoins une équipe qui n’avait pas de QA auparavant, mon défi est de construire tout le patrimoine de tests et de mettre en place l’automatisation pour sécuriser nos livraisons et notre adhérence et anticiper celles de notre prestataire.

C’est la direction que je voulais prendre pour devenir un profil encore plus complet, car l’automatisation devient aujourd’hui indispensable sur le marché de la QA. Aidé par l’IA, ces profils seront recherchés par les entreprises. Ce contexte de mission, qui me permettra de grimper en compétences et de prendre le train en marche, c’est une belle opportunité !  

J’évolue au sein d’une équipe très orientée RUN, fortement dépendante d’un prestataire, avec un fonctionnement calé sur ses propres sprints. L’objectif de l’équipe est donc de réduire cette charge de RUN et le volume d’anomalies, notamment en automatisant la non-régression.

Sur la partie manuelle, tout reste à construire : il est nécessaire de rédiger l’ensemble des cas de test dans un premier temps. En bref, cela constituera une nouvelle expérience à ajouter à toutes les autres, me permettant d’acquérir de nouvelles compétences et d’appréhender des contextes variés. Je suis vraiment excité.