Foto av form PxHere

Z: Zooma in eller ut

- vilken nivå testar vi på egentligen?

Av Charlotta Carlsson 2020-09-28

Att förstå sig på olika testnivåer är bland det viktigaste för en testledare. Här kommer först en populärvetenskaplig snabbkurs om testnivåer på cirka tio spaltcentimeter.

Man kan tänka sig testnivåerna som en omvänd pyramid, eller ett V (googla gärna på V-modellen). Längst ner finns komponenttesterna som utvecklingsteamet gör i direkt anslutning till programmeringen, och gärna automatiseras, i varje fall om man jobbar med snabba leveranscykler. Där ovanför kommer (komponent)integrationstester, när teamet slår ihop flera utvecklade komponenter i ett "bygge" och testar att de fungerar tillsammans. Nästa nivå upp är systemtester. Då verifieras systemet som helhet mot kraven, ofta med utgångspunkt i användargränssnittet. Här kan det bli fråga om att en särskild grupp av (professionella) testare hjälper till, men systemtestare kan även sitta i utvecklingsteamen - det beror på hur utvecklingsorganisationen ser ut.

Överst i testpyramiden har vi Acceptanstesten. Där handlar det inte om verifiering (mot krav) utan om validering, dvs att säkerställa att systemlösningen fungerar på ett adekvat sätt hos användarna och löser det faktiska verksamhetsbehovet som projektet går ut på. Detta går ofta inte att i sin helhet fånga som dokumenterade systemkrav, vilket är helt naturligt. (Läs gärna vidare vid bokstaven C: Checka eller upptäcka, vad är egentligen syftet med acceptanstest?)

Ju längre ner i testpyramiden, desto mer zoomar testaren IN på detaljer. Ju längre upp zoomar testaren UT i ett helikopterperspektiv, eller vidvinkel om man så vill.

För acceptanstest är därför utgångspunkten att testerna gäller övergripande verksamhetsflöden. Andra uttryck är End-to-end (E2E), processtester, happy flow, flödestester, eller scenarios. Vi testar ekosystemet. Scenarierna kan relateras till olika effektmål eller användningsmål.

Om man använder testfall som underlag kan dessa vara relativt övergripande, såsom "1. Skapa en order, 2. Skicka iväg ordern till avdelning X. Förväntat resultat: Ordermottagare hos avdelning X får en sms-avisering". Dvs. varje knapptryckning i steg 1 och 2 behövs normalt inte. Om då inte testaren förstår hur hen ska trycka? Ja, då ger det faktiskt en information om att systemet (tillsammans med eventuella användarlathundar) inte är intuitivt att använda i den avsedda verksamhetsprocessen och det i sig är ju ett viktigt fynd. 

Med detta sagt, ibland kräver typen av verksamhet, eller om data bara är komplett hos beställaren och inte hos systemleverantören, en mer heltäckande detaljkoll även på acceptans(verksamhets)nivån. All teststrategi behöver anpassas efter situation så det finns inga definitiva inzoomningsregler. Men acceptanstest ska fortfarande inte ersätta systemtester.

Det finns ett par vanliga fallgropar:

1. Om leveransen är dåligt testad på de lägre testnivåerna så att den kommer i buggigt skick till acceptanstest finns det risk att acceptanstestarna tar på sig ett systemtestansvar (leta och rapportera rena buggar) som de inte har varken kompetens eller tid till. Som acceptanstestledare får man se upp med detta och inte låta intern eller extern systemleverantör putta över systemtestansvaret. Testare på acceptansnivån är vanliga användare som ofta är extra duktiga på sitt verksamhetsområde. Det är i den egenskapen de testar. De är inte professionella testare.

2. För lite tid mellan acceptansest och produktionssättning. Det behövs tid för såväl utvecklare som verksamhet att smälta resultaten. Leverantören måste få en chans att åtgärda sådana problem som bara hittas när man zoomar ut från detaljerna.

Slutsats för bokstaven Z:  Zooma in undantagsvis men som regel gäller vidvinkeln i acceptanstest.