Agent browser: come registrare video QA con gli FPS giusti

Agent browser: come scegliere gli FPS della registrazione

Parti da 30 fps. È il nuovo valore predefinito perché clic comuni, stati hover, scorrimento, transizioni CSS e walkthrough restano leggibili senza il carico aggiuntivo dei 60 fps.

L’intervallo valido per --fps va da 1 a 60. Un valore più alto non produce automaticamente un’evidenza migliore. Se la pagina viene ridisegnata meno spesso del frame rate richiesto, impostare 60 fps non può generare 60 stati della pagina davvero diversi.

Cosa cambia in v0.37.0

Il registratore ora considera il video una rappresentazione temporizzata della pagina che stai realmente usando. record start e record restart acquisiscono per impostazione predefinita la pagina attiva a 30 fps, accettano --fps 1-60 e usano Page.startScreencast di Chrome. È il flusso con cui Chrome fornisce i frame ridisegnati dalla pagina: come collegare una videocamera direttamente alla pipeline di visualizzazione del browser, invece di scattare screenshot sporadici.

La release v0.37.0 ha anche reso più rigorosa la gestione degli errori. Se manca ffmpeg, il percorso di output non ha estensione o un’opzione di registrazione non è valida, il comando fallisce prima che cambino lo stato del browser o quello della registrazione. Se una nuova registrazione non riesce ad avviarsi, quella attiva viene preservata. Durante una registrazione, la navigazione ora elimina riferimenti obsoleti agli elementi e lo stato dei frame proprio come avviene nella navigazione normale.

In un ciclo QA reale fa la differenza. Un percorso video errato non dovrebbe modificare in silenzio la pagina sotto test, e l’avvio di una seconda registrazione non dovrebbe distruggere la prima prima di sapere se quella sostitutiva funziona.

Il flusso di registrazione in cinque passaggi

La sequenza affidabile è: verifica, apertura, registrazione, asserzione e arresto. Anche il comando finale fa parte del contratto dell’evidenza, perché completa la scrittura e salva il file.

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. Verifica prima l’encoder. agent-browser doctor segnala ffmpeg e gli encoder disponibili per la registrazione. MP4 richiede libx264; WebM richiede libvpx. Una normale build di ffmpeg per Homebrew o Debian/Ubuntu li include in genere entrambi.

2. Porta la pagina corretta nella scheda attiva. Se record start non riceve un URL, il registratore si collega alla pagina attiva esattamente nello stato in cui si trova. Non la ricarica, non apre una nuova scheda e non crea un contesto del browser pulito. È utile quando il bug dipende da un’app già inizializzata, da una sessione autenticata o dallo stato interno della pagina. Se fornisci un URL, prima viene caricata la destinazione nella scheda attiva e la registrazione parte al termine del caricamento.

3. Scegli il contenitore tramite l’estensione. .mp4 seleziona H.264 tramite libx264; .webm seleziona VP8 tramite libvpx. Le altre estensioni vengono passate a ffmpeg con H.264 e funzionano soltanto se ffmpeg riconosce il contenitore. Un nome file senza estensione viene rifiutato.

4. Lascia nell’automazione il controllo di superamento o fallimento. Nell’esempio, wait --url verifica che il browser abbia raggiunto la dashboard. Il clip aiuta una persona a capire cosa è successo, ma non trasforma i pixel in un’asserzione di test.

5. Arresta la registrazione prima di chiudere. record stop salva la registrazione e completa la scrittura. Chiudendo prima la sessione, potresti ritrovarti senza il file che volevi conservare. Usa record restart quando vuoi chiudere una registrazione e avviare subito la successiva sulla pagina attiva.

capturedFrames e frames rispondono a domande diverse

Considera i due contatori come materiale sorgente e filmato finito. capturedFrames conta i frame distinti prodotti dalla pagina. frames conta quelli scritti nel file video. Una pagina statica può generare pochissime immagini diverse, mentre ffmpeg ripete i frame per mantenere la registrazione riproducibile.

C’è un’importante particolarità temporale. Quando la pagina smette di cambiare, l’ultimo frame viene mantenuto. Una singola pausa statica resta visibile per un massimo di cinque secondi; il resto di quel periodo invariato viene poi omesso. In pratica, il video conserva le pause brevi ma comprime i lunghi intervalli inattivi. Per misurare la durata di un test di resistenza, non usare il tempo di riproduzione come cronometro.

Un valore basso di capturedFrames, quindi, non indica automaticamente una registrazione non riuscita: può semplicemente significare che la pagina era immobile. Per lo stesso motivo, conviene riservare i 60 fps ai movimenti che meritano un’analisi: la guida alla registrazione indica che 60 fps raddoppiano all’incirca il bitrate rispetto a 30 fps, mentre il numero di frame distinti continua a dipendere dai ridisegni della pagina.

La voce di budget che cambia

Se il team usa già agent-browser, le evidenze video di base non devono più partire dall’acquisto di un’altra licenza per un registratore. Il pacchetto v0.37.0 dichiara una licenza Apache-2.0, quindi il registratore non comporta un costo software per utente. I costi incrementali riguardano ciò che devi gestire: configurazione di ffmpeg, tempo CI, archiviazione degli artefatti e minuti impiegati da una persona per esaminare il risultato.

