Så kör du kvalitetssäkringsagenter på varje pullförfrågan med QA.tech (utan att skriva ett enda testskript)

Om ditt team har börjat använda AI-verktyg för kodning känner du redan till den obekväma matematiken. Utvecklingsteam som skickade ut en handfull pull-begäranden i veckan skickar nu ut femtio, hundra, ibland fler – mycket av det skrivet av kodningsagenter, granskat av agenter för kodgranskning och sammanfogat i en takt som ingen manuell QA-process var utformad för. Ett team vi nyligen pratade med hade precis slutfört sina första femtio pull-begäranden som skrivits helt av agenter och ställde den uppenbara frågan: vad verifierar allt detta?

Det traditionella svaret – skriv fler testskript – överlever inte kontakten med den mängden pull-begäranden. Det tar längre tid att skriva och underhålla skript än det tar för en agent att producera kod, så testsviten hamnar efter redan dag ett och kommer aldrig ikapp.

Den här guiden går igenom alternativet vi byggde på QA.tech: att ansluta våra QA-agenter till ditt kodarkiv så att varje pull-begäran utlöser målstyrda tester som själva härleds från det som har ändrats. Ingen testkod, inga selektorer, ingen underhållskö. Så här konfigurerar du det och det här kan du förvänta dig i varje steg.

Steg 1: Låt agenten lära sig din applikation först

Innan integrationen för pull-begäranden kan göra någon nytta behöver agenten känna till din produkt. När du ansluter QA.tech till din test- eller sandlådemiljö kör den en inledande genomsökning: den utforskar applikationen på samma sätt som en noggrann nyanställd skulle göra, följer varje väg och åtgärd den kan hitta och sammanställer detta till en kunskapsgraf över hur din produkt är strukturerad.

Två praktiska anmärkningar från hundratals introduktioner. För det första: om din applikation ligger bakom en inloggning ska du konfigurera inloggningsflödet som ett testfall som måste köras först – agenten slutför det först och genomsöker sedan allt bakom det. För det andra: du styr genomsökningens djup. En ytlig genomsökning (ett eller två steg in i varje användarresa) går snabbt och räcker vanligtvis för att komma igång; du kan göra den djupare för de flöden som är viktigast i stället för att kartlägga allt uttömmande från början.

Det här steget är hela anledningen till att integrationen för pull-begäranden fungerar. Eftersom agenten känner till varje skrymsle av applikationen kan den resonera kring vad en viss ändring kan påverka – vilket är exakt det omdöme en bra QA-ingenjör använder när hen avgör vad som ska kontrolleras före en lansering.

Steg 2: Anslut kodarkivet

GitHub-integrationen tar några minuter: auktorisera appen, välj kodarkiv och bestäm när testerna ska köras – vanligtvis när en pull-begäran skapas eller uppdateras. GitLabs sammanfogningsförfrågningar följer samma mönster. Från och med nu är testning en del av din pipeline i stället för ett steg som sker efter den.

Steg 3: Öppna en pull-begäran och se vad som händer

När en PR öppnas läser agenten vad som har lagts till och ändrats, jämför detta med sin kunskapsgraf och genererar de testfall som ändringen motiverar – vanligtvis fyra eller fem för en rutinmässig PR, fler för ändringar som berör gemensamma flöden. Därefter kör den dem omedelbart i en riktig webbläsare och interagerar visuellt med den uppdaterade versionen, precis som en användare skulle göra.

Det här är den del som överraskar team som är vana vid skriptbaserade testsviter som utlöses av CI: ingen skrev de testfallen. De härleddes från själva ändringen, i sammanhanget av allt agenten redan vet om din produkt. Lanserar du ett nytt filter på din instrumentpanel testar agenten filtret och instrumentpanelens flöden som det ingår i. Ingen behövde komma ihåg att lägga till testtäckning.

Steg 4: Läs resultaten där dina ingenjörer redan arbetar

Godkänt eller underkänt visas i själva pull-begäran. För varje körning tar agenten fram en bedömningsrapport: målet, det förväntade resultatet, vad som faktiskt hände, en video av körningen, skärmbilder steg för steg samt konsol- och nätverksloggarna bakom. Ett fel är inte ett rött X som måste bakåtdekrypteras – det är en skriftlig förklaring av vad agenten förväntade sig att se och vad den såg i stället.

Eftersom agenten testar via gränssnittet rapporterar den fel på produktnivå – den berättar att rabattkoden inte längre gäller i kassan, med bevismaterialet bifogat. Det sammanhanget på produktnivå är exakt vad dina ingenjörer – eller dina kodningsagenter – behöver för att hitta och åtgärda orsaken. Team som arbetar med agentbaserade utvecklingsloopar skickar våra bedömningsrapporter direkt tillbaka till sina kodningsagenter som felkontext för åtgärden – och med MCP-integrationen kan dessa kodningsagenter själva utlösa testkörningar medan de arbetar.

Steg 5: Lägg regressionstestning ovanpå PR-testningen

PR-utlösta tester verifierar ändringen. Regressionsplaner verifierar allt annat. I QA.tech grupperar du testfall i planer – en röksvit för varje driftsättning och en fullständig regression inför större lanseringar – och kör dem enligt den frekvens som passar din lanseringsprocess.

Eftersom testerna körs parallellt är kalendertiden en bråkdel av vad samma täckning kostar manuellt. En nyligen genomförd fullständig regressionsplan täckte en testvolym som skulle ha sysselsatt en manuell testare i en eller två dagar; den slutfördes på ungefär tjugo minuter. Det är den skillnaden som gör ”kör hela regressionstestningen vid varje lansering” till en faktisk policy i stället för en ambition.

Steg 6: Fråga agenten var din täckning är bristfällig

Eftersom kunskapsgrafen kartlägger varje flöde som genomsökningen upptäckte känner plattformen till skillnaden mellan det som din produkt innehåller och det som dina tester täcker. Du kan fråga direkt i chatten: ”Vilka flöden med högst värde saknar vi täckning för just nu?” Agenten svarar utifrån sin karta över din produkt och kan generera de saknade testerna direkt.

Detta vänder på den vanliga täckningsdynamiken. I stället för att täckningen består av det som har ackumulerats under år av biljettstyrt testskrivande blir den en fråga som du kan ställa och agera på under samma eftermiddag.

Så här ser det ut efter en månad

Mönstret vi ser hos olika team är konsekvent. Den första veckan innebär en del fram och tillbaka – agenten ställer frågor, behöver ibland sammanhang kring produktens särdrag och du korrigerar dess förståelse. Under den andra veckan är frågorna sällsynta. Under den tredje veckan har de för det mesta upphört, eftersom kunskapsgrafen har tagit till sig hur din produkt fungerar. Därefter körs testningen i samma takt som dina pull requests, och de involverade människorna granskar resultaten i stället för att underhålla skript. Om du vill ha hela utrullningssekvensen – från koncepttest till att avveckla dina äldre testsviter – har vi publicerat den som en praktisk guide, Att införa agentbaserad testning: ritningen.

För team som har tagit steget till agentgenererad kod sluter detta den cirkel som tidigare saknades: kodgenerering, kodgranskning och verifiering körs alla i maskintakt, medan era utvecklare styr systemet i stället för att mata det.

Se vad QA-agenter genererar för din nästa pull request – anslut ett arkiv till QA.tech och kör det första testet på några minuter.