Testa komplex B2B-SaaS: Så hanterar QA.techs agenter roller, behörigheter och datadrivna flöden

Enkla produkter är lätta att testa, och nästan ingen bygger enkla produkter längre. De B2B SaaS-plattformar vi arbetar med på QA.tech har en gemensam profil: flera användarroller med olika behörigheter, skärmar vars hela utformning beror på dataunderlaget, arbetsflöden som sträcker sig över ett dussin steg och flera beroenden samt, i allt högre grad, funktionalitet som sträcker sig över webb, API och mobil i en enda användarresa.

Det här är precis det område där skriptbaserad testautomatisering kostar mest och täcker minst. Varje roll multiplicerar antalet vägar. Varje datatillstånd multiplicerar dem igen. En testsvit som på ett ärligt sätt täckte kombinationerna skulle vara större än produkten – så i praktiken skriptar teamen de vanliga lyckade vägarna, gör stickprov på resten manuellt och accepterar luckan.

Den här artikeln går igenom hur QA.techs agenter hanterar var och en av dessa komplexitetsdimensioner på olika sätt, baserat på erfarenheter från onboardingteam inom fintech, HR-teknik, e-handelsinfrastruktur och hälso- och sjukvård – produkter där ”spela bara in flödet” aldrig skulle fungera.

Den rätta mentala modellen: du introducerar en ny kollega

Den infallsvinkel som får allt nedan att falla på plats kom faktiskt från en kund. En QA-chef som såg agenten utforska deras plattform för första gången frågade: ”Så den fungerar som en nykomling på företaget?” Helt rätt. Agenten ansluter till ditt team på samma sätt som en skicklig ny QA-medarbetare skulle göra – den utforskar produkten, bygger en mental modell, ställer frågor när den stöter på något tvetydigt och blir ibland korrigerad under sina första veckor. Skillnaden är vad som händer sedan: förståelsen den bygger är en beständig kunskapsgraf, den glömmer aldrig en korrigering och tillämpar varje del av kontexten på alla framtida tester.

Den mentala modellen är viktig eftersom komplexa produkter är precis det område där ”nykomlingsperioden” ger resultat. Ett skript känner till en väg genom din produkt. En tränad agent känner till din produkt.

Roller och behörigheter: lär den hela kartan och ge den sedan vilken nyckel som helst

Behörighetssystem är där skriptbaserade testsviter i tysthet ger upp. Om din plattform har rollerna administratör, chef och medlem – eller femtio kundspecifika rollkonfigurationer – behöver ett skriptbaserat tillvägagångssätt separat, manuellt skapad täckning för varje roll, och det blir inaktuellt så fort behörigheterna ändras.

Det agentbaserade tillvägagångssättet vänder på detta. Först utforskar agenten din produkt med ett administratörskonto, så att dess kunskapsgraf täcker hela ytan: varje skärm, varje åtgärd, varje befintligt flöde. Sedan ger du den begränsade konton. När agenten loggar in som medlem ser den färre alternativ – och eftersom den känner till hela kartan förstår den vad som saknas och varför, i stället för att bli förvirrad av ett mindre gränssnitt.

Därifrån blir behörighetstestning en konversation. Säg till agenten ”som den här typen av användare ska du bara se X, Y och Z”, så verifierar den gränsen. Och här är detaljen som teamen älskar: när en begränsad användare faktiskt inte kan nå en skärm registrerar agenten ett godkänt test – ett bevis på att behörighetssystemet fungerar som det ska. Du bekräftar förväntningen en gång, agenten kodar in den och en hel klass av säkerhetsrelevanta verifieringar körs kontinuerligt utan att någon behöver skripta dem.

Datadrivna flöden: samma mål, olika data, ingen omskrivning

I dataintensiva SaaS-lösningar är flödet sällan den svåra delen – det är permutationerna. Att skapa en post är ett test; att skapa den med femtio olika dataprofiler, där vissa ska lyckas och andra avvisas, är där manuell testning drunknar och skript förvandlas till svårunderhållna parametermatriser.

