Un article qui donne des éléments de langage en commun pour que toute l’équipe tech s’empare de la qualité.
Je ne m’étais jamais autant posé la question de ce qu’était la qualité qu’en 2026.
Mon challenge ? Concentrer des essentiels de la QA dans une équipe de développement.
Je m’appelle Stanislas. Suite à mon projet de reconversion professionnelle, mon équipe se retrouverait sans QA. L’enjeu était de laisser quelque chose de pérenne. Il me fallait donc condenser ce qui me semblait le plus important pour eux.
Ce que je vous partage là a été un essentiel de l’accompagnement effectué, un ensemble de commandements synthétisant ce qui devrait le plus être au centre de leur attention. Laissez-moi vous donner un peu plus de contexte.
Une décennie de carrière en tant que QA ne m’a pas laissé ça dans les mains tout préparé. Dans ma situation, il était important de construire ça en équipe et dans le contexte. Car mon équipe ne partait pas de zéro après 6 ans de collaboration chez leBonCoin.
J’ai eu peur – et eux aussi – qu’un déséquilibre s’installe, que la qualité se dégrade. De plus, mon côté un peu méticuleux de QA ne m’autorisait pas à les laisser sans quelque chose qui les guide. J’ai donc effectué un coaching et élaboré des supports pour faire cette transition.
L’important, c’était de synthétiser des points importants. Ceux-ci ont des sources différentes : l’ISTQB, mon expérience quotidienne en feature team, des conférences telles que l’Eurostar ou la Paris TestConf… Bien sûr, cela se nourrissait aussi de mon parcours personnel et de la relation que nous entretenions avec mon équipe.
Tout cela mûrissait donc à l’issue d’erreurs et de constats. Les 10 commandements ici présents sont la pierre angulaire de la transmission faite à mon équipe.
Je souhaite que cela puisse être utile à votre contexte de travail (peut-être même sujet à débat). Il s’agit d’embarquer des équipes dans des changements qui vont dans l’intérêt de chacun, et surtout dont l’intérêt est perçu collectivement.
Voici les principes que j’ai transmis à mon équipe.
1- Ne jamais présupposer que le produit fonctionne
On entend souvent que ce n’est pas la peine de vérifier un comportement, un contexte d’utilisation. Parce que le développeur a testé sa fonctionnalité, il suppose que certains problèmes n’arriveront pas. Lorsqu’on participe à la conception de quelque chose on a toujours un biais lié à notre ego et notre connaissance du produit.
Si toutes les présuppositions étaient bonnes, il n’y aurait pas de bugs.
Lorsque le développeur teste son propre code, il ne doit pas supposer que les tests couvrent parfaitement la fonctionnalité. La phase de test manuel est un indispensable dans la démarche qualité. Les tests automatisés et la couverture en TU et en TI ne peuvent pas remplacer le test effectué par un humain.
L’approche naïve est souvent la plus à même de révéler des irritants ou des incohérences qui sont des points de douleur pour les utilisateurs.
2 – Les bugs aiment vivre à la frontière des périmètres
Il existe différentes frontières propices à la croissance des anomalies :
- à la croisée des périmètres d’équipes
- dans les fonctionnalités cross-plateformes
- entre le scope d’une équipe et celui des partenaires de l’entreprise
- entre les stacks …
Il est particulièrement important dans ces contextes de communiquer, d’être vigilant et de co-construire avec les différentes parties prenantes.
Bill Mollison, cofondateur de la permaculture, disait : « The edge is where the action is ». Il entendait notamment par là que la lisière entre des environnements différents concentrait une biodiversité plus forte que ces éléments pris séparément.
Les jonctions entre les fonctionnalités, périmètres et responsabilités sont des nids à bugs qu’il est particulièrement important de surveiller. L’année dernière, nous avons commencé à travailler avec un partenaire. Les instabilités et incompréhensions sur l’utilisation de leur sandbox ont amené du retard et du stress.
Outre les anomalies logicielles, même les environnements et données partagées sont un enjeu pour la fluidité du travail dans l’équipe.
3 – Anticiper autant que possible les cas complexes
Le shift left permet de gagner du temps en amont (ou d’éviter d’en perdre en aval). Il consiste en une anticipation des problématiques de développement en plaçant des actions qualité en amont dans la chaîne de production.
Consacrer du temps à l’anticipation, partager les spécifications à l’avance, avoir des ateliers techniques préliminaires, discuter des maquettes en phase de conception, faire du TDD… sont des ensembles de pratiques qui augmentent l’efficacité et permettent d’intégrer la qualité en tant qu’habitude.
Cela peut commencer par une augmentation des tests statiques, ceux-ci concernent notamment la relecture de document ou de code.
Comme l’écrivait Aristote : “La qualité n’est pas une action – c’est une habitude.”.
Éviter les allers-retours de développement soulage les personnes en charge du test. Cela limite le stress du développeur qui souffre moins du multitasking et n’a pas à gérer une communication parasitaire.
4 – Comprendre le paradoxe du pesticide
Ce paradoxe concerne la survie de 10% d’une population de ravageurs qui développe dès lors une résistance au pesticide. Les survivants, en se reproduisant, augmentent la résistance de la population au fil des générations.
Comme un pesticide, une batterie de tests perd en efficacité pour anticiper les anomalies à mesure qu’elle est utilisée. Il est important de renouveler les tests effectués, notamment sur la couche de tests manuels.
On pourra relier ce principe au numéro 9 « Pilotage par les bugs ». Là où on trouve de nouveaux bugs, il est intéressant d’implémenter de nouveaux tests, pour couvrir « d’autres chemins dans le logiciel », comme le formule l’ISTQB.
Il sera également utile de coupler ce principe avec le numéro 5 « Qualitatif vs quantitatif ». Quand la couverture de test perd en efficacité, ajouter 3 fois plus de tests ne corrige pas le problème. Il faut évaluer la couche de test qu’il est le plus pertinent d’ajuster.
Il m’est arrivé de constater que de nombreux problèmes étaient par exemple relatifs à l’infrastructure. Peut-être que les tests ou les leviers qualité ne relèvent pas directement de votre équipe, il appartiendra alors de déplacer la responsabilité vers les acteurs capables d’agir.
5 – Qualitatif vs quantitatif
Parfois il faut réduire la voilure pour augmenter ou garantir la qualité. Il ne s’agit pas seulement de finir le travail, mais d’avoir un niveau de qualité suffisant. Ce qui passe également par un accord d’équipe sur le degré d’exigence de qualité souhaité.
Lors du coaching QA effectué avant mon changement d’équipe, il m’importait de questionner les développeurs sur leur perception de la qualité et leur intérêt à en produire.
Lorsqu’une équipe se retrouve sans QA, la responsabilité de la qualité doit se répartir sur l’ensemble des membres pour éviter que cette pression ne se transforme en une somme de responsabilités individuelles difficiles à supporter.
Ajuster le nombre de reviewers ou modifier la Definition of Ready ou la Definition of Done sont des exemples de changements nécessaires pour faire persister la qualité dans le temps.
Il est important de faire des tests de qualité et pas du volume de tests. Ceci est vrai pour le test manuel comme pour les tests unitaires (TU) ou tests d’intégration (TI). Se méfier des volumes de coverage attendus par l’entreprise qui peuvent détourner d’une approche qualitative dans la conception des tests.
La pyramide de tests reste un repère utile pour une équipe.
Mais, dans la réalité, elle est rarement équilibrée. Identifier les manques est assez simple. Les corriger, beaucoup moins. Parce que cela ne touche pas seulement au code, mais aux façons de travailler. Sur les tests d’intégration par exemple, il faut s’aligner entre équipes sur ce que l’on teste vraiment, puis faire évoluer les pratiques entre les différentes stacks.
La qualité a un coût mais a également une valeur qui se mesure mieux sur la durée. On constatera une baisse de performances business quand un produit perdra en qualité, sans pour autant avoir été capable de mettre en évidence la corrélation entre valeur et qualité.
6- Penser à la conformité entre les environnements de recette et de production
Les écarts d’environnement sont des contraintes nécessaires pour le développement et la QA. Il est important de les limiter et de les documenter. Lors des tests dynamiques, l’utilisateur (QA ou autre) comprend la fonctionnalité. Il intègre donc potentiellement des biais de compréhension.
Il arrive que des A/B tests soient mal désactivés, que des conditions d’environnement backend ne soient pas bien gérées. Souvent ces bugs sont invisibles de par leur nature et ne se constatent que lors de tests en production ou lors de remontées utilisateurs.
Il s’agit donc de bien vérifier les flags, les contingences d’environnement, les noter, les partager, documenter les enjeux quand on altère l’environnement de QA.
7- Problématiques des versions
Il faut engager de l’exigence sur les bonnes pratiques concernant les évolutions de versions. Essayer potentiellement de les anticiper dans la roadmap si on est lié à des librairies externes.
La qualité de l’implémentation rentre donc bien évidemment en tant que première étape de création de valeur. Un schéma de données qui a changé nécessite d’anticiper les effets de bord. Les bugs générés par ce genre de changement non anticipé sont souvent très longs à détecter, notamment sur les vieilles versions des applications.
La relecture de code et l’analyse en équipe des interactions front/back auront pour intérêt d’anticiper avant le développement les flux et les problèmes que pourraient rencontrer les utilisateurs (notamment ceux exploitant d’anciennes versions).
8 – Rechercher et tester les cas limites
Essayer de définir au plus tôt les cas limites. Élaborer une stratégie de test et des campagnes de test en amont peut être encore plus pertinent dans une équipe sans QA.
Une grande partie de la qualité se joue en amont. S’aligner en équipe sur la stratégie de test, anticiper les données nécessaires, préparer les environnements.
Par exemple : sur quels devices tester, quelles versions supporter, quelles dépendances peuvent poser problème. Ce travail se fait en équipe, souvent dès le sprint planning.
Les cas limites ne font pas exception. Pensés seuls, on en oublie. Pensés en équipe, ils sont challengés et deviennent plus pertinents.
C’est ce qui permet d’éviter le double travail et de rendre les tests plus efficaces.
L’activité de test peut faire tomber dans le « tilt ». Ce terme est utilisé quand un individu subit des perturbations émotionnelles qui altèrent sa capacité de décision rationnelle.
Concrètement, c’est le moment où l’on continue à tester sans vraiment réfléchir. Les gestes sont là, les scénarios s’enchaînent, mais l’attention a disparu.
Cela peut se produire lorsqu’il y a beaucoup de tests à enchaîner, de la pression sur la validation, des délais serrés. La fatigue et la répétition finissent par réduire la vigilance et l’esprit critique. On bascule alors vers du re-test, au lieu d’explorer de nouveaux cas.
Pour éviter cela, planifier sa campagne de tests, mettre à l’écrit sa réflexion ou juste s’aménager un temps de pause peuvent être salvateur.
La recherche des cas limites nécessite de réfléchir à l’état actuel de qualité du produit et d’éviter de simplement insister sur les cas passants habituels.
9 – Piloter par les bugs
L’un des éléments les plus pertinents pour établir une stratégie de test. On oublie parfois de questionner la récurrence de certains types de bugs ou des scopes touchés. A minima établir des tests (quelque soit l’étage de la pyramide concerné) sur les bugs existants est une pratique nécessaire.
Il est intéressant aussi, via des métriques ou de façon plus empirique, de voir si les anomalies ne prennent pas source dans des dépendances mal gérées avec d’autres équipes ou des lacunes dans les spécifications.
Aussi, le pilotage par les bugs peut amener à mettre en lumière des carences concernant les étages de la pyramide de test ou, à l’inverse, montrer que l’effort de qualité fourni n’est pas mis au bon endroit. Il permet de questionner l’effort effectué en tests statiques ou en tests dynamiques (par opposition au test statique, le test dynamique implique l’exécution du logiciel).
10 – Les tests automatisés ne remplacent pas les tests manuels
Les entreprises pilotent leurs activités avec des KPIs. En QA, cela se traduit souvent par des indicateurs de volume comme la couverture de tests ou le nombre de tests automatisés. Ces métriques ne reflètent pas toujours leur efficacité.
Le volume ne fait pas la qualité de la couverture de tests, ni celle des UATs. L’efficacité reste le critère clé. Une bonne stratégie de test doit rester adaptable : la qualité progresse avant tout quand les pratiques des contributeurs s’améliorent.
Comme le dit l’ISTQB, la vigilance est de mise quant à la possibilité pour l’outil d’automatisation d’amener un haut degré de confiance. La perception humaine est beaucoup plus à même de capter les changements d’interface et les incohérences logicielles.
Les tests automatisés doivent être ciblés, simples et bien maintenus. Ils doivent conserver la place suggérée par la forme de la pyramide de test.
Conclusion :
Dans l’équipe que je quitte, un chemin reste à faire pour répartir le travail de qualiticien dans la charge de travail déjà lourde des développeurs. Il faudra probablement réduire le volume de travail de ces derniers pour leur laisser le temps d’établir les questionnements de QA nécessaires au produit.
Le goût du travail bien fait en équipe est la source d’un produit bien conçu qui plaît aux utilisateurs, c’est là l’enjeu de la qualité sur le plan de l’accomplissement. Je sais que six ans avec mon équipe passés à échanger, à partager ma vision et à challenger le produit leur permettront assez vite de répondre à un certain niveau d’exigence.
Est-ce que je ressentirais le même degré de confiance si je venais d’arriver dans l’équipe et que je la quittais après seulement quelques mois ? Probablement pas.
Le QA permet un focus dans l’équipe qu’il est difficile de prendre sans attribuer ce rôle. C’est un effort qui peut être fait par une équipe mais qui nécessite de la persistance et de la rigueur.
Pour avoir un travail bien fait, je ne saurais pas conseiller à une équipe de travailler sans QA. Il est encore plus dangereux de se reposer seulement sur des outils d’automatisation au sommet de la pyramide. C’est au contraire tout au long de la chaîne de développement que la qualité doit s’intégrer.
Par chance, l’équipe que je quitte connaît l’importance du test manuel et j’espère qu’elle trouvera sur la durée le temps de l’intégrer dans ses pratiques quotidiennes. D’autres outils de la qualité sont particulièrement rentables dans le rapport entre le temps fourni et la capacité à détecter des problèmes. Selon les contextes, on pourra par exemple penser au monitoring ou au screenshot testing.
La qualité est une notion complexe, difficile à mesurer et qui, pour être bien effectuée, doit s’insérer à tous les niveaux de la chaîne de production et de développement. De façon générale, ce que fait le QA, c’est essayer de savoir où les efforts manquent en analysant le produit et le process de travail, comment y remédier et comment faire persister les pratiques efficaces.
Il est donc important d’avoir conscience de la mise en tension de son travail avec la capacité de production, mais aussi de l’effort à fournir dans une équipe quand le gros de la responsabilité ne repose plus sur une seule personne dédiée.
A propos de l’auteur: Stanislas Gourévitch a construit son parcours en Quality Assurance entre conseil et équipes produit, notamment pour le ministère des Armées, la SNCF, Renault, puis leboncoin.
Son approche croise pratique terrain, culture QA et références variées : ISTQB, EuroSTAR, Paris TestConf, Aristote ou Bill Mollison.
Il s’intéresse à la qualité comme pratique collective.
