💻 computer science

Autonomous AI and Agentic Testing Agents: A Multi-Agent Architecture for Self-Directed Software Quality Assurance

Dit artikel stelt een multi-agent architectuur voor die gebruikmaakt van door LLM gestuurde autonome agenten om zelfgestuurde softwarekwaliteitsborging mogelijk te maken door het automatiseren van testgeneratie, uitvoering, zelfherstel en defecttriage, terwijl er continu wordt geleerd van historische uitkomsten om de beperkingen van traditionele gescripte testen aan te pakken.

Oorspronkelijke auteurs: Urvish Gajjar

Gepubliceerd 2026-07-09

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Urvish Gajjar

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je softwaretesten voor als een enorm, hoog-risico spelletje "Simon zegt" op een voortdurend veranderende speeltuin. Traditioneel schrijft een menselijke tester een strikt script: "Klik op de blauwe knop, typ daarna 'Hallo'." Als de ontwikkelaar de knop verandert van blauw naar rood, of hem twee inch naar links verplaatst, breekt het script en stopt het hele spel totdat een mens het herstelt. Dit is traag, broos en frustrerend.

Dit artikel stelt een nieuwe manier van spelen voor: Het Autonome AI-testteam.

In plaats van één rigide script, hebben de auteurs een team van digitale "agents" (gespecialiseerde AI-medewerkers) gebouwd die kunnen denken, plannen en ter plekke kunnen aanpassen. Hier is hoe zij dit systeem uitleggen met behulp van eenvoudige concepten en analogieën:

1. Het Probleem: Het "Broze Script"

Denk aan traditioneel softwaretesten als een dansroutine die is opgenomen op een videoband. Als de danser (de software) van schoenen wisselt of het muziektempo verandert, weet de videoband niet hoe ze moet aanpassen. De band blijft gewoon de oude bewegingen afspelen, struikelt over de nieuwe schoenen en de hele uitvoering loopt mis. Dit gebeurt constant in moderne software omdat apps elke dag veranderen.

2. De Oplossing: Een Team van Gespecialiseerde Agents

De auteurs stellen voor om de enkele videoband te vervangen door een levende, intelligente productiecrew. In plaats van één persoon die alles doet, hebben ze een gelaagd team gecreëerd waarbij elk lid een specifieke taak heeft:

