Sådan kører du QA-agenter på enhver pull request med QA.tech (uden at skrive et eneste testscript)

Hvis dit team har taget AI-kodeværktøjer i brug, kender I allerede den ubehagelige matematik. Udviklingsteams, der tidligere leverede en håndfuld kodeanmodninger om ugen, leverer nu halvtreds, hundrede, nogle gange endnu flere – hvoraf meget er skrevet af kodeagenter, gennemgået af kodegennemgangsagenter og flettet ind i et tempo, som ingen manuel QA-proces er designet til. Et team, vi talte med for nylig, havde netop færdiggjort deres første halvtreds PR'er, der udelukkende var skrevet af agenter, og stillede os det oplagte spørgsmål: Hvad verificerer alt dette?

Det traditionelle svar – skriv flere testskripter – kan ikke holde til den mængde PR'er. Det tager længere tid at skrive og vedligeholde skripter, end det tager en agent at producere koden, så testsuiten sakker bagud fra dag ét og indhenter aldrig det forsømte.

Denne guide gennemgår det alternativ, vi har bygget hos QA.tech: at forbinde vores QA-agenter med dit kodearkiv, så hver kodeanmodning udløser målbaserede tests, der selv udledes af det, der er blevet ændret. Ingen testkode, ingen selektorer, ingen vedligeholdelseskø. Sådan sætter du det op, og hvad du kan forvente på hvert trin.

Trin 1: Lad først agenten lære din applikation at kende

Før PR-integrationen kan gøre noget nyttigt, skal agenten kende dit produkt. Når du forbinder QA.tech med dit staging- eller sandkassemiljø, udfører den en indledende gennemgang: Den udforsker applikationen, som en omhyggelig ny medarbejder ville gøre, følger alle de stier og handlinger, den kan finde, og samler det hele i en vidensgraf over, hvordan dit produkt er struktureret.

To praktiske bemærkninger fra hundredvis af onboardingforløb. For det første: Hvis din applikation er beskyttet af et login, skal du konfigurere loginforløbet som en forudsætningstest – agenten gennemfører det først og gennemgår derefter alt bagved. For det andet: Du styrer gennemgangens dybde. En overfladisk gennemgang (et eller to trin ned i hver brugerrejse) er hurtig og som regel tilstrækkelig til at komme i gang; du kan gøre den mere dybdegående for de vigtigste forløb i stedet for at kortlægge alt udtømmende fra starten.

Dette trin er hele årsagen til, at PR-integrationen fungerer. Fordi agenten kender alle afkroge af applikationen, kan den ræsonnere over, hvad en given ændring kan påvirke – præcis den vurdering, som en god QA-ingeniør foretager, når det skal besluttes, hvad der skal kontrolleres før en udgivelse.

Trin 2: Forbind kodearkivet

GitHub-integrationen tager få minutter: Godkend appen, vælg kodearkiver, og vælg, hvornår tests skal køre – typisk når en kodeanmodning oprettes eller opdateres. GitLabs fletteanmodninger følger samme mønster. Fra dette tidspunkt er test en del af din pipeline i stedet for et trin, der foregår efter den.

Trin 3: Åbn en kodeanmodning, og se, hvad der sker

Når en PR åbnes, læser agenten, hvad der er blevet tilføjet og ændret, sammenholder det med sin vidensgraf og genererer de testtilfælde, som ændringen kræver – typisk fire eller fem for en almindelig PR og flere for ændringer, der berører delte forløb. Derefter udfører den dem straks i en rigtig browser, hvor den interagerer med den opdaterede version præcis som en bruger ville gøre.

Det er denne del, der overrasker teams, som er vant til CI-udløste skripttests: Ingen har skrevet disse testtilfælde. De blev udledt af selve ændringen i konteksten af alt det, agenten allerede ved om dit produkt. Udgiver du et nyt filter på dit kontrolpanel, tester agenten filteret og de kontrolpanelforløb, det indgår i. Ingen behøvede at huske at tilføje dækning.

