Spårbarhet är ett uttryck som används inom kravhantering för att beskriva hur ett krav, ibland kallat ”item”, förhåller sig till ett annat krav. Men spårbarheten är så mycket mer än så. Som testare är det viktigt att kunna visa på den röda tråd som löper inom utvecklingen. Det finns naturligtvis flera sätt att göra detta på, men jag tycker att ett enkelt sätt är att utveckla enligt V-modellen. Denna modell har funnits med under lång tid och är därmed egentligen inte någon nyhet. Men i dessa tider, där utvecklingen går snabbare framåt än någonsin förr, får man inte glömma de verktyg som faktiskt har visat sig fungera väl historiskt.
Det finns en mängd varianter på V-modellen, bland annat W-modellen. Men man ska inte krångla till det i onödan, så idag tittar vi på V-modellen i all sin enkelhet.
Allt börjar med att någon, oftast en kund (intern eller extern kund spelar ingen roll), vill ha någon form av funktionalitet eller mjukvara. Detta beskriver vi på hög nivå som ett verksamhetskrav, det vill säga det som verksamheten vill att systemet eller funktionen ska göra. Jag upplever att det många gånger är bättre att beskriva verksamhetskraven med hjälp av verksamhetens egna språk. På så sätt blir det enklare för kunder som inte är IT-experter att godkänna verksamhetskraven.
När verksamhetskraven är satta bryter vi ner dem till systemkrav. Systemkraven beskriver på en teknisk nivå vad systemet ska göra. Då använder vi oss av vårt interna språk, vårt ”teknikerspråk”, för att beskriva vad systemet ska göra och hur det ska se ut.
Ibland händer det att vi behöver specificera några delar av systemet i detalj, exempelvis integrationsspecifikationer. Då kan vi lägga dessa som designkrav. Här använder vi samma tankemönster, det vill säga att ett systemkrav kan bli ett eller flera designkrav – men aldrig tvärt om! Historiskt sett har designkraven även varit ett bra ställe att lägga in interaktionsdesigner och andra specifikationer på det grafiska användargränssnittet.
Nu är det dags att skriva kod! Jag förväntar mig att de som utvecklar koden skriver enhetstester som verifierar att koden gör det den ska. I V-modellen brukar vi spåra enhetstesterna till designkraven, för att säkerställa att alla interfaces funkar som de ska.
När enhetstesterna är klara är det äntligen dags att genomföra systemtester. Systemtesterna syftar bland annat till att verifiera att samtliga systemkrav är införda i koden – de är av typen ”blackbox tester”, vilket innebär att vi utgår från vad kraven säger och verifierar att mjukvaran uppfyller dessa.
När vi är säkra på att alla systemkrav finns med i mjukvaran och alla buggar är utredda och hanterade är det dags för kunden att verifiera att alla de verksamhetskrav som de i början av projektet beställde faktiskt finns med i leveransen. Det är nu det är så viktigt att kundens egna språk användes i verksamhetskraven – det gör det mycket enklare för kunden att faktiskt avgöra om mjukvaran fungerar som den ska. När kunden har genomfört acceptanstestet och verifierat att alla verksamhetskraven är uppfyllda så har vi gått i mål. Mjukvaran är nu redo att levereras.
Genom att enas om ett arbetssätt som detta redan i början av projektet vet både kund och leverantör när projektet är färdigt och vilka förväntningar som ställs på varje part. Det tydliggör också vem som ansvarar för vilken del och visar tydligt när projektet är färdigt.
Som slutnot vill jag poängtera att detta inte enbart är en vattenfallsmodell, även om det vid en första anblick kan framstå som det, utan att den med framgång kan implementeras även i agila projekt.
Vill du veta mer om vad vi kan erbjuda inom ramarna för Test & Quality Management? Tveka inte att kontakta oss!
