Testschema - en praktisk metod för testprocessen

Denna artikel publicerades ursprungligen av Konsultbolag1. Sedan 2020 har verksamheten gått ihop med inUse (part of AFRY). Vi har sedan dess kunnat erbjuda ett spännande urval av kurser inom de samspelande områdena kravhantering, test, design och effektkartläggning under inUse Academy.

I metoden ingår fyra komponenter (benämns metodsteg vidare i artikeln) som betraktar olika vyer av testscenarion. Komponenterna fyller olika syften för olika roller i projektet vid olika delar av testprocessen. Komponenterna benämns testmatris, dagplan och testschema beskrivs i detalj.

Testschemat, som är själva navet, är ”slutprodukten” i min testmetod, underlättar testprocessen för flera roller både inom testorganisationen och utanför. Testarbetet underlättas på olika sätt för olika roller och beskrivs mera detaljerat längre fram i artikeln.

Min praktiska användning av metoden har skett i huvudsak i försäkringsbranschen även den har sitt ursprung från mina erfarenheter från många års systemutvecklingsarbete inom bankvärlden. Metoden är dock branschoberoende och i princip generell även om den måste anpassas för sitt specifika ändamål. Många testledare och testare har använt metoden eller valda delar av den i sina egna projekt.

Enligt min åsikt presenteras metoden bäst genom praktiska exempel varför jag har byggt upp artikeln på ett så kallat praktikfall från försäkringsbranschen. Metoden och dess komponenter beskrivs och exemplifieras steg-för-steg genom praktikfallet.

1 Beskrivning av metoden och dess komponenter

1.1 Praktikfall och begreppsdefinitioner

1.1.1 Begreppet livscykel

De flesta testobjekt påverkas av en eller flera händelser. En del testobjekt påverkas dessutom av tiden, t ex en försäkring. T ex har testobjektet ”försäkring” sin egen livscykel, från det att den avtalas/tecknas och tiden går, påverkas den av ett antal affärshändelser. Affärshändelser kan vara en utebliven inbetalning senas och en påminnelse aviseras eller att ett försäkringsavtal vid årets slut ska förnyas och då kanske utifrån justerade eller nya regelverk. Ofta sker affärshändelser direkt i realtid men av effektivitetsskäl bearbetas flertalet händelser samtidigt nattetid i så kallade batchbearbetningar. Affärshändelser kan således vara både direkt initierade av försäkringstagaren, av tiden eller av systemhändelser.

Andra testobjekt som påverkas av affärshändelser och tid är till exempel

• Ett konto på en bank (nytt konto, insättning/uttag, ränta osv.)
• En artikel från lager till butik (inköp, lager, order osv.)
• En produkt som framställs i en fabrik

1.1.2 Begreppet Testscenario och testfall

Testobjekt som har en livscykel är komplicerade att testa utifrån ett helhetsperspektiv och testfallen görs med fördel som en del i ett testscenario enligt figurbeskrivning 1.

Figur 1

1.1.3 Förutsättningar för praktikfallet

Ett försäkringssystem med integration till många andra system ska systemtestas. Tre försäkringar och deras fyra månaders livscykel ska verifieras. Testen ska genomföras under en vecka i juni.

1.2 Metodsteg 1 – identifiera testscenarion

Metodiken att identifiera testscenarion är att jämföra med traditionell testdesign där det viktiga är att man

• ser till helheten och täcker in så mycket som möjlig för att minimera antalet scenarion
• försöker minimera antal datum då affärshändelser inträffar (återanvänd händelsedatum)
• tänker på att vissa datum kan vara obligatoriska för vissa systemhändelser t ex månads- eller årsskiften.

Denna kreativa del i processen brukar intressera verksamhetskunniga. Dra fördel av detta intresse och bjud in dem till sammankomster eller s k workshops. För att få struktur och ordning på detta krävs ett antal sammankomster med dokumentation, analys och mötesplanering av testdesignern innan och mellan mötestillfällen. Använd gärna stora pappersark för att rita och visualisera. Ofta sitter verksamhetskunskapen på flera personer. Vid vissa möten kan det vara bra att alla medverkar medan andra möten fokuserar specifika delar och kräver närvaro av färre personer.

