Atomic Habits appliqué au testing : ce qui marche (et ce qui manque)

Le 26 mars 2026, j'étais au Swiss Testing Day à Zurich. Parmi les talks de la journée, celui de Manuel Felipe Hintermayr m'a interpellé par son titre : "How 1% can change everything: Micro-habits for maintainable test automation".

La promesse est claire. Prendre le framework d'Atomic Habits de James Clear et l'appliquer à l'automatisation de test. Des micro-changements, accumulés dans le temps, pour rendre les tests maintenables sans effort surhumain.

Sur le papier, c'est exactement le genre d'approche qui me parle. En pratique, certaines idées du talk sont excellentes. D'autres passent à côté de leur cible pour moi.

Le concept : des micro-habitudes pour le test automation

L'idée de départ est empruntée directement à James Clear. Dans Atomic Habits, il défend que des améliorations de 1%, répétées quotidiennement, produisent des résultats exponentiels sur le long terme. Hintermayr reprend ce principe et l'applique au monde du test automation.

Le parallèle se tient. On sait tous qu'une suite de tests mal entretenue ne s'effondre pas en un jour. C'est une accumulation de petits compromis : un sélecteur hardcodé ici, un copier-coller là, une convention de nommage ignorée. Chaque raccourci est insignifiant. L'effet cumulé est dévastateur.

L'inverse devrait donc fonctionner aussi. Des micro-améliorations appliquées régulièrement devraient rendre les tests progressivement plus solides. Le concept est séduisant. L'adaptation au testing est inégale, mais certaines idées valent vraiment le détour.

Les anti-patterns : rien de neuf, mais nécessaire

Hintermayr commence par lister les anti-patterns classiques du test automation. Du code de test copié-collé partout. Des sélecteurs et des données de test hardcodés. Aucune convention de nommage. Le fameux "it works on my machine". Pas de code review sur le code de test.

Aucun testeur expérimenté ne sera surpris par cette liste. On les connaît, on les a vus, on les a probablement commis. Mais le rappel a du mérite. Surtout quand il est accompagné du message central du slide : les tests sont un produit. Il faut les traiter comme tel.

C'est une phrase simple, mais c'est exactement le genre de changement de mentalité qui fait la différence entre une équipe qui subit ses tests et une équipe qui s'appuie dessus. Si on ne retient qu'une seule chose de cette partie du talk, c'est celle-là.

Une architecture en couches qui tient

La partie architecture est plus intéressante. Hintermayr présente un modèle en couches pour structurer le code de test. En haut, les Test Specs contiennent la logique métier et les scénarios. En dessous, deux couches d'abstraction : les Page Objects pour l'UI et les API Helpers pour le backend. À la base, les composants réutilisables, la configuration centralisée et les données de test.

Les principes derrière sont connus : Single Responsibility, DRY, lisibilité. On applique au code de test les mêmes standards qu'au code de production. Ce n'est pas révolutionnaire, mais c'est structuré clairement et ça a le mérite de montrer que l'architecture de test n'est pas un luxe. C'est un investissement qui se rembourse à chaque exécution.

Le vrai intérêt de cette section, c'est qu'elle pose les bases de ce qui vient après. Et ce qui vient après, c'est la meilleure idée du talk.

Le vrai apport : les Health Checks sur les Page Objects

L'idée est simple. On a déjà des Page Objects qui décrivent les éléments de l'interface. Hintermayr propose de les transformer en système d'alerte précoce. Un Health Check Generator parcourt les Page Objects existants et vérifie trois choses : est-ce que les locators existent encore, est-ce que les éléments sont disponibles, est-ce que les pages se chargent correctement.

Concrètement, on parle d'une ligne de code en plus et d'un script de vérification. Pas d'un projet de six mois. Pas d'une refonte. Un micro-changement, au sens propre du terme.

Le résultat, c'est un système de monitoring qui tourne plus vite qu'une suite E2E complète et qui répond à trois questions avant même de lancer les vrais tests : qu'est-ce qui fonctionne encore, qu'est-ce qui a cassé, où est-ce que l'UI a changé.

C'est tester les tests. S'assurer qu'on est prêt quand les tests sont nécessaires. Le ROI est immédiat et le coût d'entrée est ridicule. Pour moi, c'est l'idée la plus forte de tout le talk.

La communication comme micro-habitude : bonne intention, mauvaise cible

Le talk prend ensuite un virage inattendu. Hintermayr quitte le code et parle de ce qu'il a appris du théâtre. Résonance vocale, Alba Emoting, le lien entre respiration, posture et émotion. L'idée : la manière dont on communique est aussi une micro-habitude à travailler quand on fait de la QA.

L'intention est louable. Mais ce genre de conseil part du principe que tout le monde a les mêmes facilités. Quelqu'un de timide ou d'introverti ne va pas se transformer en orateur parce qu'on lui dit de parler depuis le ventre. Ce n'est pas un problème de micro-habitude. C'est un profil de personnalité.

Ce qui est intéressant, par contre, c'est ce que ça révèle en creux. La QA n'est pas un métier purement technique. Convaincre un développeur qu'un bug est réel, négocier une priorisation avec un product owner, faire accepter un processus à une équipe qui n'en veut pas : c'est de la psychologie humaine. Et c'est, à mon sens, le gros du travail en QA. Mais ça mériterait un talk entier, pas un slide en fin de présentation.

Ce que j'en retiens

Ce talk ne réinvente pas la roue. Ce n'est pas son but. L'idée de prendre Atomic Habits et de l'appliquer au testing est un bon point de départ, même si l'adaptation est inégale.

Les parties techniques sont les plus convaincantes. L'architecture en couches est un rappel utile. Les Health Checks sur les Page Objects sont une idée concrète, peu coûteuse, avec un retour immédiat. C'est exactement ce qu'un micro-changement devrait être : un petit effort pour un vrai impact.

La partie communication rate sa cible pour moi, mais elle pointe vers quelque chose de vrai. La qualité logicielle n'est pas un problème technique. C'est un problème humain qui se résout par le design de systèmes. Et ça, ça mériterait bien plus qu'un slide en fin de talk.

Le Swiss Testing Day est une conférence annuelle sur la qualité logicielle qui se tient à Zurich. L'édition 2026, "Guardians of Trust -- Defining Quality in a Dangerous Decade", a eu lieu le 26 mars.

Je partage mes retours d'expérience QA, gamification et automatisation sur mon blog. Retrouvez mes articles sur abovet.net/blog et connectons-nous sur LinkedIn.