È una situazione sostanzialmente diversa dall’acquisto di una piattaforma completa per feedback o test. Jam Team indica $14 al mese per creator con fatturazione annuale. BugHerd Standard indica $50 al mese per cinque membri con fatturazione mensile e include il feedback video. BrowserStack Automate indica $59 al mese, con fatturazione annuale, per un’esecuzione parallela su Chrome Desktop e include le registrazioni video tra gli strumenti di debug.

Questi prodotti offrono molto più della registrazione, quindi concludere che possano essere sostituiti sarebbe sbagliato. BrowserStack offre una copertura gestita dei browser. BugHerd e Jam vendono collaborazione, acquisizione dei problemi e integrazioni. La decisione utile sui costi è più circoscritta: non acquistare un secondo livello di acquisizione quando agent-browser esegue già il flusso e l’unico artefatto mancante è un video leggibile.

Sette casi d’uso, ordinati per chi ne ricava più valore

1. Team di prodotto alle prese con flussi CI non riusciti

Un team di prodotto con un test instabile di login o checkout può avviare una registrazione a 30 fps subito prima del percorso a rischio, mantenere le asserzioni su URL o elementi e conservare l’MP4 come artefatto CI quando l’esecuzione fallisce. L’ingegnere vede il banner del consenso, l’overlay arrivato in ritardo, il salto del focus o la transizione che un log testuale potrebbe non mostrare. Il risultato è meno tempo di sviluppo retribuito speso nel tentativo di ricreare uno stato intermittente.

2. Team front-end che verificano trascinamenti, scorrimento e animazioni

Un ingegnere front-end può isolare una breve interazione e acquisirla a 60 fps, quindi affiancare al clip gli screenshot dello stato iniziale e finale. Il video mostra se il movimento tra i due stati è stato fluido; gli screenshot conservano i pixel esatti. È utile quando il difetto si manifesta tra due schermate, per esempio con un frame perso o un target di trascinamento attraversato nel momento sbagliato.

3. Team di prodotto AI che verificano il comportamento degli agenti browser

Un team di prodotto AI può registrare a 30 fps la pagina attiva già autenticata mentre l’agente svolge un’attività, quindi allegare il video alla traccia dei comandi e alle asserzioni dell’agente. Chi revisiona può distinguere un piano sbagliato da una pagina cambiata durante l’esecuzione. Un processo opaco diventa così un’evidenza su cui product manager e ingegnere possono confrontarsi.

4. Ingegneri QA che riproducono bug legati allo stato

Un ingegnere QA può preparare la sessione fino a ricreare le precondizioni del bug, quindi eseguire record start senza URL. Poiché la registrazione si collega alla pagina nello stato corrente, questa non viene sostituita da una navigazione a freddo. È vantaggioso quando il bug dipende dallo stato accumulato del carrello, da una finestra modale, da una rotta autenticata o da un’altra condizione che scompare al ricaricamento.

5. Agenzie che consegnano una release al cliente

Un’agenzia web può registrare a 30 fps un percorso di accettazione, aggiungere brevi attese nei punti decisionali e consegnare al cliente un clip con un ritmo adatto a una persona, anziché a un motore di automazione. Il cliente può esaminare il percorso esatto senza accedere al test runner. L’agenzia dedica meno tempo in riunione a spiegare un flusso che l’artefatto rende già visibile.

6. Team di affidabilità che conservano timeline di esecuzioni lunghe

Un ingegnere dell’affidabilità può registrare un lungo test di durata a 10 fps quando la sequenza conta più del movimento. Rispetto a 30 o 60 fps, il frame rate inferiore riduce il carico della registrazione e la crescita del file. Il video resta utile per individuare il momento visibile dell’errore, ma la compressione degli intervalli statici impone di ricavare i timestamp dai log, non dalla durata della riproduzione.

7. Tecnici del supporto che inoltrano un problema difficile del browser

Un tecnico del supporto può riprodurre il percorso di un cliente in un account controllato, registrarlo a 30 fps, arrestare la registrazione e allegarla all’escalation. Il team di sviluppo riceve così dettagli sui tempi e sugli overlay inattesi che spesso si perdono in un ticket scritto. Il vantaggio esiste soltanto se il flusso impedisce anche che segreti e dati dei clienti finiscano nella registrazione.

Tre prodotti che vale la pena costruire

L’opportunità migliore: un pacchetto di evidenze per le esecuzioni degli agenti

Realizza un piccolo servizio che trasformi una singola esecuzione di un agente browser in un unico pacchetto da revisionare: esito dell’asserzione, traccia dei comandi, screenshot finale, MP4, contatori dei frame e un link pubblicato su Jira o Linear. I team di prodotto e sviluppo sarebbero disposti a pagare perché l’output entra nel flusso di gestione dei problemi che usano già.

