I-modellen för krav och test

Av Charlotta Carlsson 2018-12-29

Min vision är en integrerad acceptansprocess där gränsen mellan krav och test suddats ut. Att utveckling och kvalitetssäkring går hand i hand ända upp på acceptans/verksamhetsnivån.

I-modellen för krav, utveckling och test som en utveckling av den välkända V-modellen kom jag på hösten 2017 i samband med att jag förberedde ett internt seminarium på Konsultbolag1 där jag jobbade då.

Titta på V-modellen längst till vänster. På vänster sida återfinns krav och design och på höger sida motsvarande testnivåer. Vänster sida verifieras genom momenten på höger sida. V-modellen finns i otaliga varianter och du kan läsa mera om den på wikipedia: https://en.wikipedia.org/wiki/V-Model 

Vissa tycker att V-modellen är ute för att den speglar gammaldags sekvensiellt vattenfall. Jag håller inte med om att den har dessa begränsningar och jag har inte tröttnat på modellen än trots att jag kom i kontakt med den för första gången redan ca 1997. (Det var på en fantastisk testkurs med den norske gurun Hans Schaefer http://www.softwaretesting.no/.)

Jag har hittills inte sett någon annan modell som så enkelt förklarar hur specifikation, utveckling och test hänger ihop, och jag tycker att den funkar oavsett om utvecklingsmodellen är vattenfallsaktig eller agil. Poängen är att man ska börja med testbenet (höger) på varje nivå samtidigt som designbenet (vänster). Du ska alltså börja förbereda acceptanstestspecifikationen samtidigt som du påbörjar din behovsanalys. Det är genialt! Genom att tänka ut konkret hur du skulle vilja testa att systemet uppfyller behovet (utan att veta hur designen kommer att bli) så kommer den nödvändiga iterativa kommunikationen om kraven att ta fart. Jobbar du på det viset 2018 är du inte det minsta omodern utan faktiskt långt framme jämfört med många andra!

I början av min karriär var jag systemutvecklare, antagligen en ganska ovanlig sådan eftersom jag tyckte det allra roligaste var att testa. I min situation som utvecklare befann jag mig längst ner i V:ets spets där Enhetstest möter Kod. Jag whiteboxtestade alla mina egna program ner i varje kodsnutt och avhjälpte på så sätt ett antal fel, men hittade även detaljfrågeställningar/krav som ingen hade tänkt på att speca.

De av mina gamla batchprogram som skickar data in och ut från Scanias inköpssystem blev tydligen riktigt förvaltningsbara för de körs än idag. Framgångsfaktorn tror jag var att jag inte såg någon gräns mellan utveckling och test. På den punkten vad jag var kanske före min tid. Numera är det ju en självklarhet att test, ibland automatiserat på enhetsnivån, finns med i definition of done för ett item. Till ett detaljkrav finns då acceptanskriterier som genom viss syntax kan direktöversättas till testfall. Krav och test dokumenteras på så sätt tillsammans.

Ofta ser man på automatisering som ett sätt att spara tid, eller slippa göra den tråkiga delen av testarbetet manuellt. Det är också en nödvändighet att automatisera regressiontest om man ska kunna ha snabba leveranscykler. Men för mig pekar den här trenden på något mera, den visar att specifikation/utveckling och test så tydligt hänger samman. You can't have one without the other!

Låt oss nu fälla ihop benen i V:et mot varandra som en solfjäder. Vips - det blir till ett I! I-modellen är född. Nu är momenten att ta fram kravspecifikationer och testspecifikationer helt integrerade hela vägen upp till behovsanalys/acceptanstest-nivån. Detta skulle innebära att krav och test som discipliner betraktas som en och samma med ett ansvar, även överst på verksamhetssidan. Det är ett längre avstånd att fälla ihop överst i solfjädern, och även i verkligheten, men inte omöjligt.

I dagsläget hanteras ofta krav och test av olika grupperingar, där krav kanske hanteras lite mera åt ”management”-hållet medan tester kommer in på slutet då det är dags för användare att verifiera en leverans, och betraktas nog lite mer som arbete på fabriksgolvet, där komplexiteten och beroenden till kravarbetet ofta underskattas. I bästa fall finns det relevanta krav att testa emot. Men risken att hitta problem sent är stor. Och var finns ansvaret under resans gång, under det att systemleverantören utvecklar enligt kraven? Jag tror att en sammanhållen acceptansprocess och projektorganisation från behov till test är lösningen. I varje fall om systemleverantören har ett iterativt och användarnära arbetssätt som till fullo drar nytta av denna organisation hos mottagaren.

Det är även spännande att fundera på hur en integrerad och därmed slimmad dokumentation av krav+test skulle kunna se ut på acceptansnivån. Har vi krav och testfall i samma dokument? Kan vi helt enkelt låta strukturerade testidéer utgöra kravspecifikationen på verksamhetsnivån? Kan testidéer appliceras på alla sorters kravmodeller?

För er som tycker att V-modellen är gammaldags men samtidigt tror att en integrerad acceptansprocess från krav till test är lite väl utopisk. Prova tänka enligt I-modellen! Jag tror hindren är strukturella i beställande organisationer eller affärs-/upphandlings-modeller snarare än att metodmässiga. Well, vi får väl se vad som händer i branschen med roller och metoder framöver.

Här finns t.ex. spännande utveckling inom upphandlingsområdet: http://agilakontrakt.se/.

Och här en artikel jag skrev för ett par år sen för Konsultbolag1, i samband med Chris Hofstetters populära seminarium Acceptans på riktigt: http://konsultbolag1.se/bloggen/arbeta-smartare-med-acceptans-och-faa-effekt-paa-riktigt?highlight=acceptans%20p%C3%A5%20riktigt

Sammanfattning:

• I-modellen är en ihopfälld version av den klassiska V-modellen
• Gränserna mellan krav och test har suddats ut
• Specifikation, utveckling och test hänger samman i en integrerad och iterativ arbetsprocess på alla nivåer
• Ansvar och organisation för hela acceptansprocessen från behovsanalys till test hålls ihop
• Det finns spännande möjligheter till en integrerad krav- och test-dokumentation 
• Tänk i I-modellen för att uppnå acceptans på riktigt

Det vore kul att höra vad du tycker om I-modellen! Hör av dig till mig: charlotta.carlsson@srca.se