Contexte
Cadre de l’expérience
J’ai une carrière de plus de 15 ans dans l’immobilier d’entreprise (B2B) dont six ans en tant que cheffe de projet CRM. J’y ai réalisé du test fonctionnel, exploratoire, data sans savoir que c’était un métier à part entière. Ce fut une révélation, ce métier était fait pour moi ! J’ai donc fait une reconversion professionnelle pour devenir testeuse logiciel. Bonnes pratiques, principes, techniques de tests, méthodologies agiles et Certification ISTQB en poche, j’ai été recrutée sur mission par une ESN.
Le client
Je travaillais pour un acteur du secteur bancaire, sur des parcours digitaux destinés aux clients particuliers, accessibles via le web et le mobile. Mon équipe intervenait sur des fonctionnalités centrales de l’entreprise, directement liées à l’expérience client et à la transformation commerciale. Ces parcours constituaient une brique essentielle du modèle économique, avec un niveau d’exigence élevé en matière de qualité et de fiabilité.
Les logiciels à tester
Les évolutions sur lesquelles nous intervenions avaient pour objectif de simplifier les parcours digitaux et de réduire les abandons. Elles concernaient des fonctionnalités fondamentales pour l’entreprise, directement liées à son cœur d’activité. L’enjeu était double : offrir une expérience fluide aux utilisateurs tout en respectant des règles métier complexes et des exigences fortes en matière de fiabilité des données.
Le système à tester ne se limitait pas à une simple interface web. Il reposait sur un écosystème interconnecté : interfaces web et mobile, API, services back-end, bases de données, mainframe et outils tiers tels que des systèmes de scoring ou de gestion documentaire. Chaque action effectuée par l’utilisateur déclenchait des traitements en chaîne, avec des échanges de données entre plusieurs briques du système d’information.
La complexité résidait notamment dans le nombre élevé de combinaisons possibles. Les parcours comportaient de nombreuses conditions d’affichage, des champs obligatoires variables selon le profil du client, des calculs dynamiques, ainsi que des règles métier pouvant s’activer ou s’exclure selon des enchaînements précis. Il était nécessaire de prioriser les scénarios de test en fonction des risques fonctionnels et de l’impact potentiel sur le parcours client.
Tester ce type de système impliquait donc de valider non seulement le comportement visible côté utilisateur, mais aussi la cohérence et la bonne propagation des données dans l’ensemble du système.
Les activités
Au cours de cette mission, j’ai évolué dans deux contextes très différents, ce qui m’a permis de développer à la fois mes compétences techniques et ma posture professionnelle.
J’ai commencé par intervenir dans un environnement agile, sur des parcours digitaux où j’analysais les user stories, rédigeais et exécutais les cas de test, préparais les jeux de données et assurais la remontée et l’investigation des anomalies, via l’analyse des logs et des bases de données.
J’ai également travaillé sur l’automatisation de tests E2E avec Playwright afin de sécuriser les campagnes de tests de non-régression. J’ai aussi réalisé des tests d’API via Postman afin de valider certains échanges entre services. Lors des séances d’affinage, j’ai rapidement pris l’initiative de poser davantage de questions et de challenger les besoins. J’ai notamment proposé la mise en place de sessions « 3 Amigos » afin de clarifier les user stories en amont et d’améliorer la fluidité des sprints, proposition adoptée par l’équipe.
J’ai ensuite poursuivi la mission, pour le même client, au sein d’une autre squad qui travaillait sur un projet différent. Dans ce contexte plus hybride, j’étais l’unique QA sur un parcours particulièrement long et complexe (environ quarante écrans), avec des règles métier fortement imbriquées et un nombre élevé de combinaisons possibles.
Par ailleurs, la culture projet était plus traditionnelle, et la place de la QA dans le cycle de développement manquait parfois de clarté.
Dans ce contexte, certaines pratiques exposaient le projet à des risques en matière de qualité : la traçabilité des anomalies n’était pas toujours garantie, certains bugs pouvaient être transformés en user stories, les jeux de données en environnement d’intégration étaient instables, et la charge de test n’était pas systématiquement intégrée dans la planification des sprints.
La pression sur les délais s’accompagnait également d’une attente forte autour de l’automatisation, parfois perçue comme une solution immédiate, alors qu’elle nécessitait en réalité préparation, cadrage et stratégie. Par ailleurs, le maintien des rituels agiles (daily, rétrospectives) faisait parfois l’objet de questionnements.
Par conséquent, cela m’a amenée à contribuer à la structuration de certaines pratiques QA afin de sécuriser davantage le cycle de développement. J’ai choisi de proposer des solutions concrètes qui ont été adoptées par l’équipe. J’ai contribué à la mise en place d’une DoR et d’une DoD afin de sécuriser le backlog, au maintien des cérémonies agiles pour préserver la communication et la coordination, au renforcement de la formalisation des tests, ainsi qu’à l’automatisation du parcours avec Playwright afin de limiter les régressions.
Ce que je retiens de cette expérience
Je décrirais cette première expérience officielle en tant que QA comme profondément formatrice, parfois éprouvante, mais déterminante dans mon parcours.
Au sein de cette même mission, j’ai eu l’occasion de travailler dans deux squads avec des organisations très distinctes. Cela m’a permis de diversifier mes expériences et d’élargir mes compétences.
Ces environnements contrastés m’ont amenée à m’adapter rapidement, à ajuster ma posture et à consolider une conviction que j’avais déjà : la qualité se construit dans la collaboration.
Dans un environnement agile, j’ai appris à analyser les besoins en profondeur, à poser les bonnes questions et à proposer des améliorations concrètes dans les pratiques de travail.
Dans un contexte plus hybride, j’ai compris que le rôle de la QA dépasse largement l’exécution des tests. Il s’agit aussi de défendre la traçabilité, d’aligner les processus et de rappeler que la qualité a un coût… mais que l’absence de qualité en a un bien plus élevé.
Un moment marquant a été l’analyse approfondie d’une user story qui a permis d’identifier un risque fonctionnel important. Selon un développeur de l’équipe, cette vigilance a permis d’éviter un bug qui n’aurait pu être détecté qu’après mise en production. Cette situation a renforcé ma conviction que la valeur de la QA réside aussi dans l’anticipation.
Cette expérience a confirmé mon choix de carrière. Elle m’a appris que la QA doit être intégrée dès le début du cycle de développement, et non considérée comme une étape de validation en fin de chaîne.
Conclusion
Les premières expériences sont avant tout des occasions d’apprendre et de progresser.
Ce que je retiens surtout, c’est que la qualité ne dépend pas uniquement d’outils ou de méthodologies. Elle dépend d’une posture : oser poser des questions, défendre la traçabilité, clarifier quand c’est nécessaire et rester constructive, même dans des contextes exigeants.
C’est cette conviction qui guide aujourd’hui ma manière d’exercer le métier de QA.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
