Testing av kompleks B2B-SaaS: Slik håndterer agentene til QA.tech roller, tillatelser og datadrevne flyter

Enkle produkter er enkle å teste, og nesten ingen bygger enkle produkter lenger. B2B SaaS-plattformene vi jobber med hos QA.tech har en felles profil: flere brukerroller med ulike tillatelser, skjermer der hele utformingen avhenger av dataene bak dem, arbeidsflyter som går over et dusin trinn og flere avhengigheter, og i økende grad funksjonalitet som strekker seg over web, API og mobil i én og samme brukerreise.

Det er nettopp dette området der skriptbasert testautomatisering koster mest og dekker minst. Hver rolle multipliserer stiene. Hver datatilstand multipliserer dem igjen. En testpakke som faktisk dekket kombinasjonene, ville vært større enn selve produktet – så i praksis skripter teamene de forventede hovedflytene, gjør stikkprøver manuelt av resten og aksepterer gapet.

Denne artikkelen bryter ned hvordan agentene til QA.tech håndterer hver av disse kompleksitetsdimensjonene på ulike måter, basert på onboarding av team innen fintech, HR-teknologi, e-handelsinfrastruktur og helsetjenester – produktene der «bare ta opp flyten» aldri kom til å fungere.

Den riktige mentale modellen: du lærer opp en ny kollega

Rammeverket som får alt nedenfor til å henge sammen, kom faktisk fra en kunde. En QA-leder som så agenten utforske plattformen deres for første gang, spurte: «Så den fungerer som en nyansatt i selskapet?» Helt riktig. Agenten blir med i teamet ditt på samme måte som en dyktig ny QA-ansatt ville gjort – den utforsker produktet, bygger en mental modell, stiller spørsmål når den støter på noe tvetydig, og blir korrigert av og til i løpet av de første ukene. Forskjellen er hva som skjer etterpå: forståelsen den bygger, er en varig kunnskapsgraf, den glemmer aldri en korrigering, og den bruker all kontekst på hver fremtidige test.

Denne mentale modellen er viktig fordi komplekse produkter er nettopp der «nykommer»-perioden lønner seg. Et skript kjenner én vei gjennom produktet ditt. En opplært agent kjenner produktet ditt.

Roller og tillatelser: lær den opp i hele kartet, og gi den deretter hvilken som helst nøkkel

Tillatelsessystemer er der skriptbaserte testpakker i stillhet gir opp. Hvis plattformen din har rollene administrator, leder og medlem – eller femti kundespesifikke rolleoppsett – trenger en skriptbasert tilnærming separat, manuelt skrevet dekning for hver rolle, og den blir utdatert i det øyeblikket tillatelsene endres.

Den agentbaserte tilnærmingen snur dette på hodet. Først utforsker agenten produktet ditt med en administratorkonto, slik at kunnskapsgrafen dekker hele overflaten: alle skjermer, alle handlinger og alle eksisterende flyter. Deretter gir du den begrensede kontoer. Når agenten logger inn som medlem, ser den færre alternativer – og fordi den kjenner hele kartet, forstår den hva som mangler og hvorfor, i stedet for å bli forvirret av et mindre grensesnitt.

Derfra blir testing av tillatelser en samtale. Fortell agenten «som denne kategorien bruker skal du bare se X, Y og Z», så verifiserer den grensen. Og her er detaljen teamene elsker: når en begrenset bruker faktisk ikke kan nå en skjerm, registrerer agenten en bestått test – et bevis på at tillatelsessystemet gjør jobben sin. Du bekrefter forventningen én gang, agenten koder den inn, og en hel klasse sikkerhetsrelevant verifisering kjører kontinuerlig uten at noen trenger å skripte den.

Datadrevne flyter: samme mål, ulike data, ingen ny skriving

I datatunge SaaS-løsninger er det sjelden selve flyten som er den vanskelige delen – det er variasjonene. Å opprette en post er én test; å opprette den med femti ulike dataprofiler, hvorav noen skal lykkes og andre avvises, er der manuell testing drukner og skript blir til matriser med parametere som er umulige å vedlikeholde.

