Test end to end avec agent-browser : quel FPS pour la vidéo ?

Quel nombre de FPS choisir pour un test end to end ?

Commencez par 30 fps. C’est la nouvelle valeur par défaut : les clics ordinaires, les états au survol, le défilement, les transitions CSS et les démonstrations restent lisibles, sans la charge supplémentaire des 60 fps.

La plage valide de --fps va de 1 à 60. Une cadence élevée ne constitue pas automatiquement une meilleure preuve. Si la page se rafraîchit moins souvent que la valeur demandée, choisir 60 fps ne peut pas créer 60 états de page réellement distincts.

Ce qui change dans la v0.37.0

L’enregistreur traite désormais la vidéo comme une vue cadencée de la page réellement utilisée. record start et record restart capturent la page active à 30 fps par défaut, acceptent --fps 1-60 et s’appuient sur Page.startScreencast de Chrome. Il s’agit du flux d’images que Chrome produit lorsque la page est repeinte : comme si une caméra était directement branchée sur le pipeline d’affichage du navigateur, au lieu de prendre ponctuellement des captures d’écran.

La version v0.37.0 rend aussi les échecs plus sûrs. Si ffmpeg manque, si le chemin de sortie ne comporte pas d’extension ou si une option d’enregistrement est invalide, la commande échoue avant toute modification de l’état du navigateur ou de l’enregistrement. Si le démarrage d’une nouvelle prise échoue, la prise active est conservée. Pendant l’enregistrement, une navigation efface désormais les références d’éléments et l’état des frames devenus obsolètes, comme le fait une navigation normale.

Dans une véritable boucle de QA, cette différence compte. Un chemin vidéo incorrect ne doit pas modifier silencieusement la page testée, et le lancement d’une seconde prise ne doit pas détruire la première avant que son remplacement fonctionne réellement.

Le workflow d’enregistrement en cinq étapes

La séquence fiable consiste à vérifier, ouvrir, enregistrer, valider, puis arrêter. La dernière commande fait partie du contrat de preuve, car c’est elle qui vide les tampons et sauvegarde le fichier.

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. Vérifiez d’abord l’encodeur. agent-browser doctor indique la présence de ffmpeg et des encodeurs nécessaires à l’enregistrement. Le MP4 exige libx264 ; le WebM, libvpx. Une installation standard de ffmpeg via Homebrew ou sous Debian/Ubuntu comprend normalement les deux.

2. Placez la bonne page dans l’onglet actif. Sans URL fournie à record start, l’enregistreur se rattache à la page active exactement dans son état courant. Il ne la recharge pas, n’ouvre pas de nouvel onglet et ne crée pas de contexte de navigateur vierge. C’est utile lorsque le bug dépend d’une application déjà hydratée, d’une session authentifiée ou d’un état interne à la page. Si vous indiquez une URL, l’onglet actif y accède d’abord, puis l’enregistrement commence une fois la page chargée.

3. Choisissez le conteneur avec l’extension. .mp4 sélectionne H.264 via libx264 ; .webm sélectionne VP8 via libvpx. Les autres extensions sont transmises à ffmpeg avec H.264 et ne fonctionnent que si ffmpeg connaît le conteneur. Un nom de fichier sans extension est refusé.

4. Conservez le contrôle de réussite ou d’échec dans l’automatisation. Dans l’exemple, wait --url vérifie que le navigateur a atteint le tableau de bord. La vidéo aide une personne à comprendre ce qui s’est passé ; elle ne transforme pas les pixels en assertion de test.

5. Arrêtez l’enregistrement avant de fermer. record stop sauvegarde la prise après avoir vidé les tampons. Fermer d’abord la session peut vous laisser sans le fichier que vous vouliez conserver. Utilisez record restart pour terminer une prise et lancer immédiatement la suivante sur la page active.

capturedFrames et frames ne répondent pas à la même question

