Superato o fallito non basta: come vengono determinati i 14 verdetti

Un test rosso dovrebbe indicare che l'applicazione non funziona. Quando il rosso può anche significare che il DNS ha avuto un problema momentaneo, il sito ha mostrato un CAPTCHA o il browser si è bloccato, il gruppo di lavoro impara a rieseguire i test rossi invece di analizzarli, e il vero difetto si nasconde nel rumore. Nexus Studio assegna a ogni esecuzione uno di 14 verdetti anziché due. Questa pagina spiega come il motore ne sceglie uno, nell'ordine in cui prende le decisioni, e quali sono i limiti del metodo.

A cura del gruppo di lavoro di Nexus Studio, Verdict System LLC. 7 ottobre 2026.

Quali sono i 14 verdetti?

I 14 verdetti sono SECURE, CHAOS_RESILIENT, AUTO_RECOVER, FLAKY, PERFORMANCE_DEGRADED, A11Y_VIOLATION, SECURITY_VIOLATION, BREACHED, BREACHED_FLAKY, CHAOS_BREACHED, TIMEOUT, UNREACHABLE, BLOCKED e CRASHED. Rientrano in quattro gruppi: superato, superato con riserva, l'applicazione ha smesso di funzionare e nessun verdetto sull'applicazione perché il problema è nell'ambiente o nell'infrastruttura di test.

Come decide il motore quale verdetto assegnare?

Il motore pone tre domande, in questo ordine:

1. Il test ha prodotto un risultato?
2. Se è stato superato, lo è stato senza interventi?
3. Se è fallito, di chi è la colpa: del sistema di test, dell'ambiente o dell'applicazione?

Solo una risposta costituisce una segnalazione di difetto: un fallimento imputabile all'applicazione. Ogni altra risposta fornisce informazioni su qualcos'altro e riceve un nome che lo chiarisce.

Quando un test non riceve alcun verdetto?

Tre stati non rientrano nei 14, perché nessuno di essi dice nulla sulla tua applicazione: SKIPPED (il test non è mai stato eseguito), INTERRUPTED (Ctrl+C, una soglia --max-failures o un limite di tempo globale lo ha interrotto) e CONFIG_ERROR (il sistema di test non è riuscito ad avviarlo). Nessuno di essi genera una cartella delle prove o una riga nella Cronologia.

INTERRUPTED esiste per un motivo concreto. Senza questo stato, un test interrotto finiva nel ramo dei test superati e veniva registrato come SECURE: un verdetto verde per un test mai terminato.

Come viene valutato un test superato?

• SECURE: superato al primo tentativo, senza alcuna correzione.
• AUTO_RECOVER: superato, ma la correzione automatica ha dovuto sostituire un selettore in questo test. Il localizzatore scritto dall'autore non funziona più, e la prossima modifica alla pagina comprometterà davvero la suite di test, quindi un test superato grazie a una correzione non viene mai indicato come privo di problemi. Correggi il selettore originale.
• FLAKY: fallito, poi superato a un nuovo tentativo, senza alcuna correzione automatica. Qualcosa è instabile, nell'applicazione o nel test, e nulla è stato risolto.

Un'eccezione: quando il primo tentativo è fallito solo perché ha esaurito il tempo a disposizione e il tentativo successivo è stato superato, il verdetto è SECURE. Quel risultato indica latenza, non instabilità.

Come viene assegnato un verdetto a un errore?

Quando un test fallisce, il motore legge il messaggio di errore e il registro di rete dell'esecuzione e li confronta con gruppi di schemi in un ordine fisso. Il primo gruppo che trova una corrispondenza determina il verdetto, quindi l'ordine è parte integrante della progettazione.

1. CONFIG_ERROR per primo: Cannot find module, un ReferenceError o SyntaxError, una variabile d'ambiente mancante, una fixture che ha generato un errore durante la preparazione. Se il sistema di test non si è mai avviato, qualsiasi sintomo successivo ne è una conseguenza. Gli schemi sono volutamente circoscritti, limitati a errori che solo il codice di test o il suo ambiente possono produrre: un CONFIG_ERROR di troppo attribuirebbe al sistema di test la colpa di un vero difetto della tua applicazione.
2. CRASHED: Target closed, Page crashed, un errore del protocollo DevTools, SessionNotCreatedError, un identificativo di sessione non valido. Il browser o il driver ha smesso di funzionare. È un problema infrastrutturale: controlla la macchina e il driver.
3. BLOCKED: un 403 o un 429 nell'errore o nel registro di rete, un CAPTCHA, una pagina di accesso negato o una verifica anti-bot riconosciuta sullo schermo dal motore. Il sito si è difeso e la richiesta non ha mai raggiunto il tuo prodotto.
4. UNREACHABLE: la rete ha detto no prima che fosse osservata qualsiasi pagina: il nome non è stato risolto (net::ERR_NAME_NOT_RESOLVED in Chromium, NS_ERROR_UNKNOWN_HOST in Firefox, Could not resolve hostname in WebKit), la connessione è stata rifiutata o la macchina non era in rete. Un errore di certificato non rientra in questa categoria: quello è un problema rilevato.
5. TIMEOUT: Timeout 30000ms exceeded di Playwright, Wait timed out after di Selenium, un TimeoutError o un test che Playwright ha contrassegnato come scaduto per superamento del tempo massimo. Una navigazione che ha esaurito il tempo a disposizione è un TIMEOUT, non un UNREACHABLE: è iniziata, ma la pagina era lenta.
6. BREACHED_FLAKY: nessuna delle condizioni precedenti lo spiega e il test era già stato ritentato. È fallito, e il fallimento stesso non è costante. Confronta i tentativi prima di segnalare un difetto.
7. BREACHED: nessuna delle condizioni precedenti lo spiega, con un solo tentativo. Un'asserzione è fallita e nessuno schema relativo all'ambiente o al sistema di test giustifica l'errore. Questa è la segnalazione di difetto.