La domanda è concreta. I dati sulle keyword negli Stati Uniti indicano circa 590 ricerche al mese per “bug reporting tool”, con un CPC di $43.80. Anche la spesa esistente è visibile: Jam Team costa $14 al mese per creator con fatturazione annuale, mentre BugHerd Standard costa $50 al mese con fatturazione mensile. La versione minima vendibile richiede un wrapper per agent-browser, l’archiviazione degli artefatti, un’integrazione con un issue tracker e una checklist per l’oscuramento dei dati.

È l’opportunità più forte perché vende il passaggio di consegne, non il codec. Il limite è una barriera tecnica modesta. La pubblicazione su Jira e l’archiviazione video sono facili da copiare: il prodotto deve quindi diventare eccezionale nel comporre un contesto affidabile e nel tenere fuori i dati sensibili.

Un portale per le consegne QA delle agenzie

Realizza una pagina di revisione per i clienti in cui un’agenzia sceglie un flusso, lo esegue sull’ambiente di staging e pubblica asserzione, screenshot e video con il giusto ritmo sotto un unico link di approvazione. Le agenzie e i team QA in modalità fractional sono gli acquirenti ideali, perché l’approvazione del cliente è il punto in cui le evidenze tecniche si trasformano spesso in una riunione.

I dati sulle keyword negli Stati Uniti indicano 110 ricerche al mese per “website qa testing”, in crescita del 55% anno su anno, con un CPC di $23.91. Un MVP potrebbe supportare alcuni flussi riutilizzabili, l’acquisizione a 30 fps, i commenti e l’approvazione o il rifiuto. Il limite è la profondità degli operatori già presenti: il piano Standard di BugHerd comprende già progetti illimitati, utenti cliente, screenshot, metadati e feedback video. Il nuovo prodotto deve vincere grazie alle evidenze prodotte dall’agente, non con un altro pin per i commenti.

Un livello di preset per i test del movimento

Realizza un piccolo strumento CI che etichetti i test come timeline, default o motion, li associ a 10, 30 o 60 fps e segnali differenze inattese tra i frame acquisiti e quelli scritti. I team responsabili delle piattaforme front-end pagherebbero per ottenere evidenze coerenti tra regressioni delle animazioni e delle interazioni.

I dati sulle keyword negli Stati Uniti indicano 110 ricerche al mese per “automated browser testing”, con un CPC di $14.96. La query commerciale più specifica “automated browser testing tools” registra appena 20 ricerche mensili, ma ha un CPC di $63.21: un segnale che il piccolo bacino di acquirenti è costoso da raggiungere. Per l’MVP servono un manifest dei test, un wrapper dei comandi di agent-browser, clip conservati soltanto in caso di errore e un indice compatto degli artefatti.

Il limite è uno slancio più debole: la keyword più ampia è in calo del 18% anno su anno, mentre i 60 fps aumentano il carico e restano comunque vincolati alla frequenza di ridisegno della pagina. Dovrebbe nascere come funzionalità di un prodotto dedicato alle evidenze, non come azienda indipendente.

Cosa non dimostra la registrazione

Il video offre osservabilità, non dimostra la correttezza. Non può dirti se è stata scritta la riga giusta nel database, se una risposta API era valida o se tutti i browser e i dispositivi si comportano allo stesso modo. Affiancagli asserzioni, log e screenshot.

Non elimina neppure i rischi dell’ambiente. La registrazione richiede ffmpeg nel PATH e l’encoder corrispondente. Frame rate più alti aumentano il carico, le registrazioni lunghe consumano spazio su disco e le macchine headless con risorse limitate possono incontrare limiti di codec o GPU. Una pagina che viene ridisegnata lentamente non può fornire 60 frame distinti ogni secondo.

Considera la privacy un requisito di prodotto. Il registratore acquisisce il viewport attivo e lo stato interno della pagina: proprio ciò che lo rende utile e che rende necessarie regole precise per account di test, mascheramento dei segreti, conservazione degli artefatti e controllo degli accessi. Si tratta di una valutazione operativa, non di una promessa integrata di oscuramento dei dati.

Infine, agent-browser registra l’evidenza ma non la interpreta. Se vuoi che un modello analizzi il filmato dopo l’esecuzione, serve un sistema separato, più vicino alla comprensione agentica dei video. Mantieni questo livello distinto dal controllo deterministico di superamento o fallimento.

La prossima mossa per lunedì

La prossima settimana scegli un percorso di login, checkout o pubblicazione incline agli errori. Esegui doctor, registra a 30 fps la pagina attiva già esistente, mantieni l’asserzione corrente, chiama record stop e allega l’MP4 al risultato del test. Passa a 60 fps soltanto se chi revisiona non riesce a valutare un difetto di movimento; scendi a 10 fps quando un’esecuzione lunga serve soprattutto a mostrare una sequenza. Il progetto pilota ha successo quando una persona può diagnosticare l’errore senza ripetere l’esecuzione, non quando il video si limita ad apparire fluido.

Se vuoi un agente browser che produca evidenze pronte per la revisione del tuo team, posso realizzarlo intorno al tuo vero flusso QA.