Slik kjører du kvalitetssikringsagenter på hver kodeforespørsel med QA.tech (uten å skrive ett eneste testskript)

Hvis teamet ditt har tatt i bruk KI-verktøy for koding, kjenner du allerede den ubehagelige matematikken. Utviklingsteam som tidligere leverte en håndfull pull requests i uken, leverer nå femti, hundre, noen ganger enda flere – mye av det skrevet av kodeagenter, gjennomgått av kodegjennomgangsagenter og slått sammen i et tempo som ingen manuell QA-prosess er utviklet for. Et team vi nylig snakket med, hadde nettopp fullført sine første femti PR-er skrevet utelukkende av agenter, og stilte oss det åpenbare spørsmålet: Hva verifiserer alt dette?

Det tradisjonelle svaret – å skrive flere testskript – holder ikke når det møter denne mengden PR-er. Det tar lengre tid å skrive og vedlikeholde skript enn det tar for agenter å produsere kode, så testpakken blir hengende etter allerede fra dag én og tar aldri igjen forspranget.

Denne veiledningen går gjennom alternativet vi har bygget hos QA.tech: å koble QA-agentene våre til kodebasen din, slik at hver pull request utløser målbaserte tester som utleder seg selv fra det som er endret. Ingen testkode, ingen selektorer, ingen vedlikeholdskø. Slik setter du det opp, og dette kan du forvente på hvert trinn.

Trinn 1: La agenten lære applikasjonen din først

Før PR-integrasjonen kan gjøre noe nyttig, må agenten kjenne produktet ditt. Når du kobler QA.tech til test- eller sandkassemiljøet ditt, gjennomfører den en innledende gjennomgang: Den utforsker applikasjonen slik en grundig nyansatt ville gjort, følger alle stier og handlinger den finner, og setter dette sammen til en kunnskapsgraf over hvordan produktet ditt er strukturert.

To praktiske tips fra hundrevis av oppstartsprosesser. For det første: Hvis applikasjonen din ligger bak en innlogging, setter du opp innloggingsflyten som en forutsetningstest – agenten fullfører den først og går deretter gjennom alt som ligger bak den. For det andre: Du styrer gjennomgangsdybden. En grunn gjennomgang (ett eller to trinn inn i hver brukerreise) går raskt og er vanligvis nok til å komme i gang; du kan gjøre den mer detaljert for de viktigste flytene i stedet for å kartlegge alt uttømmende på forhånd.

Dette trinnet er selve grunnen til at PR-integrasjonen fungerer. Fordi agenten kjenner alle kriker og kroker i applikasjonen, kan den vurdere hva en bestemt endring kan påvirke – akkurat den vurderingen en god QA-ingeniør gjør når han eller hun avgjør hva som må kontrolleres før en lansering.

Trinn 2: Koble til kodebasen

GitHub-integrasjonen tar noen minutter: Autoriser appen, velg kodebasene og bestem når testene skal kjøre – vanligvis når en pull request opprettes eller oppdateres. GitLab merge requests følger samme mønster. Fra dette tidspunktet er testing en del av utviklingsløpet ditt, i stedet for et trinn som skjer etterpå.

Trinn 3: Åpne en pull request og se hva som skjer

Når en PR åpnes, leser agenten det som er lagt til og endret, kryssrefererer dette mot kunnskapsgrafen sin og genererer testtilfellene som endringen tilsier – vanligvis fire eller fem for en vanlig PR, flere for endringer som berører delte flyter. Deretter kjører den dem umiddelbart i en ekte nettleser, samhandler visuelt med den oppdaterte versjonen, akkurat slik en bruker ville gjort.

Dette er delen som overrasker team som er vant til skriptbaserte testpakker utløst av CI: Ingen skrev disse testtilfellene. De ble utledet fra selve endringen, i konteksten av alt agenten allerede vet om produktet ditt. Lanserer du et nytt filter på kontrollpanelet, tester agenten filteret og kontrollpanelflytene det inngår i. Ingen måtte huske å legge til testdekning.