Ces deux compteurs représentent respectivement la matière première et la vidéo finalisée. capturedFrames comptabilise les frames distinctes produites par la page. frames compte celles qui ont été écrites dans le fichier vidéo. Une page statique peut ne générer que très peu d’images différentes, tandis que ffmpeg répète des frames pour que la prise reste regardable.

Une précision importante concerne le temps. Lorsque la page cesse de changer, la dernière frame est maintenue. Une même plage statique est conservée pendant cinq secondes au maximum, puis le reste de cette période sans changement est omis. En pratique, la vidéo restitue les courtes pauses, mais compresse les longues périodes d’inactivité. N’utilisez donc pas sa durée de lecture comme chronomètre pour un test d’endurance.

Un faible nombre de capturedFrames ne signale donc pas nécessairement un échec de l’enregistrement : la page était peut-être simplement immobile. C’est aussi la raison pour laquelle les 60 fps doivent être réservés aux mouvements qui méritent une inspection. Selon le guide d’enregistrement, 60 fps double approximativement le débit binaire par rapport à 30 fps, alors que le nombre de frames distinctes dépend toujours des rafraîchissements de la page.

La ligne budgétaire qui évolue

Si votre équipe utilise déjà agent-browser, la production d’une preuve vidéo simple ne doit plus forcément commencer par l’achat d’un autre poste pour un outil d’enregistrement. Le package v0.37.0 est distribué sous licence Apache-2.0 : l’enregistreur lui-même n’entraîne donc aucun coût de licence par utilisateur. Les coûts supplémentaires viennent de ce que vous exploitez réellement : configuration de ffmpeg, temps de CI, stockage des livrables et minutes consacrées par une personne à leur examen.

C’est une situation bien différente de l’achat d’une plateforme complète de feedback ou de test. Jam Team affiche $14 par créateur et par mois avec une facturation annuelle. BugHerd Standard affiche $50 par mois pour cinq membres avec une facturation mensuelle, vidéo de feedback comprise. BrowserStack Automate affiche une session parallèle Chrome Desktop à $59 par mois avec une facturation annuelle et inclut les enregistrements vidéo parmi ses outils de débogage.

Ces produits ne se limitent pas à l’enregistrement ; en conclure qu’ils peuvent être remplacés serait donc une erreur. BrowserStack commercialise une couverture de navigateurs gérée. BugHerd et Jam apportent collaboration, collecte des incidents et intégrations. La bonne décision économique est plus ciblée : inutile d’acheter une seconde couche de capture si agent-browser exécute déjà le parcours et que le seul livrable manquant est une vidéo lisible.

Sept cas d’usage, classés selon les équipes qui en profitent le plus

1. Les équipes produit qui diagnostiquent les échecs en CI

Face à un test de connexion ou de paiement instable, une équipe produit peut lancer un enregistrement à 30 fps juste avant le parcours à risque, conserver ses assertions d’URL ou d’éléments et archiver le MP4 comme livrable de CI en cas d’échec. L’ingénieur voit alors la bannière de consentement, l’overlay tardif, le déplacement du focus ou la transition qu’un journal texte peut manquer. Le bénéfice : moins de temps d’ingénierie gaspillé à tenter de recréer un état intermittent.

2. Les équipes front-end qui vérifient le glisser-déposer, le défilement et les animations

Un ingénieur front-end peut isoler une interaction courte et la capturer à 60 fps, puis associer la vidéo à des captures d’écran des états initial et final. La vidéo montre si le mouvement entre les deux est fluide ; les captures conservent les pixels exacts. L’approche devient rentable lorsque le défaut se situe entre deux captures, par exemple une frame perdue ou une cible de dépôt franchie au mauvais moment.

3. Les équipes produit IA qui auditent le comportement d’un agent navigateur

