Hoe je QA-agents op elke pull request uitvoert met QA.tech (zonder ook maar één testscript te schrijven)

Als je team AI-codeertools heeft ingevoerd, ken je de ongemakkelijke rekensom al. Engineeringteams die eerder een handvol pull requests per week opleverden, leveren er nu vijftig, honderd en soms meer op – grotendeels geschreven door codeeragents, beoordeeld door agents voor codebeoordeling en samengevoegd in een tempo waarvoor geen handmatig QA-proces is ontworpen. Een team met wie we onlangs spraken, had net zijn eerste vijftig PR's voltooid die volledig door agents waren geschreven en stelde ons de voor de hand liggende vraag: wat controleert dit allemaal?

Het traditionele antwoord – meer testscripts schrijven – houdt geen stand bij een dergelijk PR-volume. Scripts maken en onderhouden kost meer tijd dan agents nodig hebben om code te produceren, waardoor de testsuite vanaf dag één achterloopt en die achterstand nooit meer inhaalt.

In deze gids bespreken we het alternatief dat we bij QA.tech hebben gebouwd: je QA-agents verbinden met je repository, zodat elke pull request doelgerichte tests activeert die zichzelf afleiden uit wat er is veranderd. Geen testcode, geen selectors en geen onderhoudsachterstand. Zo stel je het in en dit kun je bij elke stap verwachten.

Stap 1: Laat de agent eerst je applicatie leren kennen

Voordat de PR-integratie iets nuttigs kan doen, moet de agent je product kennen. Wanneer je QA.tech verbindt met je staging- of sandboxomgeving, voert het een eerste crawl uit: het verkent de applicatie zoals een nauwkeurige nieuwe medewerker dat zou doen, volgt elk pad en elke actie die het kan vinden en zet dat om in een kennisgrafiek van de structuur van je product.

Twee praktische opmerkingen uit honderden onboardings. Ten eerste: als je applicatie achter een login zit, stel de loginflow in als een voorafgaande testcase – de agent voltooit die eerst en crawlt daarna alles wat erachter zit. Ten tweede: jij bepaalt de crawldiepte. Een oppervlakkige crawl (één of twee stappen diep in elke gebruikersreis) is snel en meestal voldoende om te beginnen; je kunt de diepte vergroten voor de belangrijkste flows, in plaats van alles vooraf uitputtend in kaart te brengen.

Deze stap is de volledige reden waarom de PR-integratie werkt. Omdat de agent elk hoekje van de applicatie kent, kan hij beredeneren wat een bepaalde wijziging kan beïnvloeden – precies het inzicht dat een goede QA-engineer toepast bij het bepalen wat vóór een release moet worden gecontroleerd.

Stap 2: Verbind de repository

De GitHub-integratie neemt slechts enkele minuten in beslag: autoriseer de app, selecteer de repositories en kies wanneer tests moeten worden gestart – meestal bij het aanmaken of bijwerken van een pull request. GitLab-merge requests volgen hetzelfde patroon. Vanaf dit moment maakt testen deel uit van je pipeline, in plaats van een fase te zijn die erna plaatsvindt.

Stap 3: Open een pull request en kijk wat er gebeurt

Wanneer een PR wordt geopend, leest de agent wat er is toegevoegd en gewijzigd, vergelijkt hij dat met zijn kennisgrafiek en genereert hij de testcases die bij de wijziging horen – meestal vier of vijf voor een standaard-PR, en meer voor wijzigingen die gedeelde flows raken. Vervolgens voert hij deze onmiddellijk uit in een echte browser, waarbij hij visueel interactie heeft met de bijgewerkte build, precies zoals een gebruiker dat zou doen.

Dit is het onderdeel dat teams verrast die gewend zijn aan scriptuites die door CI worden gestart: niemand heeft die testcases geschreven. Ze zijn afgeleid van de wijziging zelf, in de context van alles wat de agent al over je product weet. Voeg een nieuwe filter toe aan je dashboard en de agent test de filter én de dashboardflows waarin deze zich bevindt. Niemand hoefde eraan te denken om testdekking toe te voegen.