Trinn 4: Les resultatene der utviklerne dine allerede arbeider

Bestått eller ikke bestått vises i selve PR-en. For hver kjøring lager agenten en vurderingsrapport: målet, forventet resultat, det som faktisk skjedde, en video av kjøringen, trinnvise skjermbilder samt konsoll- og nettverkslogger i bakgrunnen. En feil er ikke bare en rød X du må rekonstruere – det er en skriftlig forklaring på hva agenten forventet å se, og hva den så i stedet.

Fordi agenten tester gjennom grensesnittet, rapporterer den feil på produktnivå – den forteller deg at rabattkoden ikke lenger gjelder i kassen, med dokumentasjonen vedlagt. Denne konteksten på produktnivå er akkurat det utviklerne dine – eller kodeagentene dine – trenger for å finne og løse årsaken. Team som kjører agentbaserte utviklingssløyfer, sender vurderingsrapportene våre direkte tilbake til kodeagentene sine som feil kontekst for rettingen – og med MCP-integrasjonen kan disse kodeagentene utløse testkjøringer selv mens de arbeider.

Trinn 5: Legg regresjonstesting oppå PR-testingen

PR-utløste tester verifiserer endringen. Regresjonsplaner verifiserer alt annet. I QA.tech grupperer du testtilfeller i planer – en røykpakke for hver utrulling og en full regresjonstest før større lanseringer – og kjører dem med den frekvensen som passer utgivelsesprosessen din.

Fordi testene kjøres parallelt, utgjør den faktiske klokketiden en brøkdel av det samme dekningsomfanget ville kostet manuelt. En nylig full regresjonsplan vi kjørte, omfattet et testvolum som ville ha opptatt en manuell tester i én eller to dager; den ble fullført på omtrent tjue minutter. Det er denne forskjellen som gjør «kjør full regresjon ved hver utgivelse» til en faktisk policy i stedet for en ambisjon.

Trinn 6: Spør agenten hvor testdekningen din er svak

Fordi kunnskapsgrafen kartlegger alle flytene som ble oppdaget under gjennomgangen, kjenner plattformen forskjellen mellom det produktet ditt inneholder, og det testene dine dekker. Du kan spørre direkte i chatten: «Hvilke flyter med høyest verdi mangler vi dekning for akkurat nå?» Agenten svarer ut fra kartet over produktet ditt og kan generere de manglende testene med en gang.

Dette snur den vanlige dekningsdynamikken på hodet. I stedet for at dekningen er det som har samlet seg opp gjennom mange år med billettdreven testsriting, blir den et spørsmål du kan stille og handle på samme ettermiddag.

Slik ser dette ut etter en måned

Mønsteret vi ser på tvers av team, er konsekvent. Den første uken innebærer en del frem og tilbake – agenten stiller spørsmål, trenger av og til kontekst om særtrekk ved produktet ditt, og du korrigerer forståelsen dens. Innen uke to er spørsmålene sjeldne. Innen uke tre har de stort sett opphørt, fordi kunnskapsgrafen har tatt opp i seg hvordan produktet ditt fungerer. Derfra kjører testingen i samme tempo som pull-forespørslene dine, og menneskene som er involvert, gjennomgår resultater i stedet for å vedlikeholde skript. Hvis du ønsker hele utrullingssekvensen – fra konseptbevis til avvikling av de gamle testpakkene dine – har vi publisert den som en felthåndbok, Ta i bruk agentbasert testing: Blåkopien.

For team som har tatt steget over til agentgenerert kode, lukker dette løkken som manglet: kodegenerering, kodegjennomgang og verifisering kjører alle i maskinhastighet, mens utviklerne dine styrer systemet i stedet for å mate det.

Se hva QA-agenter genererer for din neste pull-forespørsel – koble et repositorium til QA.tech og kjør den første testen på få minutter.