Geslaagd of mislukt is niet genoeg: hoe 14 oordelen worden bepaald

Een rode test zou moeten betekenen dat de applicatie niet werkt. Als rood ook kan betekenen dat de DNS even haperde, de site een CAPTCHA toonde of de browser vastliep, leert het team rode tests opnieuw uit te voeren in plaats van ze te bekijken, en verdwijnt het echte defect in de ruis. Nexus Studio geeft elke uitvoering een van 14 oordelen in plaats van twee. Deze pagina legt uit hoe de engine er een kiest, in de volgorde waarin hij beslist, en waar de methode haar grenzen heeft.

Door het team van Nexus Studio, Verdict System LLC. 7 oktober 2026.

Wat zijn de 14 oordelen?

De 14 oordelen zijn SECURE, CHAOS_RESILIENT, AUTO_RECOVER, FLAKY, PERFORMANCE_DEGRADED, A11Y_VIOLATION, SECURITY_VIOLATION, BREACHED, BREACHED_FLAKY, CHAOS_BREACHED, TIMEOUT, UNREACHABLE, BLOCKED en CRASHED. Ze vallen in vier groepen: geslaagd, geslaagd met een voorbehoud, de toepassing werkte niet naar behoren, en geen oordeel over de toepassing omdat de oorzaak bij de omgeving of het testraamwerk ligt.

Hoe bepaalt de engine een oordeel?

De engine stelt drie vragen, in deze volgorde:

1. Heeft de test überhaupt een resultaat opgeleverd?
2. Als de test is geslaagd, was dat zonder ingrepen?
3. Als de test is mislukt, waar ligt de fout: bij het testraamwerk, de omgeving of de applicatie?

Slechts één antwoord levert een bugmelding op: een fout die aan de applicatie ligt. Elk ander antwoord geeft informatie over iets anders en krijgt een naam die dat duidelijk maakt.

Wanneer krijgt een test helemaal geen oordeel?

Drie statussen vallen buiten de 14, omdat geen ervan iets over je applicatie zegt: SKIPPED (de test is nooit uitgevoerd), INTERRUPTED (Ctrl+C, een --max-failures-limiet of een algemene time-out heeft de test gestopt) en CONFIG_ERROR (het testraamwerk kon de test niet starten). Geen ervan levert een bewijsmap of een rij in de geschiedenis op.

INTERRUPTED bestaat om een concrete reden. Zonder deze status belandde een gestopte test in de tak voor geslaagde tests en werd deze vastgelegd als SECURE: een groen oordeel voor een test die nooit is voltooid.

Hoe wordt een geslaagde test beoordeeld?

• SECURE: bij de eerste poging geslaagd, zonder dat er iets is hersteld.
• AUTO_RECOVER: geslaagd, maar automatisch herstel moest in deze test een selector vervangen. De locator die de auteur schreef werkt niet meer, en bij de volgende wijziging aan de pagina gaat de testsuite echt stuk, dus een geslaagde test met automatisch herstel wordt nooit als probleemloos gerapporteerd. Herstel de oorspronkelijke selector.
• FLAKY: mislukt, daarna bij een nieuwe poging geslaagd, zonder dat er iets automatisch is hersteld. Er is iets instabiel, in de applicatie of in de test, en er is niets opgelost.

Eén uitzondering: als de eerste poging alleen mislukte doordat de tijd verstreek en de nieuwe poging slaagde, is het oordeel SECURE. Die geslaagde poging wijst op vertraging, niet op instabiliteit.

Hoe krijgt een mislukte test een oordeel toegewezen?

Wanneer een test mislukt, leest de engine de foutmelding en het netwerklogboek van de uitvoering en vergelijkt deze in een vaste volgorde met groepen patronen. De eerste groep die overeenkomt bepaalt het oordeel, dus de volgorde maakt deel uit van het ontwerp.

1. CONFIG_ERROR eerst: Cannot find module, een ReferenceError of SyntaxError, een ontbrekende omgevingsvariabele, een fixture die tijdens de voorbereiding mislukte. Als het testraamwerk nooit is gestart, is elk later symptoom daar een gevolg van. De patronen zijn bewust strikt afgebakend tot fouten die alleen de testcode of de bijbehorende omgeving kan veroorzaken: één CONFIG_ERROR te veel zou het testraamwerk de schuld geven van een echte bug in je applicatie.
2. CRASHED: Target closed, Page crashed, een DevTools-protocolfout, SessionNotCreatedError, een ongeldige sessie-id. De browser of het stuurprogramma is uitgevallen. Dit ligt aan de infrastructuur: controleer de machine en het stuurprogramma.
3. BLOCKED: een 403 of een 429 in de foutmelding of het netwerklogboek, een CAPTCHA, een pagina die de toegang weigert, of een botcontrole die de engine op het scherm herkende. De site beschermde zichzelf en het verzoek heeft je product nooit bereikt.
4. UNREACHABLE: het netwerk weigerde dienst voordat er een pagina werd waargenomen: de naam kon niet worden omgezet (net::ERR_NAME_NOT_RESOLVED in Chromium, NS_ERROR_UNKNOWN_HOST in Firefox, Could not resolve hostname in WebKit), de verbinding werd geweigerd of de machine was offline. Een certificaatfout valt hier niet onder: dat is een bevinding.
5. TIMEOUT: Timeout 30000ms exceeded van Playwright, Wait timed out after van Selenium, een TimeoutError, of een test die Playwright markeerde als verlopen. Een navigatie waarbij de tijd verstreek is een TIMEOUT, geen UNREACHABLE: de navigatie is gestart en de pagina was traag.
6. BREACHED_FLAKY: niets hierboven verklaart het en de test was al opnieuw geprobeerd. De test is mislukt en de fout zelf treedt niet consistent op. Vergelijk de pogingen voordat je een bug meldt.
7. BREACHED: niets hierboven verklaart het, bij één enkele poging. Een assertie is mislukt en geen enkel patroon voor de omgeving of het testraamwerk verklaart de fout. Dit is de bugmelding.

