Rätt testdata – hur man hanterar den ”glömda” dimensionen

2012-03-21 Artikelbanken Test Läst 9115 gånger

Användningsfall och funktioner har en framskjuten plats när man specificerar vad som skall göras i ett utvecklingsprojekt. Däremot har jag som testare ofta saknat en analys av vilka data eller fysiska objekt som systemet skall hantera. Den här artikeln handlar om "den glömda dimensionen" – Datadimensionen - och hur man ser till att den inte glöms bort i testningen.

Tänk dig att du skall testa en biltvättsanläggning. Du får tydliga specifikationer som definierar alla möjliga användningsfall och alternativfallen till dessa: Hur kunden väljer tvättprogram, hur kunden väljer betalsätt, hur kunden ångrar sig och börjar om, hur systemet leder fordonet att placera sig på rätt ställe i tvätthallen, etc. Du har alltså ett utmärkt underlag för att konstruera en uppsättning testfall. När det är dags att testa hyr du en vanligt förekommande bil och kör igenom alla möjliga scenarion. Allt fungerar och du känner dig nöjd med din testinsats. Dags för driftsättning.

Men så börjar du känna en gnagande oro. Tänk om det bara fungerade för just den här bilen. Vad händer med ett fordon med längre hjulavstånd, blir den tvättad överallt? Eller riskerar en bil med brantare lutning på bakluckan att munstyckena skrapar lacken? Man måste alltså prova med fler bilar, men vilka? Du inser att för att kunna vara helt säker på att testningen täckt alla fall måste du kartlägga allt som rullar på våra vägar. Du tittar i kravspecen men får mycket liten vägledning. Hur skall du göra nu?

 

Jag har själv aldrig testat biltvättar men ändå vid många tillfällen befunnit mig i liknande situationer när jag testat system som hanterat finansiella instrument, pensionsförsäkringar, järnvägsbangårdar eller PC-datorer för att ta några exempel. Kravarbetet i projektet har varit fokuserat på användningsfall och funktioner men förbisett att göra en kartläggning av alla data eller objekt som systemet skall hantera. Detta trots att erfarenheten visar att allvarliga problem i drift ofta uppstår när nya funktioner stöter på existerande data som man inte förväntat sig, eller när ett existerande system hanterar nya typer av data.

Varje projekt är unikt men här kommer några tips i form av en steg-för-steg beskrivning hur man kan arbeta för att se till att testningen ger maximal datatäckning.

1. Identifiera behovet av testdata under testplaneringen

Lyft frågan om testdata så tidigt som möjligt och var beredd att driva den. Diskutera med kravutvecklarna om de specificerat vilka möjliga objekt systemet skall hantera. Detta är inte alltid fallet och hur som helst så kommer du troligen vara tvungen att gå en nivå djupare i analysen och fundera på vilka olika egenskaper alla testobjekt kan ha.

Undersök också om det finns existerande data från produktion som kan återanvändas, direkt eller efter konvertering.

Dokumentera lämpligen resultatet i Testplanen eller Teststrategin.

2. Gör en fördjupad kartläggning under testdesignfasen

Låt analys av möjligt testdata vara en tidig aktivitet under testdesignfasen. Arbeta brett, både teoretiskt och praktiskt. Leta i tillgänglig dokumentation. Datamodeller och arkitekturbeskrivningar kan vara bra utgångspunkter. Kalla till ett möte med arkitekter och utvecklare där ni utgående från systemets funktion försöker räkna ut vilka olika sorters testobjekt som behövs. Leta efter alla normala kombinationer av testdata som kan förekomma.

Leta också efter olika ytterlighetsfall. Försök identifiera de maximalt komplicerade fallen, dataobjekt som har ”extra allt”, respektive dataobjekt som är nästan tomma. Om man testar banktjänster för privatpersoner kan det alltså vara intressant att testa dels med några typiska bankkunder men också några extrema kunder som har alla sorters konton och utnyttjar alla möjliga banktjänster.

Testmetodikerna med ekvivalensklasser och gränsvärden, som man lär sig på grundkurserna i testning, är mycket användbart när man letar efter datafall. Försök lista ut vilka objekt som hanteras identiskt av systemet. Identifiera objekt som ligger precis kring gränserna mellan dessa identiska klasser.

