Mental Model #2 — Pourquoi les développeurs doivent tester leur produit
Une habitude simple qui change profondément la manière de développer.
Beaucoup de développeurs livrent des fonctionnalités qu’ils n’ont jamais utilisées eux-mêmes.
Le code fonctionne.
Les tests passent.
La pull request est mergée.
Mais personne dans l’équipe n’a réellement essayé la fonctionnalité comme un utilisateur final.
Une page qui fonctionnait… sauf pour les utilisateurs
Sur un projet, nous avons livré une nouvelle page dans l’application.
La fonctionnalité a été développée, testée, puis mise en production.
Tout semblait fonctionner.
Les tests passaient.
Les démos aussi.
Puis, plusieurs mois plus tard, un utilisateur nous signale un problème :
la page n’affiche rien.
Après investigation, la cause est simple :
l’une des ressources de la page était accessible uniquement… aux administrateurs.
En théorie, ce problème aurait aussi pu être détecté avec un test automatisé.
Mais en pratique, le développeur n’est pas infaillible, il peut oublier de tester certains cas.
Depuis cet incident, nous avons ajouté une habitude simple dans nos tests fonctionnels :
→ tester systématiquement certaines fonctionnalités avec un compte utilisateur standard.
Le code fonctionnait.
Le produit, lui, ne fonctionnait pas.
Se cacher derrière les tests
Dans beaucoup d’équipes, il existe une forme de confort.
Les tests automatisés passent, donc tout va bien.
Mais les tests automatisés ne sont qu’une représentation partielle du comportement du système.
Les tests valident le code
l’usage valide le produit.
Certains développeurs finissent par se cacher derrière ces tests pour éviter d’affronter une réalité plus complexe : l’usage du produit.
L’effort invisible
Exécuter un ticket est simple :
lire les requirements
implémenter la logique
écrire les tests
ouvrir une pull request
Tester réellement le produit demande un effort différent.
Il faut :
suivre le parcours complet
imaginer les actions d’un utilisateur (se mettre à sa place)
tester des scénarios inattendus.
C’est plus lent, et demande de l’empathie.
La tentation de déléguer aux QA
Dans certaines organisations, les développeurs se reposent aussi sur les équipes QA ou produit.
mon code fonctionne, quelqu’un d’autre vérifiera le reste.
Mais cela crée une distance entre les ingénieurs et le produit.
Et cette distance empêche souvent de détecter des problèmes pourtant évidents.
Le travail ne s’arrête pas au code
Avec le temps, j’ai adopté une idée simple :
mon travail n’est pas terminé lorsque mon code est poussé.
Il est terminé lorsque j’ai vérifié que ce que j’ai construit fonctionne réellement pour le client.
La boucle de feedback la plus courte :
Tester soi-même apporte des bénéfices immédiats.
Pas besoin d’attendre une QA, un bug report ou un retour utilisateur.
Le problème apparaît immédiatement.Développer l’empathie produit :
Utiliser le produit permet de devenir le premier client.
On comprend mieux le parcours, les frictions et les incohérences.
Cette compréhension améliore la qualité des décisions techniques.Accélérer les code reviews :
Le reviewer ne devrait pas se demander si la fonctionnalité fonctionne ; cela devrait être une condition initiale.
La review peut alors se concentrer sur l’architecture, les compromis techniques et les edge cases.
Ouvrir une pull request sans avoir testé la fonctionnalité crée une dette de confiance envers son équipe.
Les tests automatisés ne suffisent pas
Cela ne veut pas dire que les tests automatisés ne sont pas importants.
Ils sont indispensables pour garantir la stabilité et éviter les régressions.
Mais ils ne suffisent pas.
Il peut toujours y avoir des trous dans la raquette, et la seule manière de voir certains problèmes reste le test fonctionnel réel.
Les bugs visibles coûtent plus cher
Lorsque l’on ne teste pas réellement une fonctionnalité, certains problèmes ne sont découverts qu’en production.
Les conséquences dépassent alors le simple bug technique.
Un bug bloquant (bouton qui ne fonctionne pas, parcours bloqué) entame la confiance dans le produit.
Même corrigée rapidement, la perception reste.
La confiance est difficile à construire et très facile à perdre.
Le modèle mental
Avec le temps, j’ai commencé à voir deux façons différentes de développer :
Le développeur “Tunnel” :
Il regarde ses tests unitaires.
Sa vision s’arrête à la ligne de code.
Si les tests passent, il est satisfait, mais il reste aveugle à ce qui se passe réellement dans le produit.Le développeur “Line of Sight” :
Il lève la tête au-dessus du code.
Sa vision traverse l’écran pour atteindre l’utilisateur.
Il sait que le code n’est qu’un intermédiaire et que la vraie validation se trouve dans l’usage réel du produit.
Pour finir
Tester le produit que l’on développe peut sembler évident, mais c’est une habitude étonnamment rare.
Pourtant, c’est l’un des moyens les plus simples de détecter des problèmes rapidement, de mieux comprendre le produit et d’améliorer la qualité de ce que l’on construit.
Les utilisateurs ne voient jamais votre code.
Ils voient uniquement votre produit.
Si cet article t’a plu je partage ici ce que j’apprends au quotidien sur le métier d’ingénieur logiciel :
Modèles mentaux d’ingénierie logiciel
Réflexion produit
Si ces sujets t’intéressent, tu peux t’abonner pour recevoir les prochains articles directement par email.