Une équipe produit IA peut filmer à 30 fps la page active authentifiée pendant que son agent accomplit une tâche, puis joindre la vidéo à la trace des commandes et aux assertions de l’agent. La personne chargée de la revue peut distinguer un mauvais plan d’une page qui a changé sous les yeux de l’agent. Une exécution opaque devient ainsi une preuve dont le product manager et l’ingénieur peuvent discuter ensemble.

4. Les ingénieurs QA qui reproduisent des bugs dépendants d’un état

Un ingénieur QA peut préparer la session jusqu’à réunir les conditions préalables au bug, puis lancer record start sans URL. Comme l’enregistrement se rattache à la page en place, celle-ci n’est pas remplacée par une navigation à froid. C’est précieux lorsque le bug dépend d’un panier déjà rempli, d’une fenêtre modale, d’une route authentifiée ou de toute autre condition qu’un rechargement ferait disparaître.

5. Les agences qui livrent une version à leur client

Une agence web peut enregistrer à 30 fps un parcours de recette, ajouter de courtes pauses aux points de décision et remettre au client une vidéo calibrée pour une personne plutôt que pour un moteur d’automatisation. Le client examine le parcours exact sans accéder au moteur de test. L’agence consacre ainsi moins de temps en réunion à commenter un flux que le livrable montre déjà.

6. Les équipes de fiabilité qui conservent les timelines des tests longs

Un ingénieur en fiabilité peut enregistrer un long test d’endurance à 10 fps lorsque la séquence importe davantage que le mouvement. Par rapport à 30 ou 60 fps, cette cadence réduit la charge de l’enregistrement et la croissance du fichier. La prise reste utile pour repérer le moment visible de l’échec, mais ses périodes statiques compressées imposent de tirer les horodatages des logs, et non de la durée de lecture.

7. Les équipes support qui escaladent un problème complexe dans le navigateur

Un ingénieur support peut reproduire le parcours d’un client dans un compte contrôlé, l’enregistrer à 30 fps, arrêter la prise et la joindre à l’escalade. L’équipe de développement reçoit le timing et les overlays inattendus qu’un ticket écrit restitue souvent mal. Le gain n’existe toutefois que si le workflow empêche aussi les secrets et les données client d’entrer dans l’enregistrement.

Trois produits qui méritent d’être construits

Meilleure opportunité : un dossier de preuves généré par l’agent

Construisez un petit service qui transforme l’exécution d’un agent navigateur en un dossier de revue unique : résultat de l’assertion, trace des commandes, capture d’écran finale, MP4, compteurs de frames et lien publié dans Jira ou Linear. Les équipes produit et ingénierie seraient prêtes à payer, car le résultat s’intègre au workflow de suivi des incidents qu’elles utilisent déjà.

La demande est concrète. Aux États-Unis, les données de recherche indiquent environ 590 recherches mensuelles pour « bug reporting tool », avec un CPC de $43.80. Les dépenses existantes sont tout aussi visibles : Jam Team coûte $14 par créateur et par mois avec une facturation annuelle, contre $50 par mois avec une facturation mensuelle pour BugHerd Standard. La plus petite version commercialisable demande un wrapper agent-browser, un espace de stockage des livrables, une intégration à un outil de suivi des incidents et une checklist de masquage.

C’est l’opportunité la plus solide, car elle vend la transmission du contexte, et non le codec. Son point faible reste une barrière technique limitée. La publication dans Jira et le stockage vidéo sont faciles à copier : le produit doit donc exceller dans l’assemblage d’un contexte fiable et la protection des données sensibles.

Un portail de recette QA pour les agences

Construisez une page de revue destinée aux clients : une agence choisit un parcours, l’exécute sur l’environnement de staging, puis publie l’assertion, les captures d’écran et une vidéo bien rythmée derrière un lien d’approbation unique. Les agences et les spécialistes QA à temps partiel constituent la cible, car la validation client est précisément le moment où une preuve technique se transforme souvent en réunion.

