Voir les preuves de démonstrationCommencer l'essai gratuit
Français

Vos tests restent en Playwright, Selenium et pytest. Nous ne les remplaçons pas. Nous les adaptons aux exigences de l'entreprise, et vous conservez l'entière propriété : code, preuves et historique.

Pourquoi mes tests échouent-ils alors que l'application fonctionne correctement ?

Un test de bout en bout passe au rouge lorsque le réseau est lent, que le DNS échoue, que le site répond par une erreur 403 ou 429 ou affiche un défi anti-robot, ou encore lorsque le navigateur plante, et rien de tout cela ne constitue un défaut dans votre application. Nexus Studio, de Verdict System LLC, attribue à ces échecs leurs propres verdicts : TIMEOUT, UNREACHABLE, BLOCKED et CRASHED. Aucun d'entre eux n'est signalé comme un bug dans l'application.

Par l'équipe Nexus Studio, Verdict System LLC. 7 octobre 2026.

Qu'est-ce qui fait échouer un test sans qu'il n'y ait de bug ?

Un test signale uniquement qu'un événement ne s'est pas produit. La cause peut se situer à quatre niveaux qui n'ont rien à voir avec votre code :

  • la page était lente et le test a manqué de temps ;
  • l'hôte n'a pas pu être joint, par exemple parce que le nom n'a pas été résolu ;
  • le site s'est défendu avec une 403, une 429, un CAPTCHA ou un défi anti-robot, de sorte que la requête n'a jamais atteint votre produit ;
  • le navigateur ou le processus a planté.

Lorsque chacun de ces cas se traduit par un simple rouge, l'équipe les classe comme des bugs, ou apprend à réexécuter les tests en rouge au lieu de les analyser. Dans les deux cas, le véritable défaut reste dissimulé dans le bruit ambiant.

Comment Nexus Studio distingue-t-il un faux échec d'un bug ?

Lorsqu'un test échoue, le moteur lit le message d'erreur ainsi que le journal réseau de l'exécution et les compare à des groupes de modèles selon un ordre fixe. Le premier groupe correspondant détermine le verdict. L'ordre est CONFIG_ERROR, puis CRASHED, BLOCKED, UNREACHABLE et TIMEOUT, et seulement après BREACHED_FLAKY ou BREACHED. Ainsi, BREACHED, le verdict qui signale un rapport de bug, est réservé à un échec qu'aucun modèle d'environnement ou de banc d'essai n'explique. Les modèles couvrent à la fois les formulations de Playwright et de Selenium WebDriver.

Que signifient TIMEOUT, UNREACHABLE, BLOCKED et CRASHED ?

  • TIMEOUT : le test n'a jamais reçu de réponse à temps. Cela ne prouve pas que l'application est défaillante, et cela ne prouve pas non plus qu'elle fonctionne : l'exécution ne peut pas se prononcer. Une navigation qui a dépassé le temps imparti est un TIMEOUT, car elle a bien démarré et la page était lente.
  • UNREACHABLE : l'hôte n'a pas pu être joint du tout. Le DNS ou la connexion a échoué avant qu'aucune page ne soit observée, comme dans le cas d'un nom non résolu, d'une connexion refusée ou d'une machine hors ligne. Une erreur de certificat ne figure pas ici : il s'agit d'une anomalie détectée.
  • BLOCKED : le site s'est défendu avec une erreur 403, une 429, une page de blocage ou un défi bot. Lorsqu'une défense s'est affichée à l'écran, metadata.json la nomme. Un véritable téléphone Android qui s'est mis en veille ou qui est verrouillé est également BLOCKED, en tant que prérequis non satisfait.
  • CRASHED : le navigateur ou le processus s'est arrêté de manière inattendue, par exemple une page fermée, une erreur de protocole DevTools ou une session WebDriver terminée. Il s'agit d'un problème d'infrastructure : examinez la machine et le pilote.

Le guide des verdicts répertorie les modèles d'erreur précis derrière chacun d'entre eux.

Que voit mon pipeline CI ?

Sept des 14 verdicts se terminent avec le code 0 : SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION et SECURITY_VIOLATION. Les sept autres se terminent avec le code 1, et TIMEOUT, UNREACHABLE, BLOCKED ainsi que CRASHED en font partie. Le build passe donc toujours au rouge, car le test n'a pas réussi, mais le rapport et l'Historique précisent quelle en était la cause. Les exécuteurs pytest et Selenium se terminent avec le code 2 lorsque l'exécution n'a pas pu démarrer du tout.

Quelles preuves chaque faux échec conserve-t-il ?

Chacun des quatre conserve report.md, metadata.json, raw-data.json et une capture d'écran de l'image finale. Pour la vidéo, cela diffère :

  • TIMEOUT et BLOCKED : la vidéo est désactivée par défaut. Activez-la dans les Paramètres, sous Conserver la vidéo d'échec pour.
  • UNREACHABLE : aucune vidéo n'est proposée, car aucune page n'a été chargée et l'enregistrement serait vide.
  • CRASHED : aucune vidéo n'est proposée, car l'enregistrement d'un navigateur arrêté s'avère corrompu.

Seules les exécutions web Playwright et mobiles émulées enregistrent de la vidéo. Un véritable téléphone Android, une exécution Selenium et un test d'API n'en enregistrent pas.

Lorsque Jira est activé, un TIMEOUT crée un ticket, tandis qu'un blocage, un crash ou un site inaccessible n'en créent jamais.

Quelles sont les limites ?

  • La classification analyse le texte d'erreur. Un message rédigé par vos soins contenant 403, Forbidden ou Access Denied est interprété comme BLOCKED. Veillez à ce que vos messages d'assertion personnalisés soient précis, et ouvrez metadata.json lorsqu'un verdict vous surprend.
  • Un TIMEOUT ne prouve pas que l'application fonctionne. Un test qui expire à chaque exécution mérite que l'on s'y intéresse.
  • Un délai d'attente plus long ne masque pas un élément défectueux : il échoue simplement plus tard.
  • Ces verdicts identifient la cause d'une exécution en échec. Ils n'en suppriment pas la cause : un site bloqué reste bloqué tant que vous ne modifiez pas votre façon d'y accéder.

Où puis-je le constater ?

La page Evidence suit un test ayant échoué et répertorie chaque fichier que chaque verdict laisse sur votre disque. Le guide des verdicts explique dans quel ordre le moteur détermine les 14 états. La version d'essai de 30 jours exécute ce même moteur sur vos propres tests.