Skriva testfall som verksamhetstestare förstår

Varför verksamhetstestare behöver andra testfall

Ett systemtest görs av personer som har byggt systemet eller känner det väl. Ett acceptanstest görs av personer som använder det: de kan arbetet, inte konfigurationen. De vet inte vilket fält som är nytt, vilket flöde som körs i bakgrunden eller vad utvecklaren menade.

Ett UAT-testfall måste därför fungera för någon som:

• kan affärsprocessen utantill, men inte de nya skärmarna;
• har några timmar mellan annat arbete, inte en vecka;
• aldrig ska behöva gissa om ett steg gick igenom eller misslyckades;
• stannar och väntar när ett steg är otydligt, och förlorar tid.

Varje timme som läggs på tydliga testfall sparar många timmar under testdagarna: färre frågor, färre ärenden som visar sig vara missförstånd, och resultat du kan lita på vid go/no-go.

Från user stories och processer

Testfall kommer från två håll, och du behöver båda.

User stories och deras acceptanskriterier

En user story säger vad någon vill göra och varför: Som säljare vill jag konvertera ett kvalificerat lead, så att jag får ett konto, en kontakt och en affärsmöjlighet. Dess acceptanskriterier säger när den är klar. Varje acceptanskriterium är en kandidat till ett steg eller ett testfall.

Kontrollera täckningen: varje user story i omfattningen behöver minst ett testfall. En user story utan testfall är en lucka, och luckor hittas i produktion.

Affärsprocesser, från början till slut

User stories är uppdelade i små delar för utvecklarna. Verksamheten arbetar i processer som går över många user stories: lead to cash, från offert till order, ärendehantering från mejl till lösning. En user story kan gå igenom på egen hand medan processen går sönder vid överlämningen mellan två team.

Lägg därför till end-to-end-testfall som följer en process från början till slut, över rollerna: säljaren gör offerten, chefen godkänner den, ordern går till ekonomi. Det är ofta de testfall som betyder mest för verksamheten.

I UAT StudioLäs in user stories från Jira eller Azure DevOps på kortet User stories, och markera Only stories without test cases för att se luckorna. Med modulen AI test design föreslår AI testfall utifrån dina user stories eller en processbeskrivning, även på ditt företags egen modell. Inget blir ett testfall förrän du godkänner det. Utan modulen ger Prepare with your own AI en prompt att klistra in i ditt företags AI; steg märkta [CHECK] är antaganden att kontrollera.

Ett mål per testfall

Ett testfall testar ett affärsscenario, med ett mål. Titeln säger vad testaren uppnår, med verksamhetens ord:

• Konvertera ett lead med ett befintligt konto
• Godkänn en offert med en rabatt över 20%
• Dirigera ett mejl från en känd kund till rätt kö

Inte Testa lead-objektet, och inte Leads, affärsmöjligheter och offerter. När ett testfall har flera mål blockerar ett fel alla, och resultatet säger lite: vad misslyckades, och vad fungerar fortfarande?

Hur stort är ett testfall?

Som regel har ett testfall mellan tre och femton steg, och tar fem till tjugo minuter för en testare. Mycket längre, och det har troligen mer än ett mål: dela upp det. Mycket kortare, och det hör kanske ihop med ett närliggande testfall.

End-to-end-testfall är undantaget. De följer en hel process och kan vara längre. Behåll dem, men se till att varje del av processen också har ett eget kortare testfall, så att ett fel är lätt att placera.

Steg med ett förväntat resultat

Varje steg har två delar: en åtgärd (vad testaren gör) och ett förväntat resultat (vad som ska hända). Det förväntade resultatet är det som gör ett steg testbart. Utan det bestämmer testaren vad som är tillräckligt bra, och två testare bestämmer olika.

Skriv åtgärden

• En åtgärd per steg. Öppna leadet och klicka på Convert går bra; fem klick i ett steg gör det inte.
• Börja med ett verb: öppna, klicka, fyll i, välj, spara.
• Använd etiketterna som de står på skärmen, i fetstil eller inom citattecken.
• Säg vad, inte hur systemet fungerar inuti. Spara offerten, inte starta godkännandeflödet.

Skriv det förväntade resultatet

• Säg vad testaren ser: ett meddelande, ett värde i ett fält, en ny post, en status.
• Var specifik. Affärsmöjligheten är i steget Qualification, inte det fungerar.
• Ange vad som inte ska hända när det spelar roll: Inget andra konto skapas.
• För saker som systemet gör av sig självt, säg var man ska titta: Ärendet visas i kön Benelux Support inom en minut.

Testdata och roller

Testdata

Testare förlorar mer tid på att leta efter data än på någon annan del av en UAT. Skriv in data i testfallet överallt där det spelar roll: vilken kund, vilken produkt, vilken prislista, vilket belopp. Förbered dessa data i testmiljön före första testdagen.