Elke groep omvat zowel de formuleringen van Playwright als die van Selenium WebDriver. Voordat de Selenium-patronen bestonden, werden een TimeoutError van WebDriver en een SessionNotCreatedError van een verouderde chromedriver allebei als BREACHED gemeld, alsof de applicatie een defect had.

Een echte Android-telefoon die de uitvoering niet aankan omdat hij in slaapstand staat of vergrendeld is, krijgt ook BLOCKED: een onvervulde voorwaarde, geen productfout. De regel is gebaseerd op een gemeten geval. Een telefoon ging halverwege een campagne in slaapstand, waarna een inlogtest die vier keer achter elkaar was geslaagd als kritieke fout in het rood eindigde.

Hoe worden chaos-testuitvoeringen beoordeeld?

Wanneer de uitvoering fouten injecteert vanuit Chaos Lab, beantwoordt het oordeel een andere vraag: hield de applicatie stand? Een geslaagde test, SECURE of AUTO_RECOVER, wordt CHAOS_RESILIENT. Al het andere wordt CHAOS_BREACHED, inclusief een geslaagde test met FLAKY en een TIMEOUT, omdat die bij een geïnjecteerde fout de gevolgen daarvan zijn. SKIPPED, INTERRUPTED en CONFIG_ERROR blijven ongewijzigd: een test die niet is uitgevoerd, zegt niets over weerbaarheid.

Welke strikte controles kunnen een geslaagde uitkomst veranderen?

Naast je asserties worden drie controles uitgevoerd: beveiligingsheaders, toegankelijkheid met axe-core en prestatiebudgetten voor Web Vitals en uitgesteld laden. Bij elke uitvoering leggen ze hun bevindingen vast. Ze veranderen het oordeel alleen wanneer je ze in Instellingen op streng zet. Bij een bestaande applicatie zou elk ervan de hele testsuite op de eerste dag rood kleuren, en een testsuite die altijd rood is, bekijkt niemand meer.

Als ze op streng staan, gelden ze alleen voor een geslaagde test, in deze volgorde: SECURITY_VIOLATION, A11Y_VIOLATION, PERFORMANCE_DEGRADED. Beveiliging komt eerst, omdat die van de drie kan uitmonden in een incident in plaats van een klacht. Een mislukte test wordt nooit opgeschaald: BREACHED duidt al op iets ernstigers, en een aanvullende waarschuwing zou die bevinding verhullen.

Wat ziet CI?

De zeven oordelen voor geslaagde tests geven afsluitcode 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION en SECURITY_VIOLATION. Een voorbehoud verschijnt in het rapport en in Geschiedenis, niet als een mislukte build. De andere zeven geven afsluitcode 1. De pytest- en Selenium-runners geven afsluitcode 2 wanneer de uitvoering helemaal niet kon starten, bijvoorbeeld als Python ontbreekt of als de engine geen stuurprogramma voor de browser heeft.

Wat zijn de beperkingen van de methode?

• De classificatie leest foutteksten. Een zelfgeschreven melding met 403, Forbidden of Access Denied wordt geïnterpreteerd als BLOCKED, en een fout met is not a function als CONFIG_ERROR. Houd aangepaste assertiemeldingen specifiek en open metadata.json als een oordeel je verrast.
• Een TIMEOUT bewijst niet dat de applicatie werkt. Het betekent dat de uitvoering daarover geen uitsluitsel geeft. Een test die bij elke uitvoering de tijdslimiet overschrijdt, verdient nader onderzoek.
• Herhaalpogingen maken het onderscheid tussen FLAKY en SECURE en tussen BREACHED_FLAKY en BREACHED. Als herhaalpogingen uitstaan, wordt een fout die af en toe optreedt een BREACHED.
• API-tests hebben zeven eigen oordelen, die volgens andere regels worden bepaald: zie API-tests.

Waar kan ik een oordeel over een echte fout bekijken?

De bewijspagina volgt één mislukte test en vermeldt alle bestanden die elk oordeel op je schijf achterlaat: report.md, metadata.json, raw-data.json, een schermafbeelding en, bij een echte fout, de video. De proefversie van 30 dagen gebruikt dezelfde engine voor je eigen tests.