Ogni gruppo copre le formulazioni sia di Playwright sia di Selenium WebDriver. Prima che esistessero i criteri di riconoscimento per Selenium, un TimeoutError di WebDriver e un SessionNotCreatedError di un chromedriver obsoleto venivano entrambi segnalati come BREACHED, come se l'applicazione avesse un difetto.

Anche un telefono Android reale che non può eseguire il test, perché è entrato in sospensione o è bloccato, viene classificato come BLOCKED: un prerequisito non soddisfatto, non un malfunzionamento del prodotto. La regola nasce da un caso misurato. Un telefono è entrato in sospensione a metà di una campagna, e un test di accesso superato per quattro volte di seguito è risultato rosso con gravità critica.

Come vengono valutate le esecuzioni con iniezione di guasti?

Quando l'esecuzione introduce guasti da Chaos Lab, il verdetto risponde a una domanda diversa: l'applicazione ha retto? Un esito positivo, SECURE o AUTO_RECOVER, diventa CHAOS_RESILIENT. Qualsiasi altro esito diventa CHAOS_BREACHED, compresi un esito positivo FLAKY e un TIMEOUT, perché in presenza di un guasto introdotto ne rappresentano l'impatto. SKIPPED, INTERRUPTED e CONFIG_ERROR restano invariati: un test non eseguito non dice nulla sulla resilienza.

Quali controlli rigorosi possono modificare un esito positivo?

Tre controlli vengono eseguiti insieme alle asserzioni: intestazioni di sicurezza, accessibilità con axe-core e limiti di prestazioni per Web Vitals e caricamento differito. Registrano ciò che rilevano a ogni esecuzione. Cambiano il verdetto solo quando li rendi rigorosi nelle Impostazioni. Su un'applicazione esistente, uno qualsiasi di questi controlli renderebbe rossa l'intera suite fin dal primo giorno, e una suite sempre rossa è una suite che nessuno legge.

Quando sono rigorosi, si applicano solo a un test superato, in questo ordine: SECURITY_VIOLATION, A11Y_VIOLATION, PERFORMANCE_DEGRADED. La sicurezza viene prima perché, delle tre, è quella che può sfociare in un incidente anziché in un reclamo. A un test fallito non viene mai assegnata una classificazione ulteriore: BREACHED indica già qualcosa di più grave, e aggiungere un avviso nasconderebbe il problema rilevato.

Cosa vede la CI?

I sette verdetti positivi restituiscono il codice di uscita 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION e SECURITY_VIOLATION. Una riserva compare nel rapporto e nella Cronologia, non come compilazione non riuscita. Gli altri sette restituiscono il codice di uscita 1. Gli esecutori pytest e Selenium restituiscono il codice di uscita 2 quando l'esecuzione non è potuta nemmeno iniziare, per esempio in assenza di Python o con un browser per cui il motore non dispone di un driver.

Quali sono i limiti del metodo?

• La classificazione legge il testo degli errori. Un messaggio scritto da te che contiene 403, Forbidden o Access Denied viene interpretato come BLOCKED, e un errore che contiene is not a function viene interpretato come CONFIG_ERROR. Mantieni specifici i messaggi di asserzione personalizzati, e apri metadata.json quando un verdetto ti sorprende.
• Un TIMEOUT non dimostra che l'applicazione funzioni. Indica che l'esecuzione non permette di stabilirlo. Un test che supera il tempo limite a ogni esecuzione merita attenzione.
• I tentativi successivi distinguono FLAKY da SECURE e BREACHED_FLAKY da BREACHED. Se i tentativi successivi sono disattivati, un errore intermittente viene classificato come BREACHED.
• I test API hanno sette verdetti propri, determinati da altre regole: vedi Test API.

Dove posso vedere un verdetto su un errore effettivo?

La pagina delle prove segue un test fallito ed elenca tutti i file che ogni verdetto lascia sul disco: report.md, metadata.json, raw-data.json, una schermata e, per un errore reale, il video. La prova di 30 giorni esegue lo stesso motore sui tuoi test.