Exempel: om alla optionsserier på aktier på Stockholmsbörsen behandlas lika av systemet så behöver man bara ha med en sådan optionsserie i databasen. Om värderingen beror hur aktiekursen ligger i förhållande till optionens lösenkurs så behöver man studera en option med lösenkurs ovanför, en under och en precis på aktuell aktiekurs.

När man kommit så här långt i kartläggningen vet man hur stort arbete man har framför sig för att få fram relevant data.

3. Ta fram testdata under testdesign eller testexekveringsfasen

När man har gjort en kartläggning gäller det också att skapa dataobjekten och lägga in dem i systemet. Ifall man är helt säker på vilket data man behöver kan man göra det som en engångsinsats under testdesignfasen. Man kan också låta det vara ett interaktivt arbete där framtagandet av data görs som en del av testexekveringen. Om man behöver stora mängder data kan det vara praktiskt att skriva, eller be någon utvecklare skriva, ett script för att skapa data.

Det kan också visa sig att allt intressant testdata redan finns i en existerande databas från produktion. I så fall blir arbetet snarare att leta upp intressant data än att skapa det. Antingen letar man på måfå eller gör databassökningar, t ex med hjälp av SQL.

4. Testexekveringen – kör igenom testfall på alla tillämpliga datafall

Under testexekveringen kan det vara nödvändigt att köra igenom ett antal av testfallen för alla dataobjekt man skapat. Om man t.ex. testar ett pensionssystem, så kontrollera en kunds pensionsengagemang för alla testkunder man lagt in i systemet, unga och gamla, höginkomsttagare, låginkomsttagare, kvinnor, män, utlandsanställda, statligt anställda, arbetslösa, sjukskrivna, deltidsanställda osv. Enklast representerar man detta med en matris: testfall x datafall.

Under arbetet kommer man säkert på nya fall – lägg in dem också.

 

5. Spara data för kommande behov

Under projektets avslutningsfas är det viktigt att inte glömma att spara undan det testdata man använt så att det är lätt åtkomligt i framtiden.

 

6. Avslutning

Åter till tvätthallen. Så här kanske man skulle kunna göra:

Börja med en dokumentstudie, leta t.ex. hos biltillverkare på nätet och i olika bilkataloger. Lista upp allt du hittar. Dela upp fordonen i olika klasser som förväntas ha samma egenskaper i tvätthallen, t.ex. utgående från fordonstyp, längd, bredd, vikt, form, antal hjul etc. Välj ut en bil i varje klass som representera hela klassen.

Gå till hyrfirman med din lista av typiska bilmodeller. Ordna korttidskontrakt - med självriskeliminering. När du lämnat tillbaka bilarna, förhoppningsvis renare än när du hyrde dem kan du vara ganska säker på att alla normala biltyper fungerar.

Bjud in några kollegor i projektet som med kunskap om hur systemet fungerar försöker hitta på olika mer eller mindre extrema modeller. Leta upp sådana bilar i fordonsregistret och erbjud ägarna gratis tvätt. När detta är gjort vet du också att olika extrema varianter fungerar.

När du nu har testat alla användningsfall både för vanliga typmodeller och olika extrema fordon så kan du som testare med gott mod rekommendera driftsättning.

 

7. Nästa steg

Denna artikel fungera som en tankeväckare kring utmaningar med testdata. För att fylla din verktygslåda med praktiska tekniker och tips för att bemöta utmaningarna kan vi rekommendera följande:

  • Påbyggnadskursen Agil test som hjälper dig hitta rätt upplägg, omfattning och struktur i dina testfall. Du lär dig även att identifiera, strukturera och administrera testdata.
  • Påbyggnadskursen Kravdesign - detaljera och strukturera kraven, som bland annat lär dig att ta fram begrepps-, informations- och datamodeller som sedan kan fungera som underlag när du identifierar behov av testdata.
  • Kunskapsbanken KB1online – din kunskapsbank för att bli mer tvåbent inom kravhantering och test avseende både ett helhetsperspektiv och konkreta verktyg i form av aktiviteter, roller, ansvar och mallar.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln