Scenariobaserad testmetodik

Situationen är följande, kravbilden är vag och du är rådvill hur du ska agera för att få ett bra testresultat och framförallt vilket angreppsätt som du först och främst ska välja. En lösning som jag har arbetat ut genom åren är en egen typ av testmetod – scenariobaserad testning.

Scenariobaserad testning bygger på att man sätter testningen i ett sammanhang, vilket är ganska likt vad Bach och Kaner förespråkar i sin “context-driven testing”.

Skillnaden mot de vanliga testmetoderna att är att man tar på sig tänkarhatten och försöker lura ut vad en tänkbar kund skulle värdera mest (kanske ens utan att veta om det). Man sätter upp ett eller flera scenarior som beskriver ett tänkbart problem och det är upp till dig som testare att ta reda på om det går att lösa problemet med produkten som du har fått till dig levererad.

Jag ska ge ett reelt exempel:

Kravbilden var ungefär som följande i korthet. Ett företag utvecklar ett signering och valideringsprogram för kryptering av data. Kraven är att det ska gå att kryptera (signera) datat (pdf, xml) via landskoder och att kunna validera signerat data via webservice hos en tredjepartsleverantör som tillhandahåller just signering och valideringstjänster. Tanken är att en säljare signerar datat och att en köpare validerar datat så att ursprungsdatat ska vara orört via transportvägen osv. Krav såsom datamängd, last, hastighet osv saknas. Signering är ett kommande skattekrav från EU bland annat som kommer ställa krav på den här processen.

Ett scenario kan då se ut som följande:

“Företag X tillhandahåller en lösning där deras kunder kan få signerade dokument (pdf,xml). Deras köpare (5st) får båda formaten i en stokastiskt ordning och storlek (1kb-10mb), låt landskoderna även vara stokastisk mellan 5 varianter (de fem mest tänkbara) där fördelningen är 40 procent land 1, 30 land 2 och resterande land 3-5. Köparen validerar dokumentet vid leverans. 100 000 dokument går ut i en batchkörning.”

1. Sätt upp scenariot.
2. Verifiera att datat är krypterat med rätt signering (landskod).
3. Verifiera att datamängden är tillåten.
4. Mät tiden för hela batchen.
5. Verifiera att köparna som kommer från flera olika maskiner (ip-adresser) kan validera sina signerade dokument.
6. Mät minnesallockering.
7. Mät dokument per minut.
8. Mät handle-allokering och trådallokering.

Om vi nu går och ser lite hur metoden går till så fokuserar den på att man sätter upp ett scenario (problemställning) som försöker förutse en tänkbar situation när vi har levererat. Vi använder oss av stokastisk (randomiserade) funktioner när vi styr data så att vägen genom koden blir annorlunda (vilket oftast är ett sättet som vi hittar beteenden såsom minnesläckor, trådproblem och flaskhalsar). Problemställningen berättar inte exakt för oss hur vi ska lösa det, utan mer vad vi vill ha ut. Därav ligger scenariot ganska nära

acceptanstestning, fastän med vissa skillnader att vid acceptanstestning vet kunden exakt vad den vill ha, vilket är information som vi i utvecklingsfasen inte har i det här exemplet (vilket är ganska vanligt). Scenariot bygger också på att testaren här måste tänka på vad som kan tänkas viktigt med vilka icke-funktionella parametrar såsom tiden för batchen osv som är viktiga och mäta dem.

Det viktiga är när du har gjort scenariot färdigt att du diskuterar tiderna osv om de är reella med utvecklare, arkitekt, beställare och/eller projektledare. Det är inte ditt jobb att säga vad som är rätt eller fel, utan det är ditt jobb att ta fram beslutsunderlag som testare.

Jag har använt mig av den här metoden vid ett flertal tillfällen då kravbilden är vag, beställaren (intern) osäker på vad kunderna vill ha och tiden knapp. Istället för att fokusera på ren funktionalitet så sätter man funktionaliteten i ett sammanhang och specar upp det i scenario form.

Vad kräver scenariobaserad testning för att fungera:

* Erfarna testare som vågar ifrågasätta produkten på rätt sätt.
* Testare som vågar utföra tester utan fullständig kravbild.
* Människor som gillar att sätta upp problem och lösa dem.
* Tillräcklig med leverad funktionalitet för att man ska kunna sätta upp ett vettigt problem för kunden.
* Tillräcklig kunskap om marknaden. Men detta kan man få genom diskussion med projektledare och beställare om de finns tillgängliga.
* Script. Oftast måste man kunna ta fram testdata och/eller driver som utför själva testet. Fast det är inte speciellt för den här testmetodiken egentligen.

Senast jag använde mig av metoden så hade jag fått uppgiften av en projektledare som inte var säker på om produkten var testad ordentligt, testgruppen (offshored) ansåg sig vara färdig med sina tester. De hade testat i 5v och buggkurvorna visade på en stabilitet. Jag fick två veckor på mig att sätta mig in i problematiken och utföra tester. Jag hittade 27 fel varav 19 var kritiska genom att använda mig av metoden. Leveransen till marknaden blev senarelagd och hela projektet mer eller mindre räddades.

Vad hade testgruppen som testat gjort för “fel”? . De hade fokuserat på funktionalitet endast. Testat funktion 1 för sig, funktion 2 för sig osv.Det gjorde att de endast hittade fel i det scopet. Medans en kund inte bryr sig om en enstaka funktion, de köper produkten för att kunna lösa deras problem. Scenariobaserad testning går ut på att försöka simulera deras behov och problemlösning.