De Ogen (Perceptie-agents): Deze agents kijken constant naar de app. Eén houdt het visuele scherm in de gaten (zoals een mens naar een webpagina kijkt), een ander luistert naar de datastromen (API's), en een ander leest de vereisten (zoals een projectmanager die een takenlijst leest). Ze vertalen wat ze zien naar een taal die het team begrijpt.
Het Brein (Redeneringskern): Dit is de projectmanager. Het neemt de "takenlijst" en "wat het eruit ziet" van de Ogen, en bedenkt vervolgens een plan. Het vraat: "Wat proberen we te testen? Hebben we dit eerder gedaan?" Het breekt het grote doel op in kleine stappen.
De Handen (Executie-agents): Dit zijn de werkers die daadwerkelijk op knoppen klikken, tekst typen en data verzenden. Ze volgen het plan van het Brein.
De Monteurs (Zelfhelende agents): Dit is het magische deel. Als de "Handen" proberen op een knop te klikken en die ontbreekt (omdat de ontwikkelaar hem heeft verplaatst), zou een traditioneel script "FOUT!" schreeuwen en stoppen. De Zelfhelende Agent stapt in als een handige klusjesman. Hij zegt: "Wacht, ik zie een rode knop waar eerst een blauwe zat. Laat me die in plaats daarvan proberen te klikken." Als dat werkt, onthoudt hij de nieuwe locatie voor de volgende keer.
De Detective (Root-Cause Agent): Als er toch iets misgaat, onderzoekt deze agent de oorzaak. Hij kijkt naar de logs en de geschiedenis om te beslissen: "Is dit een echte bug in de app? Is het internet gewoon traag? Of is de test zelf onbetrouwbaar?" Hij scheidt de ruis van de echte problemen.

3. Hoe ze samenwerken: De "Feedbackloop"

Het artikel beschrijft een continue cyclus, zoals een slimme fabrieksproductielijn:

Invoeren: Het team leest een nieuwe vereiste (bijv. "Gebruikers moeten kunnen inloggen").
Plannen: Het Brein breekt dit af in stappen.
Handelen: De Handen proberen het uit te voeren.
Herstellen: Als een stap faalt omdat een knop is verplaatst, herstelt de Monteur dit onmiddellijk.
Leren: Als er een bug wordt gevonden, onderzoekt de Detective waarom.
Onthouden: Cruciaal is dat het hele team wat er is gebeurd opslaat in een gedeelde geheugenbank. De volgende keer dat ze met een soortgelijke situatie worden geconfronteerd, beginnen ze niet vanaf nul; ze herinneren zich wat eerder werkte.

4. De Piloottest: Wat gebeurde er in de praktijk?

De auteurs testten dit systeem op een echte website en een interne datadienst. Dit is wat ze ontdekten:

Tests schrijven: Wanneer ze 35 nieuwe vereisten kregen, schreef de AI de eerste versie van de tests voor al deze eisen. Ingenieurs hoefden alleen nog maar kleine aanpassingen te doen, wat veel tijd bespaarde.
Defecte tests repareren: Toen het ontwerp van de website veranderde, liepen 46 oude tests vast. De "Monteur" van de AI heeft 39 van hen succesvol automatisch gerepareerd door de nieuwe knoppen te vinden.
Weten wanneer te stoppen: Voor de 7 tests die te defect waren om automatisch te herstellen (zoals een volledig verdwenen menu), zei de AI verstandig: "Ik kan dit niet veilig herstellen; een mens moet hiernaar kijken." De AI raadde niet; hij vroeg om hulp.
De ruis sorteren: Het systeem identificeerde correct of een fout een echte bug was of slechts een tijdelijke storing, waarbij het meestal overeenkwam met de mening van menselijke experts.

5. De Keerzijde: Het is nog niet perfect

Het artikel is eerlijk over de beperkingen.

Het "Oracle"-probleem: De AI kan zelfverzekerd zijn, maar ook onjuist. Als de instructies vaag zijn, kan de AI een test verzinnen die er goed uitziet, maar niet daadwerkelijk test wat het bedrijf nodig heeft.
Onvoorspelbaarheid: Soms kan de AI een test telkens net iets anders schrijven, wat verwarrend kan zijn voor het bijhouden van wijzigingen.
Vertrouwen: In kritieke situaties (zoals de gezondheidszorg of de banksector) moeten mensen de beslissingen van de AI nog steeds controleren voordat ze de vrije loop krijgen.

Samenvatting

Kortom, dit artikel presenteert een verschuiving van rigide, gescript testen (een robot die alleen doet wat hem precies is gezegd) naar agentic testen (een team van AI-medewerkers die kunnen zien, denken, hun eigen fouten kunnen herstellen en leren van de geschiedenis). Het is als de upgrade van een opname van een dans naar een levende groep dansers die kunnen improviseren als het podium verandert, terwijl ze toch de hoofdvisie van de choreograaf blijven volgen.

Technische Samenvatting: Autonome AI en Agentic Testing Agents

1. Probleemstelling

Moderne softwarelevering, gekenmerkt door continuous integration en continuous delivery (CI/CD) pipelines met hoge release-snelheden, heeft de capaciteiten van conventionele testautomatisering overtroffen. Traditionele gescripte automatisering is broos; kleine wijzigingen in gebruikersinterfaces, API-schema's of navigatieflows maken vaak een groot aantal voorheen geslaagde tests ongeldig, een fenomeen dat bekend staat als test-suite fragiliteit. Hoewel technieken met ondersteuning van machine learning (bijv. visuele locator-matching) hebben geprobeerd dit te mitigeren, blijven ze grotendeels reactief: ze identificeren defecten nadat ze zijn opgetreden in plaats van proactief te redeneren over de intentie van de test. Bovendien blijft de constructie van effectieve test oracles (het bepalen of geobserveerd gedrag een defect vormt) een grote uitdaging, met name wanneer expliciete specificaties ontbreken of ambigu zijn.

2. Methodologie: Een Multi-Agent Architectuur

Het artikel stelt een gelaagde, multi-agent architectuur voor voor Autonome AI en Agentic Testing Agents. In tegenstelling tot monolithische AI-modellen, deelt dit systeem testen op in gespecialiseerde, samenwerkende agents die worden gecoördineerd door een gedeelde redeneer- en geheugenlaag. De architectuur bestaat uit zes afzonderlijke lagen:

Application Under Test (AUT): Het opaak doelwit-systeem (web, mobiel, API of microservices) dat alleen communiceert via blootgestelde interfaces.
Perceptie en Context-acquisitie Laag: Gespecialiseerde agents extraheren gestructureerde context, waaronder UI/DOM toegankelijkheidsbomen, API-logs/specificaties, ongestructureerde vereisten (user stories) en visuele regressiedata.
Redenerings- en Planningskern: Een LLM-gebaseerde kern die de testintentie interpreteert, hoogwaardige doelen deelt in uitvoerbare sub-taken, historische precedenten ophaalt uit een vector-geïndexeerd geheugen en zelfreflectie uitvoert om plannen te herzien. Het scheidt deliberatie van actie.
Multi-Agent Executie Laag: Vijf gespecialiseerde agents voeren concrete taken uit:
- Test-geval Generatie: Zet taakspecificaties om in uitvoerbare scripts (bijv. Gherkin).
- Test-executie: Stuurt de applicatie aan via adapters (bijv. Playwright, Selenium).
- Self-Healing Locator: Probeert progressieve locator-strategieën (CSS, toegankelijkheid, vision-grounded) bij falen, en werkt de kennisbank bij met gerepareerde locators.
- Defect Triage/RCA: Classificeert fouten als regressies, omgevingsproblemen of flaky tests op basis van historische signaturen.
- Regressie Prioritering: Rangschikt test-subsets op basis van code diffs.
Tool en Integratie Laag: Verbindt agents met automatisering frameworks, CI/CD orchestratie (Jenkins, GitHub Actions) en een hybride kennisbank (relationele defect-store + vector store voor semantische retrieval).
Rapportage en Continue Feedback: Aggregeert resultaten en schrijft cruciaal de uitkomsten (inclusclusief reparaties en classificaties) terug naar het vector-geheugen om de leerlus te sluiten.

Workflow: Het systeem werkt volgens een zevenfasige cyclus getriggerd door CI/CD-events: Vereisten Ingestie $\rightarrow$ Test Intentie/Planning $\rightarrow$ Test Case Generatie $\rightarrow$ Autonome Executie $\rightarrow$ Self-Healing/Retry (begrensd) $\rightarrow$ Root-Cause Analyse $\rightarrow$ Rapportage en Leren.

3. Belangrijkste Bijdragen

Het artikel levert drie primaire bijdragen:

Gelaagde Referentie Architectuur: Een voorgestelde architectuur die perceptie, redenering, multi-agent executie, tool-integratie en rapportage scheidt, wat het hergebruik van agent-pools over heterogene applicaties mogelijk maakt.
End-to-End Workflow: Een operationele workflow die een self-healing beslissingslus en een continue-learning feedbackpad integreert in bestaande CI/CD-pipelines, waarbij onderscheid wordt gemaakt tussen omgevingsfouten en echte regressies.
Implementatie en Pilot Observaties: Een prototype implementatie gebruikmakend van Python (redenering/triage) en JavaScript/TypeScript (executie) geïntegreerd met Playwright, vergezeld van kwalitatieve data uit een pilot-implementatie die de haalbaarheid aantoont.

4. Pilot Evaluatie en Resultaten

Het prototype werd gedurende een periode van vier weken ingezet tegen een webapplicatie (220 bestaande gescripte UI-tests) en een interne orderbeheer-service (60 REST-endpoints). De evaluatie was exploratief en kwalitatief.

Test Authoring: Voor 35 nieuwe user stories produceerde de generatie-agent initiële concepten die slechts minimale aanpassingen vereisten (voornamelijk het aanscherpen van assertions) in plaats van dat ze werden verworpen, wat duidt op een vermindering van de inspanning bij het schrijven van de eerste versie.
Effectiviteit van Self-Healing: Van de 46 UI-testfouten veroorzaakt door locator-drift, herstelde de self-healing agent 39 gevallen (85%) succesvol zonder menselijke interventie door terug te vallen op vision-grounded matching. De resterende 7 gevallen betroffen structurele navigatieveranderingen en werden correct gemarkeerd voor menselijke beoordeling, wat de waarde van bounded autonomy aantoont.
Root-Cause Triage: De triage-agent classificeerde 128 fouten. Engineering-review bevestigde de meerderheid van de classificaties, waarbij onenigheid zich voornamelijk concentreerde in inherent ambigue, intermitterende netwerk-timingfouten.

Tabel IV Samenvatting:

Nieuwe Stories Concepten: 35/35 (De meerderheid vereiste minimale aanpassingen).
Locator Fouten Automatisch Hersteld: 39/46 (85%).
Fouten Uitgesteld voor Menselijke Beoordeling: 7/46 (15%).
Totaal Aantal Triage Fouten: 128.

5. Betekenis en Claims

Het artikel claimt dat het agentic paradigma een verschuiving vertegenwoordigt van vaste scripts naar doelgerichte activiteiten uitgevoerd door autonome agents. De betekenis ligt in de combinatie van doelgerichte planning, begrensde autonome reparatie en closed-loop geheugen, die niet geïsoleerd aanwezig zijn in traditionele gescripte of ML-ondersteunde paradigma's.

De auteurs benadrukken dat deze aanpak de gerichte automatisering van specifieke pijnpunten mogelijk maakt — specifiek locator fragiliteit en de inspanning bij het schrijven van de eerste versie — zonder dat het systeem onbeoordeelde beslissingen hoeft te nemen over ambigue of veiligheidsrelevante uitkomsten. De architectuur is ontworpen om incrementeel naast bestaande gescripte suites te worden toegepast.

6. Openstaande Uitdagingen en Beperkingen

Het artikel erkent expliciet enkele openstaande uitdagingen:

Het Oracle Probleem: LLM's kunnen plausibele assertions genereren die niet overeenkomen met de werkelijke business intentie, vooral bij ambigue vereisten.
Niet-determinisme: Variabiliteit in LLM-outputs bemoeilijkt reproduceerbaarheid en versiebeheer.
Verklaarbaarheid en Vertrouwen: Ingenieurs moeten de rationale achter agent-beslissingen begrijpen (bijv. het classificeren van een fout als flaky) om breder vertrouwen te krijgen, vooral in gereguleerde domeinen.
Kosten en Latentie: De computationele kosten van het aanroepen van LLM's voor elke stap motiveren toekomstig werk op het gebied van selectieve aanroeping en kleinere gespecialiseerde modellen.

Het artikel concludeert bescheiden door te stellen dat de pilot de haalbaarheid illustreert in plaats van statistisch generaliseerbare prestatieclaims vast te stellen, en roept op tot toekomstige gecontroleerde vergelijkende studies en de ontwikkeling van kwantitatieve metrieken voor de kwaliteit van de oracle en de precisie van self-healing.