Testning

Vad är testning?

Många tror att testning betyder att hitta defekter, eller att bevisa att det inte finns några. Men, ännu viktigare, testaktiviteter involverar att förhindra och förebygga defekter, och att informera projektgruppen och ledningen om vilken status projektet befinner sig i.

Testning betyder mer än att utföra tester. I testning ingår uppgifter som granskning av krav, planering och kontroll, att välja testvillkor och kriterium för acceptans, design av testfall och kontroll av resultat, evaluering av kriterier, rapportering om testprocessen, systemet som testas, och ge råd fall produkten är redo att överlämnas till kund.

När testar man?

På grund av vattenfallsmodellen eller V-modellen, där integration och test är de sista faserna i processen, finns det en idé om att test är något man enbart gör i projektets slutfaser. Först utförs alla viktiga faser som ger värde, och sedan kastar man resultatet över en så kallad "vägg" till testarna som helst ska bevisa att det inte finns några fel. Men testaktiviteter innebär mycket mer än att utföra tester på den klara produkten. En av de grundläggande definitionerna för test är skillnaden mellan verifiering och validering – där verifiering definieras som att kontrollera att programvaran gör det som den definierats att göra (att den uppfyller kraven) och validering innebär att den gör det kunden eller användaren egentligen vill. Utifrån denna definition är testarens viktigaste uppgift att förstå vad den slutgiltiga produkten ska utföra och förstå vad det är som efterfrågas. Krav och test är därför hårt sammankopplade och testarens arbete börjar redan där. Därför bör testpersonalen vara involverad redan när projektet dras igång – de kan hjälpa till med kravarbetet, eller rentav vara de som utför det.

Vad testar man?

Det finns flera ordspråk kring agil testning så som "Om det är värt att bygga, är det värt att testa.", "All kod är testad kod". "Om det inte är värt att testa, varför slösar du bort din tid på det?". Vid första anblick är dessa otroligt hårt ställda krav på testning. Inte ens säkerhetskritiska system och av agila världen hatade CMM (Capability Maturity Model)/ CMMI(Capability Maturity Model Integration) förespråkar att allt skall vara testat. Inom säkerhetskritiska system kräver man att allt som är säkerhetskritiskt skall testas, medan man får välja om resten skall testas. Inom CMMI förespråkas det istället att man bör ha en strategi för vilka delar som skall testas och varför, eller varför inte.

Detta brukar följas med olika typer av riskbaserade testplaneringar. Delar som är viktiga och vars funktionalitet har stor påverkan, är de delar som bör testas mest och noggrannast. Delar som är oviktiga, eller vars funktionalitet har minimal påverkan, behöver kanske inte testas alls. Och här dyker förklaringen upp till ordspråken i den agila världen – i varje iteration bygger man bara det som är viktigast. Om det inte är viktigt, så hinner man kanske aldrig bygga det. Och därför blir bara de viktiga delarna gjorda och därav testade.

Testning i traditionella projekt

I den traditionella världen börjar man (eller i alla fall bör man börja) med design av testfall tidigt i projektet. Granskning av krav och designdokumentationen utförs då också för att förhindra att defekter uppstår. Man förbereder även alla miljöerna, för att enkelt kunna sätta igång. Själva testningen startar senare i projektet, när koden är levererad. Testningen av koden följer komponent-integration-system processen där systemet/produkten sätts ihop från sina beståndsdelar.

Att följa V-modellen skapar flera problemmoment för test. Testfasen blir ofta komprimerad, då det inte är ovanligt att utvecklingsaktiviteterna drar över tid, medan projektets sluttadum är detsamma. Pressade utvecklingsscheman leder till att koden som överlämnas till testarna är dåligt dokumenterad och debuggad. Dessutom är det inte ovanligt att testarna inte är involverade i tidiga faser av projektet, vilket resulterar i att de inte kan utföra det preventiva arbetet, eller ens ordentligt planera själva testandet.

Testning i agila projekt