Eftersom agenten kör utifrån mål i stället för inspelade steg kräver datavariation bara en instruktion: ”Kör det här testfallet igen med de här uppgifterna.” Flödeskunskapen följer med; det är bara indata som ändras. Negativa fall fungerar på samma sätt – beskriv vad som ska avvisas, så verifierar agenten att produkten säger nej när den ska. För de fritextfält som alla komplexa produkter är fulla av använder agenten den produktkontext du har gett den för att ange rimliga värden, och när den gissar fel korrigerar du förståelsen en gång i stället för att lappa ett skript.

Långa arbetsflöden: agenten känner redan till förutsättningarna

Arbetsflöden i företagsinriktade SaaS-lösningar har beroendekedjor – du kan inte redigera en affärsmöjlighet förrän en sådan finns, kan inte godkänna en begäran förrän någon har skickat in den, och kan inte testa det tionde steget utan de första nio. I skriptbaserade testsviter blir detta förberedelsekod: testfixturer, seeddata och hjälpskript som i sig innebär en underhållsbörda.

Agenten hanterar kedjor på samma sätt som en människa: genom att minnas. När den har slutfört ett flöde bygger allt som följer på den kunskapen. Be den testa underallokeringar i en affär, så vet den att det först gäller att skapa affären – eftersom den har gjort det, och vägen finns i dess kunskapsgraf. Förutsättningsflöden som inloggning konfigureras en gång och återanvänds överallt. Ju djupare era arbetsflöden är, desto större betydelse får detta ackumulerande värde, eftersom varje steg agenten redan känner till är ett steg som ingen behöver skriva om.

Resor över flera ytor: webb, API och mobil i ett test

Verkliga användarresor i moderna SaaS-produkter respekterar inte gränserna mellan testverktyg. En användare konfigurerar något på webben, en webhook utlöses, en post uppdateras via API:et och en avisering landar i mobilappen. De flesta team testar varje yta i ett separat verktyg med separata skript och hoppas att övergångarna fungerar.

QA.tech kör dessa som enskilda tester från början till slut: ett flöde kan börja i webbprodukten, innehålla API-teststeg i mitten och avslutas i den inbyggda iOS- eller Android-appen, så att resan verifieras på det sätt som kunden faktiskt upplever den. För plattformar där övergångarna mellan ytor är exakt där buggar gömmer sig – betalningar, aviseringar och synkronisering – sluter detta det gap som verktyg för enskilda ytor strukturellt inte kan överbrygga.

Vad detta sammantaget innebär

Mönstret bland team som arbetar med komplexa produkter är konsekvent. De första veckorna sker i samarbete – agenten utforskar, ställer frågor och blir korrigerad, samtidigt som ert team lär sig hur den ska instrueras. Sedan avtar frågorna, och testinsatsen kopplas loss från produktens komplexitet: nya roller, nya datatillstånd och nya arbetsflödessteg tas upp i kunskapsgrafen i stället för att generera nytt skriptarbete.

Resultatet märks i antal timmar. Pricer, ett teknikföretag inom detaljhandel, vars plattform är exakt den här typen av komplex och datatung produkt, mätte 390 sparade QA-timmar per kvartal efter att ha flyttat verifieringen till QA-agenter – kapacitet som i stället kunde läggas på att leverera nytt, snarare än på att underhålla testinfrastruktur.

Det finns också en mindre uppenbar fördel som tekniska ledare nämner: agentens utforskning synliggör kombinationer som ingen tänkte på att testa. När er täckning kommer från ett system som har kartlagt hela produkten, snarare än från en backlogg med testärenden, blir ”har ni tänkt på detta?” något som plattformen frågar er.

Har ni en produkt som får testverktyg att gå sönder? Rikta QA.techs agenter mot er stagingmiljö – komplexitet är det de är byggda för.