Liksom med allt annat så kan det vara svårt för den som inte har arbetat/arbetar inom området att förstå vad test innebär och hur viktigt det är att det blir gjort. Denna guide är sammanställd för att försöka svara på de vanligaste frågorna och förklara de olika begrepp som finns inom test.
Behövs testning?
Förr så var inte svaret givet. Då innebar testning att man kanske stängde systemet en sen eftermiddag för att först ta en säkerhetskopia, stänga av t ex inloggning och mailfunktionalitet så att inte användare fick tillgång till systemet eller mail ifrån det, uppgradera live, testa några timmar och sedan var allt klart. Då var ett system något som man för det mesta använde sig av inom företaget/organisationen och för det mesta så kunde man leva med att de viktigaste funktionerna inte fungerade till 100% från början. Vid kontakt med ett företag kunde man då få detta sagt till sig: “datan fungerar inte, kan du ringa igen senare?”
Numera så har testning högre prioritet då vi har blivit mer beroende av fungerande system samt att även personer utanför sin egen organisation har tillgång till informationen, kanske till och med skapar/uppdaterar informationen eller beställer något i systemet. Nu finns det testsystem, testare, testledare, certifieringar samt verktyg för att hantera krav, tester, testplan. testresultat, defekter etc. På grund av att vi numera är så beroende av att allt fungerar alltid så behövs någon typ av testning, men hur avancerad testning som behöver göras kan variera från gång till gång.
Värt att tänka på
Testning av ett system/program kan vara komplext eller enkelt beroende på vad det är som skall testas, vilka krav som finns, integrationer med andra system/program, typ av testning, befintlig dokumentation, hur viktigt system/program är för verksamheten/användarna/personer/kunder vars information finns i systemet/programmet samt acceptanskriterier. Det viktigaste är att man har rätt förutsättningar samt att man dokumenterar arbetet så att man kan använda sig av arbetet även i framtiden samt att man då kan se vad testresultatet blev historiskt bakåt i tiden.
Testning är en del av en kvalitetssäkring, men bara för att ett system/program är testat så är det inte samma sak som att det är kvalitetssäkrat.
Testning är en del av utvecklings- och underhållsprocessen och har t ex inget att göra med om verksamheten jobbar på det mesta optimala sättet eller om det ens är på detta sätt organisationen/företaget vill/kan arbeta på. Därför är det viktigt att man först tar fram hur man vill/kan arbeta inom organisationen/företaget och dokumenterar detta i t ex krav, arbetsflöden som sedan kan brytas ner i användarfall/testfall, väljer/utvecklar ett system/program som stödjer dessa arbetsflöden.
Det är inte ovanligt att man under testprocessen inser att man behöver justera krav/arbetsflöden pga att så som man tänkte från början fungerar inte i praktiken. I vissa fall kan det bli så att man kommer fram till att systemet/programmet inte går att justera/konfigurera så att man kan arbeta på det sätt som man vill utan då ställs man inför tre val: anpassning/utveckling av systemet (ev så är detta något som leverantören inte går med på då systemet är en standardprodukt eller så vill de ha betalt för att göra detta), anpassning av verksamheten eller välja ett annat system.
– Test visar endast vad som är fel, men kan inte bevisa att det inte finns något fel
– I regel så kan man inte testa allt utan man behöver använda sig av riskanalyser, prioriteringar och olika testtekniker – Tidig testning kan spara tid och pengar, dvs testa så tidigt som möjligt
– Om samma tester exekveras varje gång kommer man att hitta mindre och mindre nya defekter (Immunitetsparadoxen)
Vad bör en testprocess innehålla som minimum?
En testprocess bör innehålla planering, analys, design och exekvering av tester, rapportering av teststatus och testresultat.
Syftet med testning är att förhindra att allvarliga brister finns i systemet/programmet när det tas i drift, verifiera att arbetsflöden fungerar, skapa förtroende för systemet/programmet och verifiera att avtal/krav/standarder efterlevs.
Nedan finns en generell beskrivning på de olika delarna i en testprocess. Detta kan variera väldigt mycket beroende på t ex, storleken på projektet, behov av löpande rapportering av test, mottagare av testrapport, syftet för test etc. I regel så går man igenom (exekverar) testprocessen ett antal gånger innan man är klar.
Testplanering innehåller aktiviteter som beskriver testmål och hur man uppnår dessa (avgränsningar, tidsplan, avslutskriterier etc).
Under testanalysen så identifierar man testbara funktioner och definierar testvillkor, dvs vad som skall testas. Följande är exempel på vad som kan används som underlag: kravspecifikationer, design- och implementationsinformation och riskanalyser.
Man börjar redan här att välja/prioritera det som skall testas. Det är inte ovanligt att man hittar inkonsekvenser, felaktigheter, motsägelser och utelämnande under analysen. Nu skall du veta: ”Vad som skall testas”.
Under testdesign skapas underlaget för testerna genom att frågan: ”Hur ska det testas?” besvaras, t ex genom dessa arbetsmoment: design och prioritering av testfall, identifiera de förutsättningar som behövs, t ex testdata, program, hårdvara, användare och designa testmiljön.
Vid testimplementation så kontrollerar man att allt finns förberett för exekvering genom att: utveckla och prioritera tester, skapa testset/sviter av testerna baserat på t ex arbetsflödena/krav, testmiljö skapas, testdata etc skapas. Vanligtvis så görs design och implementation samtidigt.
Under testexekveringen så körs de testset/sviter som har skapats och som minimum görs detta: jämför faktiskt resultat med förväntat resultat, rapporterar defekter och loggar resultatet. Vid testavslut skapas en testrapport som kan innehålla information om: skapade defekter (antal eller mer detaljerat), ej lösta defekter (antal eller mer detaljerat), rekommendation, lärdomar under test och vilka ändringar som skulle behövas göras för framtida iterationer, releaser, projekt samt förslag på förbättringar av testprocessen.
Olika nivåer av testning
Man brukar dela upp testning i olika testnivåer: enhets- (komponents-), integrations-, system- och acceptanstestning.
Regressions- och omtestning är något man kan göra under alla ovanstående testnivåer. Regressionstestning görs när man gör en förändring/uppgradering av systemet/programmet i stället för att testa allting. Man testar då de kritiska funktionerna, det som man vet har ändrats, annat som man tror kan ha påverkats och sådant som brukar sluta fungera vid ändringar. Omtestning görs om man har hittat en defekt och denna har blivit rättad. Som minimum så kör man om de tester som inte fungerade tidigare, men man kan även behöva köra/skapa andra tester pga de ändringar som gjordes för att rätta defekten. Syftet är att bekräfta att defekten har åtgärdats.
Man bör ta hänsyn till att förr eller senare kommer man att uppdatera systemet/programmet pga t ex behov av ny funktionalitet, nya arbetssätt, större defekträttningar, ändringar i integrerade system/hårdvara, säkerhet, krav för fortsatt support från leverantören eller lagkrav (vid större projekt så hinner man till och med uppgradera systemet/programmet innan projektet är klart). Av denna anledning så kan det vara bra att fundera på regressionstester för att testa ett urval av den funktionalitet som företaget/organisationen måste ha fungerande från det ögonblick som uppdateringen har blivit installerad/konfigurerad i produktionssystemet/programmet i samband med att man skapar andra typer av testfall. Kanske är det så att man kan använda hela/en del av testfallen som underlag för att skapa ”en bas” av regressionstestfall. I slutändan kommer det ändå att vara så att man måste fatta beslut om vad det är som behöver testas när man vet vad som uppdateras så att en del av testningen fokuserar på det som har blivit uppdaterat och den funktionalitet som detta kan/har påverkat.
Man kan dela upp test i funktionell- och icke funktionell testning. Vid funktionell testning så testar man så att systemet/programmet beter sig så som förväntat och här kan man använda sig av krav, användarberättelser, användningsfall eller funktionsspecifikationer/manualer. Man testar vad systemet/programmet skall göra. Vid icke funktionell testning så testar man systemets/programmets egenskaper t ex prestanda, säkerhet och skalbarhet. Man testar hur väl systemet/programmet fungerar.
Erfarenhetsbaseradtestning, testar t ex sådant som det brukar vara problem med (i detta system/program eller i liknande system/program) och vilka fel som man som användare brukar göra.
Negativtestning, testar att man t ex inte kan fylla i felaktig information (t ex bokstäver där det skall vara siffror), klicka på spara utan att ha fyllt i tvingande fält, en användare kan göra saker som de inte skall kunna göra.
Utforskandetestning, kan göras utan testfall, men det är viktigt att man dokumenterar vad man har gjort så att man kan beskriva detta om man upptäcker något som man tycker är ett fel.
Behövs både testledare och testare?
Det beror helt och hållet på hur stort testbehovet är. Vid mindre behov så kan mycket väl en testare ta ansvaret och sköta allt, men man behöver vara medveten om att man i så fall tar bort mycket av testarens testtid till att göra annat. Nedanstående tabell visar en generell bild över vad som normalt görs av vilken roll. Det är inte ovanligt att t ex defektuppföljning även hamnar på testledare eller testare:
| Uppgift | Testledare | Testare |
| Skapa/granska teststrategi | X | |
| Planera testaktiviteter | X | |
| Skapa/uppdatera testplan | X | |
| Följa upp/rapportera teststatus och testresultat | X | |
| Granska testplan | X | |
| Analysera, granska, utvärdera testunderlaget | X | |
| Skapa testfall | X | |
| Granska testfall som andra har skapat | X | |
| Förbereda testdata | X | |
| Skapa testexekveringsunderlag/testsviter (vad som skall exekveras och i vilken ordning) | X | |
| Exekvera tester, dokumentera resultat och defekter/avvikelser | X |
Defekthantering
Defekter som hittas under testningen skall loggas. Hur de loggas varierar mellan olika företag/organisationer och t ex storleken på projektet.
Alla defekter som loggas bör undersökas och prioriteras och inte endast av IT utan också av produktägaren/verksamheten/kunden (beroende på vid vilken typ av testning man hittade defekten).
De defekter som är kritiska och påverkar systemet/programmet så pass mycket så att det inte går att driftsätta systemet/programmet behöver lösas. Däremot de mindre defekter som inte påverkar t ex viktig funktionalitet, arbetssätt, dataintegritet, säkerhet kan mycket väl lösas i en senare release av systemet/programmet. De flesta system/program driftsätts innan alla defekter är lösta pga att annars kommer man aldrig att driftsätta systemet/programmet. Följande fråga behöver besvaras: Fungerar systemet/programmet ”tillräckligt bra” för att driftsättas? Det svåra är vad själva definitionen av ”tillräckligt bra” är.
Lämpligen så skapar man en defektprocess som beskriver hur man hanterar defekter och att där då även ingår någon definition av de olika prioriteringsnivåerna.
När man undersöker den loggade defekten så är det viktigt att man ställer sig frågan: Är detta en defekt? Det är inte ovanligt att en defekt kan vara handhavande fel, fel på testfall eller att man tycker att systemet/programmet skall fungera på ett annat sätt än vad det har specificerats när man utvecklade/beställde systemet. Vad står det i t ex krav, användarberättelser, acceptanskriterier och användarmanualer?
Verktyg för testning
Det finns en del verktyg/system som kan underlätta testarbetet, t ex Azure DevOps och Quality Center. Använder inte företaget/organisationen redan ett verktyg så behöver man utvärdera vilket som stödjer deras behov bäst. Man bör tänka på att om det inte redan finns ett verktyg som man kan använda sig av så behövs det tid för att konfigurera, lära sig verktyget samt dokumentera hur verktyget skall användas. Är det ett mindre projekt så kanske man kan nöja sig med att använda sig av Office i kombination med en bra mappstruktur. Det man bör fundera på är hur man vill hantera framtida testningar och defekter. För det mesta så har man nytta av att kunna se hur man har gjort tidigare t ex: Har vi testat detta tidigare? Vad blev resultatet då? Har vi haft defekten tidigare? Kan vi använda oss av de gamla testfallen? Hur såg kraven ut? Några ändringar i arbetsflödet?