I de agila projekten är testning integrerad med utveckling – alla faser utförs i samma iteration och inte ovanligt av samma personer. Detta medför helt andra problem än de traditionella. Regressionstester tar den centrala rollen, eftersom varje utökning (kallad inkrement) hotar att förstöra den redan existerade och testade funktionaliteten. Den pressade och förkortade utvecklingstiden per iteration pressar även mer testningen i slutfasen av iterationen än V-modellen gjorde. Och sist, men inte minst, "skeppa fast" mentaliteten kan bli otroligt icke stödjande till själva disciplinen och infrastrukturen som krävs av ordentligt utfört test.

För att klara av dessa utmaningar, har man i de agila metoderna för närvarande 4 populära strömmar. Dessa är testdriven utveckling, automatiserade tester, utforskande testning och testkvadranter.

Testdriven utveckling är en avancerad metod där man använder sig av test för att driva mjukvarudesignen. Detta görs genom att testfallen skrivs innan designen och koden. Den största fördelen med denna metod är effektiviseringen av arbetet - kravgranskning och analys utförs samtidigt som man skriver testfallen, man kan använda testfallen som krav, och detta fungerar väldigt bra tillsammans med "Definition of Done" (kriterium för acceptans) delen av User Stories. Man tvingar fram fundering kring vad som kan gå fel och vilka de alternativa vägarna är genom systemet. Samtidigt löser det problemet med att utvecklare blir förblindade av sina egna lösningar, då lösningarna inte är färdiga när de skriver testfallen.

Automatiserade tester är, som det låter, testfall som körs av separat mjukvara som kontrollerar exekveringen och jämför resultaten med förutbestämda utfall. Detta kan användas för nödvändiga, men tjatiga uppgifter eller för att addera mer testning som annars skulle vara svår att utföra manuellt, eller helt enkelt för att köra regressionstester. Allt mer av testning flyttas över till automatiserade tester, och det efterfrågas allt fler testare som antingen vet hur man använder dessa verktyg, eller vet hur man programmerar. Automatiserade tester tillsammans med kontinuerlig integrering anses vara det mest effektiva sättet att testa.

Utforskande (exploratory) testning är en effektiv metod som är svår att acceptera för dem som gillar traditionella testspecar. Utforskande tester innebär att man försöker förstå hur programvaran fungerar samtidigt som man testar och loggar resultaten. Varje testsession utförs under en begränsad tid (kallad tidsbox), med ett eller flera specifika mål. Både målen och resultaten rapporteras. Ofta skriver man ner eller filmar testfallen som utförts, för att skapa en testspec och/eller regressionstester. Idag finns det många verktyg på marknaden som underlättar detta arbete, både för rapportering, inspelning, och automatisering av manuella tester.

Testkvadranter är en metod som organiserar testning på annat sätt än traditionella nivåer (komponent, integrering, system och UAT). Den största anledningen är att för varje funktionalitet som adderas, utför man alla nivåer under en och samma korta iteration. Kvadrantnumreringen har ingen betydelse för prioritering eller ordning av testfall. Dessa används endast som förkortning; som Q1 istället för att säga "tekniska tester som stödjer teamet". De flesta team tenderar att börja med Q2, därför att det är där som de flesta exemplen dyker upp, som sedan blir specifikationer och tester som driver kod. Kvadranterna är en bra metod som hjälper teamen att planera sina test och se till att de har alla resurser att utföra dessa.

Trender

Förutom de agila trenderna, så finns det även andra strömmar inom test. Det mest uppbenbara är att test som disciplin har fått ett uppsving i betydelse och intresse. Från att vara något som man bara satte "misslyckade utvecklare" på att utföra, håller det nu på att bli ett riktigt yrke med egen status och karriärmöjligheter. Högskolor som förut bara nämnde till sina studenter att inlämningsuppgifterna bör vara testade, utan att lära ut vad detta innebär, har nu inte bara kurser i testning, utan även forskningsprojekt. Företag letar efter testare med ljus och lykta, samtidigt som det dyker upp specifika testföretag och molntjänster. Detta har även lett till framtagning av en ny teststandard, ISO/IEC/IEEE 29119, som är mycket kontroversiell och omdiskuterat inom testvärlden. Hur och varför den är så kontroversiell, samt argument för och emot är dock ingenting som går att ta upp i bara några meningar, utan skulle kräva sin alldeles egna artikel.

Magdalena Bozyk, konsult Addiva AB