Spårbarhet i utvecklingen

utveckla enligt V-modellen!

 

Som testare är det av stor vikt att kunna visa på den röda tråd som löper genom utvecklingen. Detta finns det flera sätt för, men vår affärsområdeschef för Test & Quality Management, Magnus Hjelmgren, har en klar favorit – att utveckla enligt V-modellen. Vad detta innebär berättar han mer om i detta blogginlägg om spårbarhet!

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.

V-modellen

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!

Anpassa dina datapreferenser

Vi använder data för att analysera trafik på vår webbplats och dela information om användningen till våra analyspartners. Du kan läsa mer och ändra dina val på vår sida om datahantering och cookies. Läs mer på vår sida om datahantering och cookies.

Funktionella cookies känner igen dig på vår webbplats och kommer ihåg dina tidigare valda inställningar. Dessa kan inkludera det språk du föredrar, platsen du befinner dig på, lyssna på ljud eller titta på en video. En blandning av cookies från första och tredje part används.

Marknadsföringscookies används för att samla in data om hur vår webbplats används, vilka sidor som besöks oftast eller om du får felmeddelanden på vissa webbsidor. Ibland behöver vi information om din ålder, kön och intresse. Vi delar ibland vissa begränsade aspekter av dessa data med tredje part i reklamsyfte, till exempel Google. Informationen kan omfatta användarens plats, sökhistorik, YouTube-historik och data från webbplatser som fungerar med Google, och den används för att tillhandahålla aggregerad och anonymiserade insikter om användarbeteende på flera enheter.

Nödvändiga cookies är absolut nödvändiga för att webbplatsen ska fungera korrekt. Denna kategori innehåller endast cookies som garanterar grundläggande funktioner och säkerhetsfunktioner på webbplatsen. Dessa cookies lagrar ingen personlig information.

Prestandacookies är cookies som används specifikt för att samla in data om hur vår webbplats används, vilka sidor som besöks oftast eller om du får felmeddelanden på vissa webbsidor. Dessa cookies övervakar endast webbplatsens prestanda när användaren interagerar med den. Ingen av denna information kan användas för att identifiera dig. Allt är aggregerat och därför anonymiserat.