5 nyanser av spårbarhet (50 blev för jobbigt)

Spårbarhet som generellt begrepp ger oss möjligheter att koppla olika typer av artefakter till varandra och via dessa kopplingar besvara olika typer av frågor. Inom mjukvaruutveckling finns många exempel på spårbarhet med mer eller mindre komplexa kopplingar. Man kan till exempel tänka sig att spåra mellan krav, testfall, felrapporter, testresultat och produkter.

Dessutom kan man ytterligare komplicera denna bild genom att i sin spårbarhet även ta hänsyn till olika versioner av ovanstående.

Nedan berörs fem centrala frågeställningar när det handlar om spårbarhet mellan krav och testfall.

1. Vad ska spårbarhetsinformationen användas till?
   Innan man implementerar spårbarhet mellan krav och testfall bör man fundera på vad man egentligen ska använda spårbarheten till. Den tänkta användningen kan påverka hur spårbarheten implementeras och/eller vilket verktyg man väljer. Möjliga användningar ges av svaren på följande frågor:

• Vad är hittills täckt och vad återstår? (Planering)
• Vilka krav är EJ uppfyllda, som resultat av ”failade” testfall? (Riskanalys)
• Täcks ett krav i sin helhet? (Test Design)
• Vilka testfall påverkas av en potentiell kravändring (Underhåll)

1. Vem ansvarar för att den skapas, och inte minst underhålls?

Nästa viktiga fråga är vem eller vilka som ansvarar (äger) spårbarhets-informationen. Att skapa en mängd spårbarhetsinformation är en kostnad. Därtill kommer även en kostnad för att hålla informationen uppdaterad över tiden. Tanken är att spårbarhetsinformationen ska innebära ett mervärde som överskrider dessa kostnader. Utan någon som ansvarar för spårbarhetsinformationen och som driver arbetet med spårbarheten är risken stor att organisationen aldrig når en punkt där spårbarheten genererar något mervärde.

I detta sammanhang är det även viktigt att förstå om syftet med att erhålla spårbarhet endast en projektangelägenhet eller om finns en mottagande förvaltning. I det senare fallet är det viktigt att representanter för förvaltningen tidigt involveras i spårbarhetsarbetet.

1. Hur påverkar spårbarhetsstrategi och testfallsstrukturen varandra?

Spårbarhetsstrategi handlar bland annat om hur man väljer att täcka sina krav med testfall. Man kan tänka sig ett 1-1 förhållande, dvs. varje krav testas av (och länkas till) ett och endast ett testfall. Detta är bra ur analyssynpunkt, men i praktiken ofta svårt att uppnå, då både krav och testfall kan se väldigt olika ut. För generella krav kan man behöva flera testfall för att täcka kravet, vilket leder till en 1-N relation. Flödesbaserade testfall har ofta den omvända egenskapen, dvs. ett testfall täcker mer än ett krav, vilket leder till en N-1 relation. Slutligen kan man även tänka sig testfall som testar delar av flera krav, vilket ger N-N relationer mellan krav och testfall.

Vilken eller vilka av dessa relationer man ska tillåta/uppmuntra beror på en massa olika aspekter, men oavsett så kan det påverka den struktur man skapar för sina testfall.

Många gånger kan det även vara klokt att anpassa sin spårbarhetsstrategi över tiden. Initialt, när systemet fortfarande är instabilt används mest 1-1 eller 1-N relationer för att ett fel i ett krav inte ska förhindra godkännande av övriga krav. Senare när systemet stabiliserat sig, utökas scoopet till N-N, för att tillåta längre testfall som bättre avspeglar verkliga flöden.

1. Hur hantera bilder och modeller

Att en bild säger mer än tusen ord håller nog de flesta med om och för att förstå en komplex mekanism är det ju nästan alltid enklare att strukturera informationen i bilder, tabeller eller modeller jämfört med att ha informationen i löpande text eller uttryckt i en stor mängd korta koncisa kravtexter.

Hur gör man då när det handlar om spårbarhet mot ett sådant objekt (bild, tabell eller modell)? Under antagandet att det objekt man ska testa kräver flera testfall för att täckas, så finns det två grundläggande sätt att hantera spårbarheten beroende på ambitionsnivå.

Med den lägre ambitionsnivån ger man objektet en unik identitet (ungefär som en krav-identitet) och kopplar sina testfall mot denna identitet. Detta ger tydlig spårbarhet mot objektet men inte dess delar.

Med en högre ambitionsnivå så identifierar man delar inom objektet och ger var och en av dessa delar en egen identitet. Med tabeller är detta ofta enkelt; till exempel varje rad, varje kolumn eller varje cell. Med vissa typer av modeller kan det också vara ganska enkelt, t.ex. vägar genom ett användningsfall eller en tillståndsmaskin. Bilder däremot är svåra. Kanske kan man dela upp bilden på något sätt, men det kräver samarbete med den som ansvarar för bilden och dess innehåll.

1. Om spårbarhetsverktyget bara har en typ av länk, vad gör man då?

Så snart spårbarhetsinformationen blir lite mer omfattande så finns det bara en väg att gå och det är mot etablerade verktyg. Tyvärr har flera av de stora kommersiella verktygen en inneboende brist i sitt stöd för spårbarhet, nämligen bara en typ av länk för att koppla ihop krav med deras associerade testfall. Varför att detta ett problem? Jo, det finns minst två sätt att se på dessa länkar. Med det första perspektivet så väljer man att länka in alla krav som eventuellt skulle kunna påverka testfallet, även om kravet faktiskt inte testas av testfallet. Som exempel kan man tänka sig ett generellt krav som säger: ”alla menyval ska ha kortkommandon”.  Detta krav skulle man med denna utgångspunkt sannolikt länka till ganska många testfall. Fördelen är att om kravet ändras så får man en bra utpekning av alla testfall som behöver analyseras för att säkerställa att kravändringen slår igenom i alla berörda testfall. Nackdelen med detta perspektiv är att man riskerar att få en massa ”false-fail” dvs., krav som är markerade som ”failade” trots att dom är implementerade korrekt.

Med det andra perspektivet så väljer man att från ett testfall bara länka till de krav som verkligen testas (helt eller delvis) av testfallet. Det ger en bra utpekning av krav som inte uppfyllts, vid eventuella ”fail”, men risken är att man missar att uppdatera testfall som påverkas av en kravändring eftersom det inte finns någon länk som kopplar ihop dessa testfall.

Som med alla intressanta och svåra frågor så finns ofta inga givna svar. Sannolikt är svaren på ovanstående frågor situationsberoende men genom att fundera på dessa frågor så ökar man chansen att göra ett bra val.

Om författaren (Mats Grindal)

Mats startade sin testkarriär i början på 1990-talet i en testroll. Sedan dess har han jobbat i många små och stora testprojekt i olika roller, bl.a. som testledare, testprojektledare, testkoordinator och test configuration manager. Mats stora intresse för testning har även lett till ansvarsposter inom både SAST och SSTB. Han är även gästkrönikör på Testzonen och han har hållit ett antal föredrag på både Nationella och Internationella konferenser.