E2E business vs fonctionnel — la distinction qui change tout
Photo by Luke Chesser on Unsplash
Un article fondamental pour tout dev qui livre du code "testé" mais reçoit des retours client sur des bugs visuels.
Photo by Carlos Muza on Unsplash
Découvrez la méthode 2 couches MoonManager : couche 1 technique (CodeceptJS, assertions CSS/layout) + couche 2 business (screenshots validés par un humain). Avec des résultats concrets : 42/43 tests, 97 screenshots, quasi zéro bug visuel remonté.
Le piège du dev qui teste "techniquement"
Un test fonctionnel vérifie que nav.mws-nav-bar li > a contient N éléments. Un test business capture un screenshot et le compare visuellement.
Le client ne fait jamais document.querySelectorAll(). Il regarde l'écran.
Pourquoi les tests fonctionnels mentent
Imaginez : votre test Cypress vérifie qu'un bouton "Ajouter au panier" est présent dans le DOM. Le test passe. Mais sur mobile, le bouton est masqué par un overflow:hidden mal configuré. Le client, lui, voit une page sans bouton d'achat.
C'est le problème fondamental : les tests fonctionnels vérifient la structure (le DOM, les requêtes HTTP, les codes de retour), pas l'apparence — ce que l'utilisateur perçoit réellement.
Chez Monwoo, après des dizaines de projets, on a constaté que 80% des bugs remontés par les clients étaient des bugs visuels que nos tests "verts" ne détectaient pas.
La méthode MoonManager : 2 couches de validation
La solution qu'on a développée sur MoonManager v4 est une validation à deux couches, chacune avec un rôle distinct :
Couche 1 — Pre-test technique (automatique, CodeceptJS)
La première couche filtre les bugs techniques avant que l'humain perde du temps à regarder. Elle vérifie :
- Layout CSS : pas d'overflow horizontal, pas de scroll involontaire
- Sticky elements : la navbar reste visible, le footer ne recouvre pas le contenu
- Responsive : les breakpoints ne cassent pas la mise en page
- Console errors : aucune erreur JS bloquante, aucun 404 sur les assets
Si la couche 1 échoue, on ne passe même pas à la couche 2 — inutile de faire valider visuellement un écran techniquement cassé.
Couche 2 — Validation business (humain, screenshots)
La deuxième couche est la plus importante : c'est un humain qui regarde des screenshots.
Chaque parcours utilisateur critique (inscription, achat, consultation) est capturé en screenshots à des checkpoints définis. L'humain (souvent Miguel) regarde les images dans un viewer dédié (port 8201) et valide que :
- Le rendu visuel correspond à ce que le client attend
- Les textes sont lisibles et correctement positionnés
- Les interactions produisent le résultat visuel attendu
- L'expérience est fluide d'un écran à l'autre
Pourquoi cette approche est utile
La couche 2 demande des skills de communication client, pas juste des skills de dev. Il faut comprendre ce que le client veut voir, pas ce que le code devrait faire. C'est une compétence de bridge entre technique et business, et son intégration dans le workflow quotidien fait la différence.
Résultat concret : sur MoonManager v4, on opère avec 42/43 tests E2E qui couvrent 12 fichiers de scénarios et 97 screenshots de référence, validés à chaque changement par un humain. Le taux de bugs visuels remontés par les clients a fortement diminué.
Comment l'appliquer sur votre projet
- Commencez par identifier les 5 parcours critiques de votre app (inscription, achat, dashboard principal...)
- Créez un test E2E par parcours avec des screenshots aux étapes-clés
- Installez un viewer de screenshots (ou utilisez un outil comme Percy, Chromatic, ou notre viewer MoonManager)
- Regardez les images après chaque déploiement. Pas les logs, pas la console — les images.
Le plus dur n'est pas l'outillage. C'est de convaincre l'équipe que regarder des screenshots est du vrai travail de QA, pas une perte de temps.
