Essor et réinvention des quadrants de test agile

Quand les testeurs n’avaient pas leur place dans l’agilité

Extreme Programming était une méthodologie conçue par des développeurs pour des développeurs. Tout ce qui ne relevait pas du code était regroupé dans le rôle du « client XP, » ce qui se traduisait approximativement par « ce n’est pas mon problème. » Quand les entreprises ont commencé à adopter l’agilité au milieu des années 2000, les analystes d’affaires sont devenus des product owners et les chefs de projet des scrum masters. Les testeurs, éternels parents pauvres du monde logiciel, se sont retrouvés à se demander s’ils avaient encore un emploi.

La confusion était bien réelle. Dans une grande entreprise de services financiers, l’ensemble du département de test a démissionné en l’espace d’une semaine après avoir appris que l’organisation adoptait Scrum. Des développeurs du monde entier espéraient secrètement que quelques tests JUnit bien écrits rendraient les testeurs dédiés inutiles.

Un cadre qui a sauvé une profession

Brian Marick a esquissé les quadrants de test vers 2003, organisant les activités de test selon deux dimensions. L’axe vertical séparait les tests orientés métier des tests orientés technologie. L’axe horizontal séparait les tests qui soutiennent l’équipe pendant le développement de ceux qui évaluent le produit fini. C’était une taxonomie claire et intuitive.

Lisa Crispin et Janet Gregory ont rendu les quadrants célèbres grâce à leur livre Agile Testing de 2009. Le modèle est devenu la pièce maîtresse de l’ouvrage, le seul diagramme que tout le monde retenait de chaque conférence. En moins de cinq minutes, on pouvait utiliser les quadrants pour montrer à un développeur sceptique que les tests unitaires n’occupaient qu’un coin d’un domaine qualité bien plus vaste. Ce cadre a donné aux testeurs un langage pour défendre leur rôle et a aidé les équipes à concevoir des stratégies de test équilibrées.

Pourquoi le modèle ne fonctionne-t-il plus?

Les quadrants ont été conçus pour un monde de sprints de deux semaines avec une frontière nette entre développement et livraison. Au début des années 2010, ce monde se dissolvait. La livraison continue signifiait que les équipes déployaient plusieurs fois par jour. Le DevOps estompait la ligne entre construire et exploiter le logiciel. Les pratiques lean startup poussaient les équipes à tester leurs hypothèses produit avant d’écrire du code.

L’axe horizontal est devenu le problème. Il demandait aux équipes de séparer les activités qui « soutiennent l’équipe » de celles qui « évaluent le produit. » Dans un environnement de livraison continue, cette séparation s’effondre. Les tests de performance exécutés pendant le développement soutiennent l’équipe en détectant les régressions et évaluent le produit en mesurant les temps de réponse. Les tests fonctionnels construits par Specification by Example sont simultanément un feedback développeur et une acceptation métier. Les tests exploratoires, placés par de nombreux praticiens dans la moitié « évaluation, » produisent leurs résultats les plus précieux quand on les réalise tôt dans le cycle.

Gojko Adzic, auteur de Specification by Example et Impact Mapping, l’a formulé ainsi: plus il essayait de cartographier les pratiques modernes sur quatre quadrants, plus l’image devenait confuse. Les activités qui se rangeaient autrefois proprement dans un quadrant en chevauchent désormais deux ou trois. Le cadre conçu pour réduire la confusion avait commencé à en créer.

Un axe survit, l’autre doit être remplacé

L’axe vertical fonctionne toujours. Distinguer les tests orientés métier des tests orientés technologie reste une règle empirique utile. Cela aide les équipes à répartir les compétences, choisir les outils et structurer les conversations entre le personnel technique et les parties prenantes métier.

L’axe horizontal a besoin d’une nouvelle question. Plutôt que de demander « est-ce que cela soutient l’équipe ou évalue le produit? » la distinction plus utile est entre vérification et analyse. Vérifier signifie confirmer des résultats attendus prédéfinis: assertions dans les tests automatisés, validations de conformité, suites de régression. Analyser signifie explorer des domaines où il n’existe pas de bonne réponse prédéfinie: tests exploratoires, tests de pénétration, tests de charge pour trouver les points de rupture, recherche en utilisabilité, analyse des journaux de production.

Ce que le nouvel axe révèle

Ce recadrage résout plusieurs débats persistants. Les tests de sécurité se divisent naturellement entre tests de pénétration du côté analyse et vérification de conformité du côté vérification, déconstruisant le mythe que la sécurité est une seule préoccupation « non fonctionnelle. » Les tests de performance se divisent de façon similaire: les tests de charge exploratoires qui demandent « où va-t-il casser? » relèvent de l’analyse, tandis que la vérification automatisée des SLA est une vérification.

La distinction fait aussi émerger des activités qualité que les plans de test traditionnels couvrent rarement. Les expériences A/B, l’analytique de production, les tests produit guidés par des hypothèses et l’analyse de tendances des données opérationnelles se situent toutes du côté analyse. Elles produisent des insights plutôt que des verdicts réussite/échec et exigent une interprétation qualifiée plutôt qu’une exécution scriptée. L’essentiel de l’innovation actuelle en qualité logicielle se produit dans cet espace.

La communauté du test contextuel avançait un argument similaire depuis des années: vérifier des résultats attendus n’est pas vraiment tester au sens plein. La vérification est nécessaire mais mécanique. L’analyse est là où les testeurs appliquent une compétence et un jugement. Un modèle qui rend cela visible aide les organisations à investir plus judicieusement dans les deux dimensions.

Les cadres doivent évoluer avec l’industrie

Les quadrants de test originaux ont fait un travail important. Ils ont légitimé la profession de testeur au sein des équipes agiles à une période où cette profession était réellement menacée. Le fait qu’on doive maintenant mettre à jour le modèle n’est pas une critique de ses créateurs. C’est la preuve que l’industrie a avancé, en partie parce que des cadres comme les quadrants l’ont aidée à avancer.

Les équipes ont toujours besoin d’un modèle mental partagé pour la stratégie de test. L’axe vérification/analyse offre une meilleure adéquation pour les organisations pratiquant la livraison continue, opérant des pipelines DevOps et appliquant le lean product management. Garder l’axe vertical intact préserve l’insight original selon lequel le test a des dimensions métier et techniques. Remplacer l’axe horizontal met à jour le modèle pour un monde où la frontière entre développement et opérations a pratiquement disparu.