Trin 4: Læs resultaterne dér, hvor dine udviklere allerede arbejder

Bestået eller fejlet vises i selve PR'en. For hver kørsel udarbejder agenten en vurderingsrapport: målet, det forventede resultat, hvad der faktisk skete, en video af kørslen, trin-for-trin-skærmbilleder samt de underliggende konsol- og netværkslogfiler. En fejl er ikke bare et rødt X, som man skal finde årsagen til på egen hånd – det er en skriftlig forklaring på, hvad agenten forventede at se, og hvad den i stedet så.

Fordi agenten tester gennem brugerfladen, rapporterer den fejl på produktniveau – den fortæller dig, at rabatkoden ikke længere gælder ved betaling, og vedlægger dokumentationen. Denne kontekst på produktniveau er præcis det, dine udviklere – eller dine kodeagenter – har brug for for at lokalisere og løse årsagen. Teams, der arbejder med agentbaserede udviklingssløjfer, sender vores vurderingsrapporter direkte tilbage til deres kodeagenter som fejlkontekst til rettelsen – og med MCP-integrationen kan disse kodeagenter selv udløse testkørsler, mens de arbejder.

Trin 5: Læg regressionstest oven på PR-test

PR-udløste test verificerer ændringen. Regressionsplaner verificerer alt andet. I QA.tech grupperer du testcases i planer – en røgtestpakke til hver implementering, en komplet regressionstest før større udgivelser – og kører dem med den frekvens, der passer til din udgivelsesproces.

Fordi testene udføres parallelt, udgør den faktiske tidsforbrug kun en brøkdel af, hvad den samme dækning koster manuelt. En nylig komplet regressionsplan, vi kørte, dækkede en mængde test, der ville optage en manuel tester i en dag eller to; den blev gennemført på omkring tyve minutter. Det er denne forskel, der gør "kør den komplette regressionstest ved hver udgivelse" til en reel politik i stedet for en ambition.

Trin 6: Spørg agenten, hvor din dækning er mangelfuld

Fordi vidensgrafen kortlægger alle arbejdsgange, som crawlningen fandt, kender platformen forskellen på det, dit produkt indeholder, og det, dine test afprøver. Du kan spørge direkte i chatten: "Hvilke arbejdsgange med højest værdi har vi ikke dækning af lige nu?" Agenten svarer ud fra sit kort over dit produkt og kan generere de manglende test med det samme.

Det vender den sædvanlige dækningsdynamik på hovedet. I stedet for at dækningen er det, der har ophobet sig gennem årevis med billetdreven testskrivning, bliver den et spørgsmål, du kan stille og handle på samme eftermiddag.

Sådan ser det ud efter en måned

Det mønster, vi ser på tværs af teams, er ensartet. Den første uge indebærer en del frem og tilbage – agenten stiller spørgsmål, har lejlighedsvis brug for kontekst om dit produkts særheder, og du korrigerer dens forståelse. I uge to er spørgsmålene sjældne. I uge tre er de for det meste ophørt, fordi vidensgrafen har optaget, hvordan dit produkt fungerer. Derefter kører testene i samme tempo som dine pullanmodninger, og de involverede mennesker gennemgår resultater i stedet for at vedligeholde scripts. Hvis du ønsker den fulde implementeringssekvens – fra konceptafprøvning til udfasning af dine ældre testpakker – har vi udgivet den som en praktisk vejledning, Implementering af agentbaseret test: Planen.

For teams, der har taget springet til agentbaseret kode, lukker dette det hul, der manglede: kodegenerering, kodegennemgang og verifikation kører alle i maskintempo, mens dine udviklere styrer systemet i stedet for at fodre det.

Se, hvad QA-agenter genererer til din næste pullanmodning – tilslut et repository på QA.tech og kør den første test på få minutter.