Stap 4: Bekijk de resultaten op de plek waar je engineers al werken

Geslaagd of mislukt: het resultaat verschijnt in de PR zelf. Voor elke run maakt de agent een beoordelingsrapport: het doel, het verwachte resultaat, wat er daadwerkelijk gebeurde, een video van de run, schermafbeeldingen per stap en de onderliggende console- en netwerklogboeken. Een fout is geen rode X die je zelf moet ontcijferen – het is een geschreven uitleg van wat de agent verwachtte te zien en wat hij in plaats daarvan zag.

Omdat de agent via de interface test, rapporteert hij fouten op productniveau – hij vertelt je dat de kortingscode niet langer wordt toegepast bij het afrekenen, met het bewijs erbij. Die context op productniveau is precies wat je engineers – of je codeeragents – nodig hebben om de oorzaak te vinden en te verhelpen. Teams die ontwikkelcycli met agents uitvoeren, sturen onze beoordelingsrapporten rechtstreeks terug naar hun codeeragents als foutcontext voor de oplossing – en met de MCP-integratie kunnen die codeeragents zelf testruns starten terwijl ze werken.

Stap 5: Voeg regressietests toe bovenop PR-tests

Tests die door een PR worden geactiveerd, verifiëren de wijziging. Regressieplannen verifiëren al het overige. In QA.tech groepeer je testgevallen in plannen – een smoke-testsuite voor elke implementatie, een volledige regressietest vóór grote releases – en voer je ze uit volgens de frequentie die bij je releaseproces past.

Omdat tests parallel worden uitgevoerd, bedraagt de verstreken tijd slechts een fractie van wat dezelfde dekking handmatig zou kosten. Een recent volledig regressieplan dat we uitvoerden, omvatte een hoeveelheid tests die een handmatige tester een of twee dagen zou bezighouden; het was in ongeveer twintig minuten voltooid. Dat verschil maakt van "voer de volledige regressietest uit bij elke release" een daadwerkelijk beleid in plaats van een streven.

Stap 6: Vraag de agent waar je dekking tekortschiet

Omdat de kennisgrafiek elke flow in kaart brengt die tijdens de crawl is ontdekt, kent het platform het verschil tussen wat je product bevat en wat je tests uitvoeren. Je kunt rechtstreeks in de chat vragen: "Op welke flows met de hoogste waarde hebben we momenteel geen dekking?" De agent antwoordt op basis van zijn kaart van je product en kan de ontbrekende tests direct genereren.

Dit draait de gebruikelijke dynamiek rond testdekking om. In plaats van dat de dekking bestaat uit alles wat zich in de loop van jaren aan ticketgestuurd schrijven van tests heeft opgestapeld, wordt het een vraag die je dezelfde middag kunt stellen en waarop je kunt handelen.

Hoe dit er na een maand uitziet

Het patroon dat we bij teams zien, is consistent. In de eerste week is er enige heen-en-weervoorcommunicatie – de agent stelt vragen, heeft af en toe context nodig over de eigenaardigheden van je product en jij corrigeert zijn begrip. In de tweede week zijn de vragen zeldzaam. In de derde week zijn ze grotendeels gestopt, omdat de kennisgrafiek heeft opgenomen hoe je product werkt. Vanaf dat moment worden tests uitgevoerd in het tempo van je pull requests en beoordelen de betrokken mensen de resultaten in plaats van scripts te onderhouden. Als je de volledige uitrolvolgorde wilt – van proof-of-concept tot het uitfaseren van je bestaande suites – hebben we die gepubliceerd als een praktische handleiding, Agentisch testen invoeren: de blauwdruk.

Voor teams die de overstap naar door agents geschreven code hebben gemaakt, sluit dit de ontbrekende schakel: codegeneratie, codebeoordeling en verificatie draaien allemaal op machinesnelheid, waarbij je engineers het systeem aansturen in plaats van het te voeden.

Bekijk wat QA-agents voor je volgende pull request genereren – verbind een repository met QA.tech en voer de eerste test binnen enkele minuten uit.