För enkelheten skull används affärshändelser på nyskapade försäkringsobjekt istället för att visa affärshändelser som sker på en befintlig försäkring. Givetvis måste även befintliga försäkringar/testobjekt testas men detta är ett annat testområde, hur man hanterar och hittar relevant testdata, som inte denna artikel beskriver.

Praktikfallet i figur 2 visar tre exempel på testscenarion som har identifierats från förutsättningar för praktikfallet (rubrik 1.1.3)

Figur 2

1.3 Metodsteg 2 – sammanställ en testmatris

Ovanstående testscenarion och testfall sammanställs och vidareförädlas i ett Excelark enligt nedanstående exempel. Anledningen till att Excel är att föredra är att funktionaliteten för filtrering är användbar; speciellt i nästa metodsteg är den viktig.

För varje händelse är det viktigt att identifiera

• Vad som sker (kolumn händelser)
• När händelsen sker (kolumn testdatum)
• Indata/förutsättningar för att händelsen ska inträffa (kolumngrupp Indata)
  • Ange vilket läge/värde visst data behöver vara i vid genomförandet
• Vilka verifieringspunkter (grov nivå) som är intressanta efter händelsen

Testmatrisen i figur 2 visar endast ett urval av indata/förutsättningar som kan tänkas vara intressanta för testfallen. Verifieringspunkter (förväntat resultat) kan detaljeras per flera kolumner och namnsättas om man önskar. Behovet av detaljeringsnivå är lite beroende på hur mycket kunskap testarna har.

Aktiviteten genomförs av testdesignern men resultatet har flera intressenter beroende på hur testprojektet är organiserat. Testaren behöver testmatrisen för att genomföra sin test, testdesignern för att rätta till felaktig design, testledaren eller den som framställer det slutliga testschemat behöver resultatet.

1.4 Metodsteg 3 – sammanställ en dagplan

Dagplanen är nästa steg och utgår från testmatrisen men här fokuseras istället testdatum. Filtrera testmatrisen per datum, beakta varje filtrerad händelse speciellt vad gäller indata. Ställ dig frågan: hur ska jag få försäkringsdata i rätt läge, behöver någon annan affärs- eller systemhändelse vara genomförd för att läget ska vara uppnått?

Det är i detta steg som behovet av systemhändelser och batchbearbetningar identifieras och oftast är testdesignern här beroende av antingen en systemutvecklare eller en driftsansvarig person.

Dagplanen i figur 3 visar en delmängd av händelserna från testmatrisen. Dagplanen i vårt exempel har även ett visst mått av detaljplaneringsdata t ex ansvarig för testaktiviteten och när ett specifikt testdatum ska verifieras. Detta kan genomföras i nästa steg. Om planeringen sker i detta steg är testledaren delaktig i processen. Det är då viktigt att tidsestimera varje aktivitet för att bedöma vilka kalenderdagar som kommer att behöva tas i anspråk.

Figur 3

Dagplan kan hoppas över om man är en van testdesigner och man har gjort ett antal matriser – då går man direkt till nästa steg sammanställ ett testschema.

1.5 Metodsteg 4 – sammanställ ett testschema

Aktiviteten Sammanställa ett Testschema involverar oftast flera roller t ex testdesigner, testare, testdriftare, utvecklare m fl. Det är en fördel om en person är sammanhållande; t ex testledaren som ändå är den som ska följa upp och rapportera utifrån testschemat. Arbetet är extremt iterativt och tänk på att avsätta tid för detta; ju bättre förberett desto bättre genomförd test!

En enkel datamodell över testschemat kan beskrivas med objekten

• Testschema
• Testdelar
• Testpass
• Testaktiviteter

Namnen på de olika objekten kan variera; det viktigaste är att man möjliggör en hierarki från övergripande beskrivningsnivå till detaljerad nivå. Datamodellen realiseras sedan i en väldigt enkel Excel applikation; detta för att standard funktionaliteten som grafik, länkar, delning, filtrering och fliksystem i Excel kommer väl till pass. Filtrering används t ex när en testare önskar se enbart sina aktiviteter.

Det övergripande testschemat är en flik i arbetsboken och är själva ”spindeln i nätet”. Där ges en helikoptervy över vad som ska testas, planerat datum samt datum för faktiskt genomförande. Testschemat visar också en grafisk vy över testdelarna och testpassen.

