Det är trendigt att baka, både söta kakor och surdeg. Det är också trendigt med test. Lättuggat och lättsmält eller mer tuggmotstånd? Vilken metod är bäst? Att testa surdegarna först och sedan gå på knäckebrödet för att avsluta med småkakorna? Eller att spara surdegen till sist, den kanske inte är lika jobbig då, eller den kanske till och med har försvunnit på vägen. Olika metoder och teorier ger olika besked om vad som är bäst.

Hitta felen tidigt

Målet med tester är att hitta så många fel som möjligt och gärna tidigt i arbetet för att hinna rätta felen innan produktionssättning. Sedan finns det naturligtvis tester som inte kan genomföras i början, t.ex. regressionstester. Oavsett vilket så vill jag här, med hjälp av några exempel från verkligheten, visa på olika synsätt för i vilken ordning kraven ska testas av.

Överväg nyttan när du planerar testerna

Jag har varit med om projekt där man varit fast övertygad om att (enligt RUP-teori) ta surdegarna först. Det vill säga de jobbigaste och mest komplexa områdena ska testas först för att sedan gå över till de mer lättsamma delarna. I projektet började testerna bra enligt denna modell men till slut blev det så tungrott att projektet (i det här exemplet) fick blanda upp de komplexa testerna med mindre komplexa och lättare områden för att komma framåt.

När tiden inte räcker till

Ett annat exempel som inte är helt ovanligt är att tiden i projektet inte räcker till och eftersom lanseringsdatumet är heligt är det lättare att korta av testtiden i projektet. Vilka tester prioriteras i sådana fall? I det här fallet, och inte helt ovanligt generellt sett, blir det knäckebrödet och småkakorna som går igenom testerna medan surdegarna blir kvar.

Acceptanstest innan systemtest

Ett lite mer våghalsigt exempel på ett projekt från verkligheten är där tidplanen var pressad och beslut fattades om att acceptanstesterna i princip skulle genomföras före systemtesterna. Jag kan meddela att även det projektet nådde i mål och systemets funktionalitet blev kvalitetssäkrat.
Oavsett hur testarbetet planeras ser jag det som viktigt att testplanen är iterativ. Det brukar skilja sig åt vilka områden som är viktigast i början av ett projekt jämfört med i slutet av ett projekt.

Ett sätt att ta sig an testplaneringen är att utgå från följande punkter (hämtade från Stefan Görling):

  • Funktionalitet före stabilitet
  • Enskilda funktioners funktion snarare än kombinationerna av dem
  • De synliga funktionerna före de osynliga

De vanliga användningsfallen före de ovanliga.

Knäckebröd, småkakor eller surdegar, testa alla sorter! Vill du veta mer läs vårt White Paper om kvalitetsäkring av IT-system genom att klicka här.

Eleonore Hammare, VD Systemstrategerna Förvaltning