Test graphique : vérification que l'interface d'une application s'affiche et se comporte comme attendu après une modification — mise en page, couleurs, textes, valeurs affichées, états des composants. Quand cette vérification est rejouée à chaque livraison pour protéger l'existant, on parle de test de non-régression graphique (ou TNR graphique). C'est la déclinaison « interface » du test de non-régression.
En France, les équipes projet, les ESN et les éditeurs d'outils de test parlent de « tests graphiques » là où la documentation anglophone dit UI testing ou visual regression testing. Les trois expressions désignent une réalité proche, mais pas identique — et la confusion coûte cher au moment de choisir une méthode ou un outil. Cet article pose le vocabulaire, décrit ce qu'un test graphique doit réellement vérifier, puis montre comment le rejouer automatiquement, sans écrire une ligne de code.
L'essentiel en une page — définition, automatisation sans code, grille de choix d'un outil : Test de non-régression automatisé, sans code.
Vos tests graphiques sont encore faits à la main, écran par écran, avant chaque mise en production ? Delta-QA enregistre vos parcours en naviguant, les rejoue à chaque livraison et compare le résultat, gratuitement et sans code. Essayer Delta-QA gratuitement →
Tests graphiques, TNR graphique, test visuel : qui désigne quoi ?
| Expression | Ce qu'elle désigne | Où on la rencontre |
|---|---|---|
| Test graphique | Vérification de l'interface (rendu et comportement visible) d'une application, manuelle ou automatisée | Cahiers de recette, plans de test, ESN, éditeurs français |
| Test de non-régression graphique (TNR graphique) | La partie des tests graphiques rejouée à chaque livraison pour s'assurer que l'existant n'a pas changé | Périmètres TNR, campagnes de recette |
| Test visuel / régression visuelle | Traduction de visual (regression) testing : comparaison du rendu à une référence, souvent par captures d'écran | Documentation des outils, articles anglophones |
| Test d'interface / test UI | Terme générique, couvre le fonctionnel de l'interface (clics, saisies) autant que le rendu | Frameworks de test (Selenium, Cypress, Playwright) |
Le point commun : on vérifie ce que l'utilisateur voit et manipule, pas la logique métier derrière. La différence utile : « test graphique » et « TNR graphique » décrivent un besoin et une campagne ; « test visuel » décrit surtout une technique (la comparaison de rendu). Un test graphique automatisé s'appuie donc sur la comparaison visuelle, mais ne s'y réduit pas : il doit aussi lire les valeurs affichées et les états des composants.
Ce qu'un test graphique doit détecter
Une campagne de tests graphiques manuelle vérifie, page par page, une liste de points. Automatisée, elle doit couvrir les mêmes familles de défauts :
- Mise en page : un bloc qui se décale, un bouton qui passe sous la ligne de flottaison, une colonne qui déborde sur mobile.
- Rendu : couleur, typographie, bordures, ombres, visibilité — un thème sombre à moitié appliqué, une icône qui disparaît.
- Valeurs et états : un prix affiché sans devise, un compteur figé, un formulaire dont l'état d'erreur ne s'affiche plus, un bouton désactivé qui reste actif.
- Multi-navigateurs et multi-écrans : le même parcours sur Chrome, Firefox et WebKit, à plusieurs largeurs d'écran.
- Et surtout, ce qu'il ne doit pas signaler : un changement de structure HTML sans effet visible, un anti-aliasing différent, une animation capturée à un autre instant. Chaque fausse alerte coûte une analyse ; un outil de test graphique bruyant finit ignoré.
Delta-QA publie la liste des 15 catégories et 437 cas de test sur lesquels son moteur est re-validé à chaque version, avec zéro faux positif et zéro faux négatif.
Pourquoi les tests graphiques restent manuels
Trois raisons reviennent dans les équipes QA :
- Les scripts coûtent cher. Automatiser un test graphique avec Selenium, Cypress ou Playwright suppose d'écrire chaque parcours en code, avec ses sélecteurs et ses assertions. Le périmètre TNR dépend alors des développeurs, et chaque changement d'interface casse des sélecteurs sans que l'application soit fautive.
- La comparaison de captures est bruyante. Photographier avant/après et comparer pixel par pixel génère des faux positifs à chaque police, animation ou contenu dynamique — et ne dit rien des valeurs affichées.
- Le périmètre vieillit. Sans outil maintenable par la QA elle-même, la liste des écrans à vérifier n'est pas mise à jour, et la campagne finit réduite au « happy path ».
Résultat : le test graphique est sacrifié quand la release presse, et la régression d'interface est découverte par l'utilisateur.
Un périmètre de tests graphiques que l'équipe QA fait évoluer elle-même, sans ticket de développement ? Avec Delta-QA, un parcours enregistré en naviguant devient un scénario rejoué et comparé automatiquement. Gratuit, sans carte bancaire. Essayer Delta-QA gratuitement →
Automatiser les tests graphiques sans code : la méthode
L'approche par enregistrement et rejeu remplace l'écriture de scripts :
- Enregistrer : le testeur navigue sur l'application comme un utilisateur ; l'outil capture les actions et l'état de chaque page.
- Rejouer : à chaque livraison candidate, les scénarios s'exécutent seuls, sur les navigateurs et les largeurs d'écran choisis.
- Comparer : le rapport montre la référence et la version courante côte à côte, avec les différences surlignées et classées — visuellement et fonctionnellement (valeurs, états).
- Décider : le changement est validé comme nouvelle référence, ou un bug est ouvert.
Chez Delta-QA, le verdict vient d'une IA déterministe — pas un LLM : un algorithme propriétaire, sans modèle appris, qui donne le même résultat à chaque exécution et ne signale que ce qu'un œil humain remarquerait. C'est ce déterminisme qui rend un test graphique automatisé digne de confiance : même entrée, même verdict. Le détail de l'approche est sur la page Automatisation des tests sans code.
Intégrer les tests graphiques dans la recette et le TNR
- Dans le cahier de recette : les cas « à rejouer à chaque livraison » (connexion, recherche, panier, formulaires critiques) deviennent des scénarios enregistrés ; la recette manuelle se concentre sur la nouveauté. Guide : Cahier de recette informatique.
- Dans la campagne de TNR : le TNR graphique tourne avec le TNR fonctionnel, à chaque livraison candidate, en préproduction — ou en production à intervalle régulier pour attraper les changements sans déploiement (CDN, CMS, widgets tiers).
- Dans la CI/CD : optionnel pour démarrer, mais un scénario déclenché à chaque déploiement peut bloquer la mise en production en cas de régression non validée. Guide : Tests de non-régression dans un pipeline CI/CD.
Choisir un outil de tests graphiques
| Critère | Ce qu'il faut demander |
|---|---|
| Sans code | La QA peut-elle créer et maintenir les scénarios sans développeur ? |
| Faux positifs | Un chiffre mesuré sur un jeu de cas public, pas une promesse |
| Visuel + fonctionnel | Le rendu et les valeurs affichées sont-ils vérifiés ensemble ? |
| Déterminisme | Même entrée, même verdict, à chaque exécution ? |
| Hébergement | SaaS pour démarrer ; On-Premise si les captures ne doivent pas quitter votre réseau |
| Coût d'entrée | Un plan gratuit, sans carte bancaire, pour valider sur un vrai périmètre |
Pour comparer les solutions sur ces critères : Alternatives et comparatifs.
FAQ
Qu'est-ce qu'un test graphique ?
C'est la vérification que l'interface d'une application s'affiche et réagit comme attendu : mise en page, couleurs, textes, valeurs affichées, états des composants. Rejoué à chaque livraison pour protéger l'existant, il devient un test de non-régression graphique.
Test graphique et test visuel, est-ce la même chose ?
Presque. « Test graphique » décrit le besoin (vérifier l'interface) ; « test visuel » décrit la technique la plus courante pour l'automatiser (comparer le rendu à une référence). Un bon test graphique automatisé compare le rendu et lit les valeurs et états affichés.
Peut-on automatiser des tests graphiques sans coder ?
Oui. Avec un outil d'enregistrement et de rejeu, le testeur navigue une fois ; les scénarios sont rejoués et comparés automatiquement à chaque livraison, sans script ni sélecteur à maintenir.
Comment éviter les faux positifs en test graphique ?
En choisissant un outil dont le verdict est déterministe et calibré sur ce qu'un œil humain remarque, et en demandant un taux de faux positifs mesuré sur des cas publics plutôt qu'une promesse.
Prêt à rejouer vos tests graphiques à chaque livraison, sans une ligne de code ? Créez un compte gratuit, enregistrez un premier parcours et lisez le rapport côte à côte en deux minutes. Essayer Delta-QA gratuitement →