Testdelarna används i vårt exempel för att visa en kalendermånad från praktikfallet.

Nästa detaljeringsnivå Testpassen beskriver vilka testaktiviteter som ska utföras.

Figur 4

Utgå från dagplanen och självklart testfallen som i bästa fall är mera detaljerade i något specifikt testverktyg. Detta är inte säkert nödvändigt; det beror på behov och ofta är det kopplat till testarens kompetens dvs. om testaren är verksamhetskunnig eller inte.

Det är valfritt i vilken ände man börjar dvs. antingen ritar man det övergripande grafiska testschemat först eller också börjar man med detaljer per testdag. Detta är ett iterativt arbete där man nämligen vandrar mellan detaljer och den övergripande helikoptervyn fram och tillbaka.

Exemplet i figur 4 visar hur det övergripande testschemat kan se ut. Färg och form är självklart valfritt men detta är välbeprövat och har använts flera gånger och förfinats under åren. Från dagplanen i figur 3 är endast de två första testdagarna detaljerade.

Vidare i exemplet visas nästa detaljeringsnivå de s.k. testpassen (figur 5 och 6). Ett testpass är en grafisk figur som är länkad till en separat flik som rymmer metadata för testpasset samt nästa detaljeringsnivå de s.k. testaktiviteterna (händelserna från testmatrisen). Detta är den lägsta detaljeringsnivån i metoden. Det är här man oftast hittar detaljer som behövs för att testa och driva fram processen till de lägen man önskar verifiera. Allt behöver inte vara testfall utan kan vara små påminnelser eller andra aktiviteter som behöver ske vid ett visst läge.

Ett testpass kan vara antingen ”manuellt” eller ”maskinellt” dvs. innehålla ett antal registreringar eller också är det en förteckning av körningar/batchar som behöver göras för att få systemhändelser och systemklocka att gå vidare i livscykeln. Beroende på typ av testpass är behovet av metadata olika. Nedan visas ett exempel på både ett manuellt testpass och sedan ett maskinellt testpass.

Manuellt testpass

Figur 5

Figur 6

2 Testschemat under testgenomförandet

Under testgenomförandet ajourhåller testare och testdriftare status och nedlagd tid på sina aktiviteter. Vid behov kommenteras aktiviteterna.

Testledaren använder informationen för att eventuellt planera om och att statusrapportera. Beroende på hur sofistikerat man löser summeringar och aggregerad information på de detaljerade testpassen/testaktiviteterna, underlättas arbetet.

Som det syns i figur 7 har testpassen som genomförts grönmarkerats samt att omplanerat datum (genomförande datum) visar 1 dags försening. Vilka datum man använder för att visa glapp och omplanering kan självklart varieras efter tycke och smak.

Figur 7

Det kan också vara bra att försöka samla så mycket information som möjligt i ett och samma dokument varför det kan vara fördelaktigt att lägga in kontaktlista och övriga stöddokument som förtydligar testarbetet.

I mitt exempel i figur 6 och 7 har jag även lagt till att koppla Testdagboken till testschemat; detta för att ha allt samlat inför testrapportering. Man hittar rätt testdagbok till rätt dag med en länk från det övergripande testschemat.

Figur 8

Sammanfattning

Min metod som jag beskrivit i denna artikel ersätter inte behovet av att använda ett administrativt testverktyg för testfallen. Min metod erbjuder inte spårbarhet mellan testscenario/testfall och avvikelser vilket möjliggörs genom ett testverktyg. Ett verktyg som kan användas för detta är t ex ReQtest, Quality Center eller Test Manager.

För organisationer som använder testverktyg kan strukturen av ett testschema användas i t ex Quality Centers TestLab även om det inte exakt erbjuder samma överblick och hierarki. En annan nackdel är att alla testaktiviteter måste vara testfall. I denna metod kan smått som stort t ex påminnelser läggas in som testaktiviteter.

I många organisationer benämner man ett testschema för testscript även om jag aldrig sett någon specifik eller liknande metodik för detta.

För att möjliggöra åtkomst till samtliga användare är det fördelaktigt att använda funktionen dela ut arbetsboken för uppdatering av flera personer. Med fördel lösenordskyddas testschemat för när det senare i processen tillkommer intressenter är det viktigt att dessa endast har visa-behörighet.

Alla våra kurser på inUse Academy finns här!