De fleste team mislykkes ikke med agentbasert testing fordi teknologien ikke strekker til. De mislykkes fordi de ruller det ut som et verktøy, selv om det oppfører seg som en ny medarbeider. Du ville ikke vurdert en ny QA-ingeniør den første morgenen, gitt vedkommende null kontekst om produktet ditt og stille gått tilbake til den gamle prosessen når personen stilte et spørsmål. Likevel er det omtrent slik mange evalueringer av autonom testing gjennomføres – og deretter skrinlegges.
Vi utvikler QA.tech, en agentbasert QA-plattform der autonome QA-agenter tester nett, pull-forespørsler og mobil ut fra mål formulert i naturlig språk, og vi har nå fulgt hundrevis av team gjennom denne utrullingen. Vi har også skrevet mye om dette: feltguiden vår Forbi flaskehalsen dekker hvordan du diagnostiserer hvor QA faktisk bremser organisasjonen din, og Å ta i bruk agentbasert testing: Oppskriften går gjennom hele utrullingen fra konseptbevis til produksjon. Denne artikkelen er kortversjonen av begge: rekkefølgen som fungerer, disiplinen som skiller vellykkede innføringer fra prosesser som stopper opp, og feilene vi ser oftest.
Fase 0: Mål flaskehalsen før du kjøper noe
Det første steget skjer før du tar i bruk produktet. Før du ruller ut QA.tech, bør du skaffe ærlige tall på hvor verifisering faktisk koster deg tid i dag. Tre målinger er viktigst.
For det første: vedlikeholdsbelastning – hvor mange ingeniørtimer per sprint går med til å reparere eksisterende tester i stedet for å skrive nye eller levere funksjoner? For det andre: etterslep i testdekningen – når en funksjon flettes inn, hvor lang tid går det før den har meningsfull testdekning – timer, dager eller «når noen får tatt tak i saken»? For det tredje: friksjon i utgivelsene – hvor ofte venter en utgivelse på QA, og hvor ofte blir QA presset sammen for å rekke en dato?
Disse tallene gjør to ting. De forteller deg om agentbasert testing i det hele tatt er verdt å ta i bruk – et team med lav vedlikeholdsbelastning og en behagelig utgivelsestakt har svakere grunner til å endre seg. Og de blir utgangspunktet ditt, fordi du om nitti dager vil kunne vise endringen med de samme måleenhetene. Innføringsprosesser uten et utgangspunkt ender i magefølelse, og magefølelse overlever ikke en budsjettgjennomgang.
Like viktig er det å bestemme hva du skal slutte med. Hver time du bruker på å lappe sammen et skjørt skript under utrullingen, er en time som subsidierer prosessen du erstatter. Velg hvilke testsett du skal fase ut, og når.
Fase 1: Avgrens et konseptbevis som faktisk kan bevise noe
Et godt konseptbevis med QA.tech er lite, spisset og ærlig. Tre avgrensningsvalg avgjør det meste av resultatet.
Velg de smertefulle flytene. Fristelsen er å starte med den ryddigste standardflyten. Ikke gjør det. Ta med minst én flyt som faktisk er smertefull i dag – den med mange tillatelser, den som er avhengig av data, eller den teamet stille gruer seg til å regresjonsteste. Hvis plattformen håndterer den vanskeligste saken din, er de enkle sakene en formalitet. Hvis den ikke gjør det, vil du vite det i uke én i stedet for måned tre.
Involver hele teamet. Én entusiastisk ingeniør som kjører konseptbeviset, gir et skjevt bilde. Ulike personer gir QA-agenter ulike beskrivelser – QA-lederen, en produktansvarlig og en backend-ingeniør vil alle formulere mål på sin egen måte, og du må vite at plattformen fungerer med teamets daglige språk, fordi en enkelt ildsjel med innøvde instruksjoner beviser svært lite.
Skriv suksesskriteriene før du starter. Pålitelighet på de kritiske flytene, en andel falske positive du kan leve med, en fungerende integrasjon med pull-forespørsler og dokumentert brukervennlighet på tvers av teamet er et solid kjernesett. Bli enige om dem med teamet vårt ved oppstart, og hold begge sider ansvarlige for dem.
Want to learn more about QA.tech?
Fase 2: Bygg ti solide tester før du skalerer til hundre
Dette er den mest forutsigende disiplinen vi har observert på tvers av utrullinger, og den teamene oftest hopper over. Når en plattform kan generere tester på få minutter, er instinktet å generere alt i uke én. Ikke gjør det. Omfang før forståelse skaper en bunke overfladiske tester, en resultatside full av støy og et team som mister tilliten til resultatene.
Bygg i stedet omtrent ti tester som betyr noe, og gjør dem virkelig solide. Kjør dem gjentatte ganger. Når agenten misforstår noe – og det vil den gjøre i begynnelsen – bør du forklare hvorfor den tok feil i stedet for å stille og rolig rette resultatet; korrigeringen videreføres til alt den gjør etterpå. Ti gjennomgående pålitelige tester lærer plattformen produktet ditt og lærer teamet ditt å bruke plattformen. Med dette grunnlaget er det raskt å skalere til hundre tester, og de hundre arver kvaliteten fra de ti.
Utviklingen du bør følge med på i disse ukene, er kurven for spørsmål. En sunn innføring ser ut som en ny kollega som finner seg til rette: hyppige spørsmål i uke én, enkelte i uke to og sjeldne innen uke tre, fordi plattformens kunnskap om produktet ditt bygger seg opp. Hvis spørsmålene ikke blir færre, bør du ta det opp med teamet vårt i stedet for å presse videre – det skyldes vanligvis manglende produktkontekst, som er raskt å tilføre.
Fase 3: Koble det inn i pipelinen og gi slipp på den gamle prosessen
Når grunnlagstestene er pålitelige, blir innføringen en integrasjonsøvelse. Koble til repositoriet slik at QA.tech fanger opp hver pull request. Sett sammen regresjons- og røyktestene i testplaner som kjører etter en tidsplan som samsvarer med utgivelsestakten deres. Send resultatene dit teamet allerede jobber – til selve PR-en, Slack eller sakssystemet deres.
Deretter kommer delen som krever reelt lederskap: å avvikle den parallelle prosessen. Team som lar den gamle skriptbaserte testpakken kjøre «for sikkerhets skyld» på ubestemt tid, betaler for to systemer og stoler ikke på noen av dem. Sett en dato, basert på avviklingskriteriene deres, når det agentbaserte laget blir systemet som gjelder for flytene det dekker – og hold fast ved den. Hele 90-dagersforløpet, inkludert hvordan dere skal sekvensere hvilke testpakker som overleveres når, dekkes grundig i Blåkopien.
Fase 4: Omdefiner QA-rollen bevisst
Agentbasert testing endrer hva QA-arbeid innebærer, og å late som noe annet skaper stille motstand som undergraver utrullinger innenfra. Ta tak i det direkte.
Det som forsvinner, er utvikling og vedlikehold av skript – arbeidet de fleste QA-fagfolk vil fortelle deg at de liker minst. Det som erstatter det, er retning: å avgjøre hva som fortjener dekning, gi agentene produktkontekst som ingen andre har, gjennomgå vurderingsrapporter og presse testingen inn på områder som aldri tidligere ble dekket fordi det aldri var tid. QA-lederen som brukte torsdager på å reparere selektorer, blir personen som spør plattformen «hvilke verdifulle flyter mangler dekning akkurat nå?» – og handler på svaret samme dag.
Gjør denne endringen tydelig i den første uken av innføringen, før uroen får tid til å vokse. Teamene der QA-medarbeiderne blir plattformens superbrukere, er teamene der innføringen varer.
Feilene som kort sagt bremser utrullinger
Å hoppe over utgangspunktet, slik at ingen kan bevise forbedringen. Å starte med hundre genererte tester i stedet for ti solide. Å kjøre POC-en gjennom én enkelt forkjemper. Å behandle spørsmål fra den første uken som feil, i stedet for som opplæring. Å holde den gamle testpakken i live på ubestemt tid. Og å la endringen i QA-teamets rolle forbli usagt. All innføring som har stoppet opp, kan spores tilbake til minst én av disse – og alle seks kan unngås med sekvensen ovenfor.
Vanlige spørsmål
Hvor lang tid tar det å innføre agentbasert testing?
Med et AI-testverktøy som QA.tech tar de første fungerende testene minutter, fordi det ikke finnes noe rammeverk som må settes opp; et pålitelig grunnlag tar to til fire uker, og en full utrulling til produksjon – PR-integrasjon, regresjonsplaner og avvikling av gamle testpakker – er vanligvis på plass innen nitti dager.
Bør vi kjøre agentbasert testing sammen med den eksisterende testpakken vår?
Ja, under overgangen – med en tydelig sluttdato. Å kjøre begge systemene på ubestemt tid dobler kostnadene og splitter tilliten; fastsett kriterier for overlevering per testpakke, og avvikle den gamle prosessen bevisst.
Hvem bør eie utrullingen av agentbasert testing?
En teknologileder er sponsor, men det daglige eierskapet fungerer best hos QA – de har produktkonteksten agentene trenger, og utrullingen lykkes når de blir plattformens superbrukere.
Hva bør vi måle for å bevise at innføringen fungerte?
Det samme utgangspunktet som dere målte før dere startet: vedlikeholdstimer per sprint, tid fra sammenslåing til dekning og utgivelser som ble forsinket av QA. Sammenlign på dag nitti.
Klar til å gjennomføre utrullingen? Start med analysen i Forbi flaskehalsen, eller ta kontakt med teamet vårt for å se hvordan ledende utviklingsteam leverer raskere med QA-agenter som validerer hver utgivelse.
