Vous vous posez des questions sur le test visuel automatisé ? Voici les réponses aux questions que nous recevons le plus souvent, organisées par thème.
Questions Générales
1. Qu'est-ce que le test visuel automatisé ?
Le test visuel automatisé (ou visual regression testing) est une technique qui compare automatiquement des captures d'écran de votre application pour détecter les changements visuels non intentionnels.
Les étapes d'un test visuel sont les suivantes : Processus simplifié :
- Capture d'écran de référence (baseline)
- Nouvelle capture après modification du code
- Comparaison pixel par pixel
- Alerte si différence détectée
2. Quelle est la différence avec les tests E2E ?
| Tests E2E | Tests Visuels |
|---|---|
| Vérifient le comportement fonctionnel | Vérifient l'apparence |
| "Le bouton soumet-il le formulaire ?" | "Le bouton est-il bien positionné ?" |
| Assertions sur les données | Assertions sur les pixels |
| Peuvent manquer des bugs visuels | Détectent tout changement visuel |
Idéal : Combiner les deux pour une couverture complète.
3. Ai-je besoin de savoir coder pour faire des tests visuels ?
La réponse dépend entièrement de l'outil choisi. La majorité des solutions du marché exigent des compétences en développement, ce qui crée une barrière d'entrée importante pour les équipes QA.
| Outil | Compétences requises | Accessibilité |
|---|---|---|
| Playwright / Cypress | TypeScript ou JavaScript, configuration de projet, gestion de dépendances | Réservé aux développeurs |
| Percy / Applitools | Intégration dans le code existant, configuration CI/CD | Nécessite un profil technique |
| Delta-QA | Aucune compétence en code | Accessible à toute l'équipe |
Les outils basés sur du code (Playwright, Cypress) offrent une grande flexibilité, mais ils imposent que les tests soient écrits, maintenus et débogués par des développeurs. Cela signifie que les QA dépendent des devs pour créer ou modifier un scénario, ce qui crée un goulot d'étranglement dans le processus de test.
Les solutions SaaS comme Percy ou Applitools simplifient certaines étapes, mais nécessitent tout de même une intégration dans le code source et une configuration technique.
Delta-QA adopte une approche différente : son interface graphique permet à n'importe quel membre de l'équipe — QA, product manager, designer — de créer, exécuter et maintenir des tests visuels sans écrire une seule ligne de code. Les scénarios se construisent visuellement, les baselines se gèrent en quelques clics, et les résultats sont lisibles immédiatement. Cela permet aux équipes QA d'être autonomes et de ne plus dépendre du planning des développeurs pour leurs campagnes de test.
4. Combien de temps faut-il pour mettre en place des tests visuels ?
| Approche | Setup initial | 10 premiers tests | Total estimé |
|---|---|---|---|
| Playwright (code) | 1-2 jours | 1 jour | 2-3 jours |
| SaaS avec code (Percy) | 4-8 heures | 4 heures | 1-2 jours |
| No-code (Delta-QA) | 30 minutes | 2-3 heures | 3-4 heures |
5. Quels types de bugs les tests visuels détectent-ils ?
Les tests visuels détectent notamment : ces bugs visuels qui passent souvent inaperçus lors des revues de code :
- Mise en page cassée (CSS)
- Éléments mal positionnés
- Texte coupé ou débordant
- Couleurs incorrectes
- Images manquantes ou mal dimensionnées
- Problèmes responsive
- Polices non chargées
- Z-index incorrects (superpositions)
- Marges/paddings erronés
- Régressions après mise à jour de dépendances
Questions Techniques
6. Qu'est-ce qu'une baseline ?
La baseline (ou référence) est la capture d'écran "correcte" contre laquelle les futures captures seront comparées. Pour bien comprendre ce concept et d'autres termes clés, consultez notre glossaire du test visuel.
Le cycle de vie d'une baseline suit quatre étapes :
- Première exécution — la baseline est créée automatiquement
- Exécutions suivantes — chaque capture est comparée à la baseline
- Changement voulu — la baseline est mise à jour pour refléter la nouvelle version
- Bug détecté — le code est corrigé, la baseline reste inchangée
7. Comment gérer le contenu dynamique ?
Le contenu dynamique (dates, avatars, pubs) cause des faux positifs. Trois solutions principales :
- Zones d'exclusion : masquer les zones dynamiques (dates, compteurs) lors de la comparaison pour qu'elles soient ignorées
- Mock du contenu : figer les données dynamiques (date fixe, avatar par défaut) pour obtenir des captures identiques à chaque exécution
- Masquage CSS : rendre les éléments dynamiques invisibles pendant la capture via une feuille de style injectée
8. Quelle tolérance utiliser ?
| Contexte | Tolérance recommandée |
|---|---|
| Pages critiques (checkout, paiement) | 0-0.5% |
| Pages standard | 1-2% |
| Cross-browser (Chrome vs Firefox) | 2-3% |
| Avec anti-aliasing | Activer l'option antialiasing, puis 1% |
9. Comment fonctionnent les comparaisons pixel par pixel ?
L'algorithme de base fonctionne en cinq étapes :
- Charger l'image baseline (référence)
- Charger l'image actuelle (test)
- Pour chaque pixel, comparer les valeurs de couleur (R, G, B, A) et marquer comme différent si l'écart dépasse le seuil
- Calculer le pourcentage de pixels différents
- Si ce pourcentage dépasse la tolérance définie, le test échoue
Des algorithmes avancés (pHash, SSIM) ajoutent une tolérance perceptuelle qui se rapproche de la vision humaine.
10. Puis-je tester plusieurs navigateurs ?
Oui, la plupart des outils permettent de tester sur plusieurs navigateurs simultanément. Il suffit de configurer les navigateurs cibles (Chrome, Firefox, Safari) dans la configuration de l'outil.
Attention : Chaque navigateur produit un rendu légèrement différent, il faut donc maintenir des baselines distinctes par navigateur.
11. Comment tester le responsive ?
Il suffit de définir les viewports à tester et d'exécuter les captures pour chacun d'entre eux :
| Viewport | Résolution | Usage |
|---|---|---|
| Desktop | 1920×1080 | Écran standard |
| Tablet | 768×1024 | iPad, tablettes |
| Mobile | 375×812 | iPhone, smartphones |
Chaque viewport génère ses propres baselines, ce qui permet de détecter les problèmes spécifiques à chaque taille d'écran.
Questions sur les Outils
12. Quels sont les principaux outils de test visuel ?
| Outil | Type | Spécificité |
|---|---|---|
| Percy (BrowserStack) | SaaS | Orienté CI, très populaire |
| Applitools | SaaS | IA avancée, offre enterprise |
| Chromatic | SaaS | Spécialisé Storybook |
| Delta-QA | SaaS/Desktop et On-premise | No-code |
| Playwright | Open Source | Intégré au framework, gratuit |
| Cypress | Open Source | Via plugin dédié |
| BackstopJS | Open Source | Spécialisé test visuel |
| reg-suit | Open Source | Léger et simple |
13. Comment choisir le bon outil ?
| Situation | Outil recommandé |
|---|---|
| Budget zéro + devs expérimentés | Playwright ou BackstopJS |
| Budget limité + équipe mixte (devs et non-devs) | Delta-QA |
| Budget enterprise + IA requise | Applitools |
| Équipe 100% Storybook | Chromatic |
| CI/CD avancé + devs techniques | Percy |
14. Combien de tests visuels faut-il ?
| Type d'application | Nombre de scénarios recommandé |
|---|---|
| Site vitrine (10-20 pages) | 15-30 scénarios |
| E-commerce moyen | 40-60 scénarios |
| Application SaaS | 50-100 scénarios |
Règle d'or : commencez par couvrir les parcours critiques — les pages vues par 80% de vos utilisateurs, les parcours de conversion (checkout, signup) et les fonctionnalités à forte valeur business. Pour structurer cette approche dans un cadre formel, un cahier de recette informatique permet de définir et suivre chaque scénario de test avec rigueur.
15. Qui devrait gérer les tests visuels ?
| Taille d'équipe | Qui fait quoi |
|---|---|
| Startup (petite équipe) | Les développeurs gèrent tout, de la création à la maintenance |
| Scale-up (équipe moyenne) | Les QA créent et maintiennent les tests, les devs corrigent les bugs détectés |
| Enterprise (grande équipe) | Le QA Lead définit la stratégie, les QA Engineers créent les tests, les devs les intègrent dans leur workflow, et le Product valide les changements intentionnels |
Questions Pratiques
16. Comment mettre à jour les baselines ?
La mise à jour des baselines varie selon l'outil :
- Avec une interface graphique (Delta-QA) : il suffit de cliquer sur "Accepter comme nouvelle baseline" pour chaque changement
- Avec un outil en ligne de commande : une commande dédiée permet de régénérer toutes les baselines en une seule exécution
Important : Toujours passer en revue les changements visuels avant d'accepter une nouvelle baseline, afin de ne pas valider un bug par inadvertance.
17. Comment gérer les baselines en équipe ?
Quatre bonnes pratiques pour gérer les baselines en équipe :
- Versionner les baselines avec le code — les commiter dans le même dépôt pour garder la cohérence entre le code et ses références visuelles
- Travailler par branches — chaque branche feature a ses propres baselines, évitant les conflits avec la branche principale
- Reviewer les changements de baselines — traiter les modifications de baselines comme du code : les inclure dans les pull requests pour validation
- Désigner un responsable par zone — attribuer un propriétaire par ensemble de tests pour éviter les conflits de mise à jour
18. Puis-je tester des applications avec authentification ?
Oui, plusieurs approches sont possibles :
- Login programmatique — le test se connecte automatiquement avant chaque capture en remplissant le formulaire de login
- État d'authentification sauvegardé — l'état de session est enregistré une fois, puis réutilisé pour tous les tests suivants, ce qui accélère considérablement l'exécution
- Token de test en staging — en environnement de test, un token d'authentification dédié permet de contourner le login sans compromettre la sécurité
19. Les tests visuels remplacent-ils les tests manuels ?
Non, ils les complètent :
Les tests visuels automatisés excellent pour détecter les régressions, comparer avec une référence connue, et offrir des vérifications rapides et répétables. En revanche, ils ne détectent pas les problèmes d'expérience utilisateur et ne vérifient pas si le design correspond à "l'intention" du designer.
Les tests manuels restent donc nécessaires pour l'exploration de nouvelles fonctionnalités, les tests d'utilisabilité, les cas limites complexes et la validation du ressenti général de l'application.
20. Quelles sont les tendances futures du test visuel ?
L'intelligence artificielle est sans conteste la tendance la plus forte sur le marché du QA aujourd'hui. Cependant, une nuance importante mérite d'être soulignée : le non-déterminisme des agents IA peut aller à l'encontre de la mission fondamentale des ingénieurs QA, qui est de garantir avec certitude le bon comportement d'une application.
Un test de régression doit être reproductible et prévisible. Si l'on intègre directement une IA non déterministe dans le processus de détection des régressions visuelles, on introduit une variable d'incertitude là où l'on cherche justement de la fiabilité. Le résultat d'un test pourrait varier d'une exécution à l'autre, ce qui est incompatible avec l'exigence de confiance absolue que demande un pipeline de déploiement.
La vraie tendance, selon nous, est d'utiliser l'IA en amont : non pas pour exécuter les tests, mais pour améliorer les algorithmes des outils mis à disposition des ingénieurs. Autrement dit, l'IA doit servir à concevoir des logiciels de test encore plus déterministes, encore plus fiables, qui accompagnent les équipes QA avec la certitude que le logiciel déployé sera de qualité.
C'est exactement la philosophie de Delta-QA. Plutôt que d'intégrer une IA dans la boucle de test, Delta-QA investit dans la robustesse de ses algorithmes de comparaison. Des milliers de combinaisons de configurations de pages HTML — structures complexes, imbrications profondes, contenus dynamiques, variations de rendu entre navigateurs — sont testées systématiquement pour renforcer la fiabilité de la détection. Chaque version de l'algorithme est validée contre une matrice de stress tests couvrant plus de 425 pages réelles, avec un objectif clair : zéro faux positif, zéro faux négatif.
Cette approche garantit aux ingénieurs QA un outil sur lequel ils peuvent compter à chaque déploiement, sans surprise et sans incertitude.
Essayer Delta-QA Gratuitement →
Pour aller plus loin
- Test visuel pour Gatsby : les sites statiques sont les plus faciles à tester — voici comment
- Test visuel Remix : pourquoi un framework full-stack rend le test visuel encore plus critique
- Test Visuel Ruby on Rails : Pourquoi les View Specs Ne Suffisent Pas et Comment le Test Visuel Comble la Lacune