En introduktion till mjukvarutestning

Tänk ett tag på påståendet ovan. För mig innefattar detta den centrala meningen med mjukvarutestning. Till synes en enkel uppgift men så svår att utföra i praktiken. Testning handlar om kommunikation, information och att ställa frågor. Testning befinner sig i gränslandet mellan krav, utveckling och de verkliga behoven. Testning är den hubb där informationen från dessa tre världar möts och det ger testområdet en särställning inom systemutveckling.

…att jämföra med förväntat resultat

Testning handlar om att jämföra, men hur vet man vad man ska jämföra med och vad som är rätt beteende? Vilka informationskällor finns det att luta sig emot och hur värderar man dessa källor? Kravspecifikationen är förstås en given informationskälla och ett bra och ofta lättillgängligt sätt att ta del av förväntningarna på systemlösningen. Den ofta favoriserade kravspecifikationen är dock inte den enda informationskällan och den är sällan heltäckande. Krav kan vara felaktiga, krav kan ha ändrats, krav kan vara otydliga, krav kan ha glömts bort, krav kan ha kommit till. Som testare måste man ifrågasätta kravställningen och göra egna bedömningar utifrån all tillgänglig information. Förutom kravspecifikationen finns mycket information att hämta i den verklighet där systemlösningen används. Prata med folk, gör studiebesök eller låt användarna vara med i testerna. Var vetgirig och ställ frågor.

Ytterligare en källa till information är hur systemlösningen är utformad. Vilka tekniska val har gjorts? Vilka möjligheter och begräsningar medför de tekniska valen? Finns det områden som behöver testas extra noga? Vilka är de angränsande systement och hur ser integrationerna ut? De icke-funktionella kraven, såsom prestanda, säkerhet, användbarhet o.s.v. är områden som ofta är eftersatta i kravspecifikationen. Vad verkar rimligt, finns det luckor? Egen erfarenhet och intuition är ytterligare ett viktigt redskap. Hur borde systemlösningen fungera? Ger systemlösningen ett ostabilt intryck eller en skev känsla? Vad som utgör en bugg ligger i betraktarens öga. ”A bug is something that bugs me”, tycker jag är en bra utgångspunkt.

…för kreativa utmaningar…

Under själva testandet utgår man ofta från ett testfall, testscenario eller någon annan beskrivning för att fokusera testandet på den aktuella funktionen. I vissa fall kan det finnas skäl till att använda en väldigt detaljerad beskrivning och vid andra tillfällen kanske man helt enkelt improviserar fram tester. Ofta befinner man sig någonstans mittemellan, struktur för att testa effektivt men med möjlighet att släppa ledstången för kreativa infall. Även vid uttrycklig uppmaning att följa testprotokollet så finns det skäl att pröva infall vid sidan av. Testning är ett kreativt arbete och en detaljerad testspecifikation säger inte allt. Uppslag till nya tester kan ske under arbetets gång och buggar kan finnas i områden som ingen hittills förutsätt. Vilka erfarenheter har du själv av vad som kan gå fel? Svenska tecken, division med noll, olika webbläsare, köade transaktioner? Använd ditt eget omdöme och kunskap om systemlösningen både ur tekniskt perspektiv och i produktionssituationen. Vid en misstänkt bugg är det ofta till hjälp att zooma in runt det specifika området. Uteslut parametrar, börja testa från ett känt läge och förenkla testfallen. När man tvärtom vill undersöka förekomsten av buggar kan det hjälpa att zooma ut och köra långa komplicerade testsekvenser med utmanande uppgifter.

En annan dimension är skalan tekniknära respektive användarcentrerade tester. Vi har alla olika kunskap och fallenhet. En del är experter på verksamheten och hur systemlösningen fungerar i produktionssituationer medan andra har omfattande teknisk kunskap och nyttjar detta för riktigt utmanande tester. Båda aspekterna är nödvändiga men välj din personliga infallsvinkel utifrån var du befinner dig på skalan.

...att utsätta en systemlösning…

Det finns mängder av tester att utsätta systemlösningen för. Det kanske vanligaste är enkla funktionella tester i någon form av gränssnitt men det är synd att bara begränsa sig till detta. Populera databasen med inkonsekvent data, läs in korrupta filer, stäng ner batchkörningar vid oväntade tillfällen, ställ om systemklockor och ryck nätverkssladdar! Simulera samtidigt användande, omfattande last, intrång och systemkrascher. Testning är ett kreativt och en smula destruktivt arbete. Ifall du anar något oväntat, fortsätt att provocera systemet ytterligare.

Man behöver inte begränsa sig till testning vid enstaka faser eller leveranstillfällen, utan tester kan göras löpande under hela utvecklingsperioden. Sätt upp en egen utvecklingsmiljö för att kunna köra kodbyggena allteftersom de blir klara eller sitt tillsammans med en utvecklare för att få en inblick i hur systemlösningen växer fram. Ju tidigare som problem upptäcks, desto enklare är det i regel att åtgärda dessa. Ifall tester sker tillräckligt tidigt i samband med utveckling kan man tala om att tester hjälper till och driver utveckling, istället för att passivt mäta kvalité i efterhand. Då blir testning en integrerad del av utvecklingsarbetet och ger maximal nytta under systemlösningens hela framväxt.