IT, data & développement / /10 min de lecture
Quand une équipe produit passe d'une mise en production par mois à plusieurs par semaine, les tests faits par les développeurs et le product owner ne suffisent plus. Les critères pour choisir entre une QA intégrée à l'équipe locale et une QA dédiée à distance, et les conditions pour que l'une ou l'autre fonctionne.
Il y a quelques années, beaucoup d’éditeurs de logiciels et d’équipes produit livraient une version par mois, voire par trimestre. La recette durait une semaine, parfois deux, et mobilisait le product owner, un ou deux développeurs et quelques utilisateurs clés. Avec l’intégration continue, les déploiements automatisés et la pression des clients pour des évolutions plus rapides, le rythme a changé. Une équipe de huit développeurs peut aujourd’hui pousser plusieurs mises en production par semaine. Le temps consacré à vérifier ce qui sort, lui, n’a souvent pas suivi. Les régressions apparaissent chez les clients, le support remonte des anomalies sur des fonctionnalités que personne n’avait touchées, et le product owner passe ses soirées à cliquer dans l’application avant chaque livraison. C’est à ce moment que se pose la question : faut-il renforcer la QA au sein de l’équipe locale, ou constituer une QA dédiée, éventuellement à distance ? Cet article propose une grille de décision fondée sur la nature des tests, le rythme et l’organisation de l’équipe.
Ce qui casse quand le rythme de livraison s’accélère
Le premier effet d’un rythme plus rapide est la réduction de la fenêtre de test. Quand on livre chaque semaine, il n’y a plus de semaine de recette. Les tests doivent se faire au fil de l’eau, en parallèle du développement, sur des branches ou des environnements de préproduction qui changent en permanence. Une organisation où les tests sont une phase finale, confiée à ceux qui ont un moment, ne tient plus. Les développeurs testent leur propre code, ce qui est nécessaire mais insuffisant, car on vérifie rarement bien ce que l’on vient d’écrire.
Le deuxième effet est l’accumulation de la dette de non-régression. Chaque nouvelle fonctionnalité ajoute des cas à vérifier, mais les anciens ne disparaissent pas. Une application de gestion utilisée par des cabinets comptables, par exemple, doit continuer à produire les mêmes états, à respecter les mêmes calculs et à accepter les mêmes imports, même quand on retravaille l’interface. Sans campagne de non-régression régulière, les anomalies se glissent dans les zones que personne ne regarde plus. Elles sont découvertes par les clients, souvent au pire moment, comme une clôture mensuelle ou une période déclarative.
Le troisième effet concerne la charge des profils clés. Dans beaucoup de PME du logiciel, la recette repose sur le product owner ou le directeur technique. Ce sont eux qui connaissent le mieux le produit, donc eux qui testent. Mais leur temps est précieux : cadrage des évolutions, échanges avec les clients, arbitrages techniques. Quand la recette dévore leur semaine, c’est toute la feuille de route qui ralentit. Le coût caché d’une QA insuffisante se mesure donc autant en retard sur les évolutions qu’en anomalies en production.
Distinguer les types de tests avant de choisir une organisation
La question « locale ou dédiée » n’a pas de sens tant qu’on n’a pas distingué les types de tests. Les tests unitaires et d’intégration relèvent du développement : ils sont écrits par les développeurs, exécutés automatiquement dans la chaîne d’intégration continue, et ne sont pas concernés par ce choix. Les tests fonctionnels, qui vérifient qu’une fonctionnalité fait ce que le besoin décrit, demandent une compréhension fine du métier de l’utilisateur. Les tests de non-régression, qui vérifient que l’existant fonctionne toujours, sont plus répétitifs et se prêtent bien à une exécution méthodique, manuelle ou automatisée. Les tests exploratoires, enfin, consistent à chercher activement ce qui pourrait casser, en sortant des parcours prévus.
Chacun de ces types n’appelle pas la même proximité avec l’équipe produit. Les tests fonctionnels sur une fonctionnalité nouvelle gagnent à être conçus au plus près du product owner, au moment où l’on écrit les critères d’acceptation. Leur exécution, en revanche, peut être confiée à une personne qui n’a pas participé à la conception, à condition que les critères soient écrits. Les campagnes de non-régression, une fois documentées dans un outil de gestion des tests (Xray, TestRail, Qase, Zephyr ou même un tableur structuré), sont les plus faciles à confier. L’automatisation des tests de bout en bout, avec Playwright, Cypress ou Selenium, demande des profils plus techniques, et peut s’organiser dans les deux modèles.
Prenons un éditeur de logiciel de gestion pour les réseaux de franchise, avec douze personnes dont sept développeurs. Il livre toutes les semaines. En examinant son activité de test, il constate que la conception des tests fonctionnels occupe peu de temps si les critères d’acceptation sont bien écrits, mais que l’exécution de la non-régression avant chaque livraison prend une à deux journées de travail, réparties entre le product owner et les développeurs. C’est cette part qui sature l’équipe. Et c’est elle qui pose réellement la question de la QA dédiée.
Les situations où une QA locale reste le meilleur choix
Une QA intégrée à l’équipe locale, en présentiel ou au moins sur le même fuseau et dans les mêmes rituels, reste préférable dans plusieurs situations. La première est un produit très jeune, dont les fonctionnalités changent chaque semaine et dont la documentation n’existe pas encore. Dans ce cas, le testeur doit être assis à côté du product owner, au sens figuré au moins, pour comprendre ce qui est attendu. Confier les tests à distance avant d’avoir stabilisé un minimum de documentation revient à demander de vérifier quelque chose que personne n’a décrit.
La deuxième situation est un domaine métier très spécialisé, où la validation fonctionnelle exige des connaissances rares : calcul de paie, règles de facturation dans le secteur de la santé, réglementation financière, logiciel embarqué dans un équipement industriel. Un testeur doit alors connaître le métier presque autant que l’utilisateur. Cela n’exclut pas une QA dédiée, mais demande une période de formation beaucoup plus longue, et parfois un binôme avec un expert métier interne.
La troisième situation est celle d’un volume faible. Une équipe de trois développeurs qui livre deux fois par mois un produit relativement stable n’a pas nécessairement besoin d’une personne dédiée aux tests. Mieux vaut investir dans l’automatisation des tests critiques, dans des critères d’acceptation précis et dans une revue croisée entre développeurs. La QA dédiée apporte de la valeur quand il y a assez de matière pour occuper au moins une personne de façon régulière.
Les situations où une QA dédiée apporte davantage
À l’inverse, une QA dédiée, qu’elle soit recrutée en interne ou constituée avec un partenaire, s’impose quand plusieurs conditions sont réunies. Le produit a atteint une certaine maturité et ses fonctionnalités principales sont stables. Le rythme de livraison est soutenu, avec au moins une mise en production par semaine ou par quinzaine. Les campagnes de non-régression sont longues et répétitives. Et les profils clés, product owner ou directeur technique, passent une part significative de leur temps à tester au lieu de piloter le produit.
Le fait que la QA soit dédiée à distance présente des avantages spécifiques. Le décalage horaire, s’il est modéré, peut permettre d’exécuter des campagnes en début de journée sur ce qui a été livré en préproduction la veille, et de remonter les anomalies avant que l’équipe ne reprenne. La constitution d’une équipe de plusieurs testeurs formés au même produit assure une continuité pendant les congés et les pics de livraison. Et le coût permet souvent de dimensionner la QA à hauteur des besoins réels, là où un recrutement local se limiterait à une seule personne.
Il faut cependant être lucide sur les conditions de réussite. Une QA dédiée à distance ne fonctionne que si l’équipe accepte de documenter : critères d’acceptation écrits, cas de test maintenus, environnements de test stables et accessibles, jeux de données réalistes et anonymisés. Elle demande aussi une intégration réelle dans les rituels : présence aux revues de sprint, accès aux tickets, canal de communication direct avec les développeurs. Une QA à qui l’on envoie une version par mail avec la mention « à tester » produira des résultats décevants, et ce ne sera pas sa faute.
Organiser la collaboration pour que la QA accélère au lieu de freiner
Quel que soit le modèle choisi, la QA doit s’insérer dans le flux de livraison sans devenir un goulot. Plusieurs pratiques y contribuent. Faire participer la QA dès la rédaction des critères d’acceptation, pour qu’elle signale les cas oubliés avant le développement. Définir clairement ce qui bloque une livraison et ce qui ne la bloque pas : une anomalie critique sur un parcours de paiement bloque, une faute d’orthographe dans une infobulle non. Utiliser un format commun de rapport d’anomalie, avec les étapes de reproduction, l’environnement, les captures et la gravité, pour que les développeurs n’aient pas à revenir vers le testeur à chaque fois.
La répartition entre tests manuels et tests automatisés mérite aussi une réflexion. Automatiser les parcours critiques et stables permet de libérer la QA pour les tests exploratoires et les nouvelles fonctionnalités. Mais l’automatisation a un coût de maintenance : un test automatisé cassé à chaque modification de l’interface devient une source de bruit. Il est souvent plus rentable de commencer par une non-régression manuelle bien documentée, puis d’automatiser progressivement les cas les plus répétés, qu’une QA dédiée peut prendre en charge si elle compte un profil technique.
Enfin, quelques indicateurs permettent de piloter : nombre d’anomalies trouvées avant et après la mise en production, délai entre la livraison en préproduction et le feu vert de la QA, taux de réouverture des anomalies corrigées, couverture des parcours critiques par la non-régression. L’objectif n’est pas de surveiller les testeurs, mais de vérifier que la QA réduit les anomalies découvertes par les clients sans ralentir les livraisons.
Constituer une QA dédiée à Madagascar pour votre équipe produit
Dedicateam constitue pour les éditeurs de logiciels et les équipes produit une équipe dédiée de QA à Madagascar, en mode offshore : testeurs fonctionnels chargés de l’exécution des campagnes de non-régression et des tests des nouvelles fonctionnalités, profils plus techniques pour l’automatisation des parcours critiques, selon votre besoin. Ils travaillent dans vos outils, gestionnaire de tickets, outil de gestion des tests, environnements de préproduction, et participent à vos rituels à distance. Cette externalisation informatique porte sur l’exécution et la maintenance des tests, la définition des priorités restant chez votre product owner.
L’axe que nous mettons en avant ici est l’outillage et la documentation de départ. Avant de lancer les premières campagnes, nous travaillons avec votre équipe sur ce qui manque souvent : un référentiel de cas de test, une classification des anomalies par gravité, des jeux de données de test utilisables et un accès stable aux environnements. Ce socle est la condition pour que la QA dédiée soit efficace dès les premières semaines, et il reste votre propriété si l’organisation évolue.
Le centre de services à Madagascar fonctionne avec un décalage horaire faible par rapport à la France, ce qui facilite la participation aux revues de sprint et les échanges directs avec vos développeurs. L’équipe peut démarrer avec un testeur formé à votre produit, puis s’étoffer au rythme de vos livraisons. Plusieurs personnes formées au même produit assurent la continuité, et la collaboration à distance s’appuie sur des canaux directs plutôt que sur des échanges de fichiers.
Notre approche : construire avec vous le socle de tests de votre produit, puis confier son exécution à une QA dédiée à Madagascar intégrée à vos rituels de livraison.