Aux États-Unis, les données de recherche indiquent 110 recherches mensuelles pour « website qa testing », en hausse de 55% sur un an, avec un CPC de $23.91. Un MVP pourrait gérer quelques parcours réutilisables, la capture à 30 fps, les commentaires et les actions d’approbation ou de refus. La difficulté vient de la richesse des acteurs établis : l’offre Standard de BugHerd réunit déjà projets illimités, utilisateurs clients, captures d’écran, métadonnées et feedback vidéo. Le nouveau produit doit gagner grâce aux preuves produites par l’agent, et non avec une énième épingle de commentaire.

Une couche de presets pour les tests de mouvement

Construisez un outil de CI léger qui classe les tests sous timeline, default ou motion, leur associe respectivement 10, 30 ou 60 fps et signale les écarts surprenants entre les frames capturées et écrites. Les équipes chargées des plateformes front-end seraient prêtes à payer pour uniformiser les preuves liées aux régressions d’animation et d’interaction.

Aux États-Unis, les données de recherche indiquent 110 recherches mensuelles pour « automated browser testing », avec un CPC de $14.96. L’expression commerciale plus précise « automated browser testing tools » n’enregistre que 20 recherches mensuelles, mais affiche un CPC de $63.21 : le signe que ce petit vivier d’acheteurs coûte cher à atteindre. Le MVP consiste en un manifeste de tests, un wrapper pour les commandes agent-browser, des vidéos conservées uniquement en cas d’échec et un index compact des livrables.

La dynamique est toutefois moins favorable : le mot-clé général recule de 18% sur un an, et les 60 fps ajoutent de la charge tout en restant limités par la fréquence de rafraîchissement de la page. Mieux vaut commencer par une fonctionnalité intégrée à un produit de gestion des preuves que par une offre autonome.

Ce que l’enregistrement ne prouve pas

La vidéo apporte de l’observabilité, pas une preuve de bon fonctionnement. Elle ne permet pas de savoir si la bonne ligne a été écrite dans la base de données, si une réponse d’API était valide ou si tous les navigateurs et appareils se comportent de la même manière. Conservez les assertions, les logs et les captures d’écran à ses côtés.

Elle ne supprime pas non plus les risques liés à l’environnement. L’enregistrement exige ffmpeg dans le PATH et l’encodeur correspondant. Les cadences élevées augmentent la charge, les longues vidéos occupent de l’espace disque et les machines headless contraintes peuvent rencontrer des limites de codec ou de GPU. Une page qui se rafraîchit lentement ne peut pas fournir 60 frames distinctes par seconde.

Traitez la confidentialité comme une exigence produit. L’enregistreur capture la zone visible active et l’état interne de la page : c’est précisément ce qui le rend utile, mais aussi ce qui impose des règles réfléchies sur les comptes de test, le masquage des secrets, la conservation des livrables et le contrôle d’accès. Il s’agit d’un choix opérationnel, et non d’une promesse intégrée de masquage.

Enfin, agent-browser enregistre la preuve, mais ne l’interprète pas. Si vous souhaitez qu’un modèle examine la vidéo après l’exécution, il faut un système distinct, plus proche de la compréhension agentique de la vidéo. Gardez cette couche séparée du contrôle déterministe de réussite ou d’échec.

L’action à lancer lundi

La semaine prochaine, choisissez un parcours de connexion, de paiement ou de publication sujet aux échecs. Exécutez doctor, enregistrez la page active existante à 30 fps, conservez l’assertion actuelle, appelez record stop, puis joignez le MP4 au résultat du test. Ne passez à 60 fps que si la personne chargée de la revue ne peut pas évaluer un défaut de mouvement ; descendez à 10 fps lorsqu’un test long sert surtout à suivre une séquence. Le pilote est concluant si l’échec peut être diagnostiqué sans relancer le test, pas si la vidéo est simplement fluide.

Si vous voulez un agent navigateur qui produise des preuves prêtes à être examinées par votre équipe, je peux le construire autour de votre véritable workflow QA.