Fordi agenten kjører ut fra mål i stedet for registrerte trinn, krever datavariasjon bare én instruksjon: «Kjør denne testsaken på nytt med disse dataene.» Kunnskapen om flyten videreføres; bare inndataene endres. Negative tilfeller fungerer på samme måte – beskriv hva som skal avvises, så verifiserer agenten at produktet sier nei når det skal. For fritekstfeltene som alle komplekse produkter er fulle av, bruker agenten produktkonteksten du har gitt den til å skrive inn fornuftige verdier, og når den gjetter feil, korrigerer du forståelsen dens én gang i stedet for å lappe på et skript.

Lange arbeidsflyter: agenten kjenner allerede forutsetningene

Arbeidsflyter i virksomhetsrettet SaaS har avhengighetskjeder – du kan ikke redigere en avtale før det finnes en avtale, du kan ikke godkjenne en forespørsel før noen sender den inn, og du kan ikke teste det tiende trinnet uten de ni første. I skriptbaserte testpakker blir dette til oppsettskode: testdata, forhåndsdefinerte datasett og hjelpeskript som i seg selv utgjør en vedlikeholdsbyrde.

Agenten håndterer kjeder på samme måte som en person gjør: ved å huske. Når den har fullført en arbeidsflyt, bygger alt nedstrøms videre på denne kunnskapen. Be den om å teste delallokeringer i en avtale, så vet den at det først må opprettes en avtale – fordi den har gjort det, og banen ligger i kunnskapsgrafen. Forutgående arbeidsflyter som innlogging konfigureres én gang og gjenbrukes overalt. Jo mer omfattende arbeidsflytene dine er, desto viktigere blir denne opphopningen, fordi hvert trinn agenten allerede kjenner til, er et trinn ingen trenger å skrive på nytt.

Arbeidsflyter på tvers av flater: nett, API og mobil i én test

Reelle brukerreiser i moderne SaaS respekterer ikke grensene mellom testverktøy. En bruker konfigurerer noe på nettet, en webhook utløses, en post oppdateres gjennom API-et, og et varsel vises i mobilappen. De fleste team tester hver flate i et separat verktøy med separate skript og håper at overgangene fungerer.

QA.tech kjører disse som enkeltstående ende-til-ende-tester: En arbeidsflyt kan starte i nettproduktet, inkludere API-testtrinn underveis og avsluttes i den innebygde iOS- eller Android-appen, slik at brukerreisen verifiseres på samme måte som kunden faktisk opplever den. For plattformer der overgangene mellom flater er akkurat der feil skjuler seg – betalinger, varsler og synkronisering – tetter dette gapet som verktøy for enkeltflater strukturelt ikke kan.

Hva dette innebærer

Mønsteret på tvers av team som arbeider med komplekse produkter, er konsekvent. De første ukene samarbeider man – agenten utforsker, stiller spørsmål og blir korrigert, mens teamet lærer hvordan det skal instruere den. Deretter avtar spørsmålene, og testinnsatsen frikobles fra produktkompleksiteten: nye roller, nye datatilstander og nye arbeidsflyttrinn blir innlemmet i kunnskapsgrafen i stedet for å generere mer skriptarbeid.

Resultatet vises i antall timer. Pricer, et teknologiselskap innen detaljhandel, hvis plattform er akkurat denne typen komplekse, datatunge produkt, målte 390 sparte QA-timer per kvartal etter at de flyttet verifiseringen til QA-agenter – kapasitet som gikk tilbake til produktleveranser i stedet for vedlikehold av testinfrastruktur.

Og det finnes en stillere fordel som tekniske ledere trekker frem: Agentens utforskning avdekker kombinasjonene ingen tenkte på å teste. Når dekningen din kommer fra et system som har kartlagt hele produktet, i stedet for fra en oppgaveliste med testbilletter, blir «har du tenkt på dette?» noe plattformen spør deg om.

Har du et produkt som får testverktøy til å bryte sammen? La QA.techs agenter teste testmiljøet ditt – de er bygget for komplekse produkter.