• Använd namn som tydligt är testdata, till exempel Jansen Logistics (test).
• Ge varje testare egna poster när de ändrar data, så att två personer inte redigerar samma affärsmöjlighet.
• Lägg till värden vid gränserna: en rabatt strax under och strax över gränsen, ett tomt obligatoriskt fält.
• Använd inte riktiga personuppgifter om kunder där du kan undvika det.

Roller

I ett CRM beror vad en användare kan se och göra på hens roll: en profil och behörighetsuppsättningar i Salesforce, säkerhetsroller och en affärsenhet i Dynamics 365. En UAT visar att varje roll kan göra sitt arbete, och bara sitt arbete. Varje testfall anger därför vilken roll som testar det, och testaren loggar in med en testanvändare som har exakt den rollen.

Testa aldrig som administratör. En administratör ser och får göra allt, så de problem som en UAT ska hitta förblir dolda.

I UAT StudioVarje steg har en åtgärd, ett förväntat resultat och eventuellt testdata. Varje testare får en Test role och ett Test account, som visas överst i deras tester som Log in as …, och rollen visas bredvid deras namn på varje ärende de registrerar.

Prioritet och risk

Det finns aldrig tid nog att testa allt lika väl. Märk varje testfall så att de viktiga testas först, och blir klara även när tiden tar slut.

Lägg till risken bredvid: vad det kostar om det går fel efter go-live. Ett felaktigt pris på en faktura är hög risk; en felaktig etikett i en rapport är låg. Inom samma prioritet börjar testarna med hög risk.

Var strikt med Must. När hälften av testfallen är Must betyder etiketten ingenting: spara den för det som verksamheten inte klarar sig utan. Kom överens om prioriteterna med processägarna: de beslutar också vid go/no-go, där Must-testfall som inte har gått igenom väger tyngst.

I UAT StudioAnge Priority (Must, Should, Could) och Risk (High, Medium, Low) i redigeraren eller i en kolumn när du importerar. Värden från andra verktyg läses också in: Critical och High blir Must, Medium och Normal Should, Low Could. Testarna ser sina Must-testfall först, med hög risk först inom varje prioritet.

Ett exempel

Testfall 12: Godkänn en offert med en rabatt över 20%

Prioritet Must, risk High. User story CRM-118. Roll: säljare (steg 1 till 3) och försäljningschef (steg 4 och 5).

Lägg märke till vad som gör att det fungerar: ett mål i titeln, en åtgärd per steg, ett förväntat resultat som en testare kan kontrollera, data och roll namngivna, och ett negativt flöde i steg 3. Lägg till ett andra testfall för en rabatt under gränsen, som inte ska behöva något godkännande.

Vanliga misstag

• Inget förväntat resultat, eller fungerar som förväntat. Testaren måste gissa vad som förväntades.
• Tekniskt språk. Fältnamn från databasen, objektnamn, eller kontrollera att triggern körs. Använd orden på skärmen.
• För många mål i ett testfall. Ett fel blockerar resten, och resultatet säger dig lite.
• Bara det lyckade flödet. Lägg till ett obligatoriskt fält som lämnas tomt, ett värde över en gräns, en användare som inte ska se en post.
• Testdata saknas. Öppna en affärsmöjlighet: vilken? I vilket steg, med vilka produkter?
• Ingen roll. Testaren använder det konto hen har, ofta ett med för många behörigheter.
• Kopierat från systemtestet. Skrivet för utvecklare, med steg som verksamhetstestare inte kan följa.
• Allt är Must. Då är ingenting det, och de viktiga testerna görs inte först.
• Skrivna en gång, aldrig lästa. Skript som ingen kontrollerade före testdagarna är fulla av gamla etiketter och fel menyer.

Låt en nyckelanvändare granska dem

Be före testdagarna en nyckelanvändare från verksamheten att läsa testfallen och prova två eller tre av dem i testmiljön. Hen hittar det som skribenten inte ser: ett steg som förutsätter kunskap, en etikett som har ändrats, en process som går till på ett annat sätt i ett annat land.

Kontrollera samtidigt att varje user story i omfattningen har ett testfall, att varje roll i omfattningen testar något och att testdata finns. Spara sedan testfallen efter go-live: de är ditt regressionstest för nästa CRM-release.

I UAT StudioImportera testfall från Excel, Azure DevOps, Jira med Xray eller Zephyr Scale, eller TestRail, eller skriv dem i redigeraren. Mallbiblioteket, ett tillägg till varje betalt paket, har färdiga skript för Salesforce och Dynamics 365 att anpassa till din egen konfiguration.

Gratis att använda

För allt annat att ordna före, under och efter UAT:n, se UAT-checklistan för en CRM-go-live, också som en gratis Excel-fil.