Du kan aldrig testa allt, därför behöver du fundera på vilka affärsmässiga risker som finns i ditt utvecklingsprojekt. Med det här som utgångspunkt kan du planera för i vilken ordning du ska testa, hur du ska minimera riskerna kring test och hur testerna ska prioriteras, så att du testar det mest kritiska först. Din teststrategi kommer då att ha samma affärsmässiga prioritering som styr hela utvecklingsprojektet. I det här blogginlägget beskriver jag hur du ska tänka när det kommer till riskbaserad test.
Det finns ett affärsmässigt perspektiv för hur viktigt det är att testa. Vilken bransch ditt system utvecklas i är också viktigt. Är ditt projekt inom till exempel bank, försäkring, medicinteknik eller myndigheter så har företaget ett anseende att det ska fungera rätt. Även om felet bara är en felstavning så kan det sänka förtroendet för hela företaget. I andra fall så kanske det är viktigast för företaget du arbetar för att få ut en produkt på marknaden före alla andra, då kanske det går att acceptera att det finns en del buggar i den första versionen av produkten. I alla projekt brukar det finnas en prioritering mellan tid, kostnad och kvalitet. Om du prioriterar kvaliteten så kommer det att påverka tid och kostnad. Är tiden viktigast så kommer kostnad och kvalitet att påverkas.
Tids-, kostnads- och kvalitetsfaktorerna är med andra ord också viktiga parametrar för din testplanering. Det finns faktiskt en möjlighet att du testar ”för mycket” i förhållande till projektets övergripande prioritering. Det här är viktigt så att testinsatsen sker med samma mål som hela projektet ska mätas på. När du planerar dina tester tar du fram dina testfall, testscenarier eller förutsättningarna till utforskande test och får fram en lista med allt som ska testas. Men alla tester är inte lika viktiga, det finns alltid funktioner i systemet som körs många gånger, medans andra funktioner körs mer sällan. Det finns också andra faktorer som styr om en funktion i systemet kräver mer eller mindre tester. Hur komplex en funktion är i kravställning och utveckling har stor tyngd i din prioritering av testerna.
En riskbaserad test utgår från en riskanalys vanligtvis baserad på vad som ska testas inom en speciell testnivå, till exempel systemtest eller inom en sprint. Vilken typ av riskanalys man väljer har inte så stor betydelse, det viktiga är att man tar hänsyn till sannolikhet och konsekvens för av projektet utvalda aspekter såsom affärskritiskt, implementationskomplext, datakomplext med mera. Tänk även på de tids-, kostnads- och kvalitetsfaktorerna som nämns ovan.
En riskbaserad testanalys kan genomföras på olika sätt, det här är ett förslag som visar hur du kan göra. Detta kanske inte passar just dig och ditt projekt men vi hoppas att du kan få några bra tips som du har nytta av.
1. Utse en person till riskansvarig, som kommer att driva den riskbaserade testanalysen - förslagsvis testledaren.
2. Först och främst ska risker identifieras inom ramen för uppdraget, vilket kan ske på ett klassiskt sätt med hjälp av ”gula lappar”. Eller varför inte använda Mind Mapping, där man skriver ner risker - höga som låga. Det här görs bäst i grupp, i ett gemensamt rum eller via länk, för att man ska inspireras av varandra, bli mer kreativ och tänka utanför boxen.
3. När insamlingen av risker är genomförd ska riskerna grupperas, vilket oftast görs i funktioner eller områden. Men det kan finnas andra sätt att gruppera riskerna som passar uppdraget bättre. Grupperingen görs av den riskansvarige.
4. Den riskansvarige kallar till nytt riskanalysmöte där hen presenterar riskerna och dess gruppering. Nu kan deltagarna kommentera och lägga till nya risker, vid behov kan riskerna brytas ned mer detaljerat. Efter det mötet ska kartan över risker vara klar och förutsättningarna finnas för att genomföra en riskanalys där sannolikheten och konsekvensen utvärderas.
5. Riskansvarig kallar till en ny workshop där själva riskanalysen genomförs.
Exempel på deltagare är:
- Testledare
- Erfaren testare
- Beställare
- Arkitekt
- Projektledare
- Produktägare/systemförvaltare
- Erfaren utvecklare
6. Sannolikhet och konsekvens ska viktas för respektive risk. Börja med att gå igenom sannolikheten att risken ska inträffa, 1-4 och för in det i kalkylbladet.
Sannolikhet
När det gäller sannolikhet tar vi hänsyn till olika faktorer som påverkar sannolikheten att risken ska inträffa.
Fortsätt att vikta konsekvenserna för respektive risk. Dölj kolumnen med Sannolikhet så att den inte påverkar viktningen av konsekvensen.
Konsekvens
Här gäller det att identifiera alla relevanta intressenter och fundera på om några utav dessa är viktigare än andra och i så fall hur de ska viktas.
7. Multiplicera Sannolikheten med Konsekvensen och du får fram ett riskvärde. Fördela riskerna utefter dess riskvärde:
1-4 = låg
5-9 = mellan
10-16 = hög
8. Bestäm hur riskerna ska elimineras:
- Om man ska eliminera alla risker på en gång genom att börja med de som har högst riskvärde och eliminera nedåt.
- Om man ska utgå från respektive funktion/område och sedan eliminera riskerna.
- Om man ska utgå från leveranser/sprintar.
- Om man överhuvudtaget ska skriva testfall/scenarios/ge förutsättningar för utforskande tester för de riskerna med lågt riskvärde?
9. Börja att arbeta med de risker som har högst riskvärde:
- Kontrollera om risken kan knytas till ett krav eller motsvarande, notera det i kolumnen Mappat Krav.
- Identifiera ett eller flera testfall/scenarios/förutsättningar för utforskande tester eller motsvarande som kontrollerar att risken elimineras. Skriv dem på rubriknivå för att få en övergripande syn över hur stort testarbetet kommer att bli. Testerna kommer att detaljeras i nästa punkt, 10.
10. Då var det dags att börja att skriva testfall/scenarios/ge förutsättningar för utforskande tester på en detaljnivå.
- Utse ansvariga för varje testfall/scenarios/förutsättning för utforskande tester.
- Skriv först på rubriknivå för att få en känsla över hur många tester som ska genomföras. Det görs förslagsvis i ett testverktyg alternativt fortsätt att bygga ut excel-bladet, vilket kommer bli väldigt komplext.
- Skriv testfallen/scenarios/förutsättning för utforskande tester på detaljnivå.
- Fundera på om testfallet/scenariot ska exekveras automatiserat eller manuellt.
- Testfallen/scenarios bör granskas innan de exekveras.
- Om möjligt i vilken ordning testfallen/scenarion/utforskande test ska utföras. Förslagsvis ska de tester med högt riskvärde testas först men det kan finnas grundfunktionalitet som man vill säkerställa att den fungerar innan de andra testerna påbörjas.
11. Om du vill ha full kravtäckning, kan du parallellt med att testerna detaljeras kontrollera hur väl kraven testas. I punkt 9 har risker, krav och tester mappats, nu kan du kontrollera om det finns krav som inte har tester definierade. Finns det krav som inte täcks med testfall/scenarios/utforskande test, notera dem och lägg in dem, förslagsvis under en ny flik i Excel-arket.
12. Utför punkt 3-10 för de krav som inte täcktes av riskanalysen. Hantera kraven på motsvarande sätt som risken, dvs ta fram ett riskvärde, vilket hjälper dig att planera i vilken ordning testen ska tas fram och genomföras.
13. Nu har du ett system som kommer att testas med full kravtäckning och du har eliminerat alla höga risker i och med att du har testfall/scenarios/utforskande test som ska säkerställa att all viktig funktionalitet testas.
14. När det är dags för nästa leverans/sprint kan man med fördel göra en uppföljning av tidigare riskanalys och fråga sig:
a. Kan man ändra sannolikheten/konsekvensen för risken? Har vi eliminerat eller delvis eliminerat risken mha de tester som tagits fram/utförts?
b. Har det tillkommit några nya risker eller krav som behöver behandlas på motsvarande sätt som beskrivits ovan.
15. Vid planering av kommande leverans/sprint, gör på motsvarande sätt som beskrivet ovan men här ska det också identifieras regressionstester. Ett tips är då att välja ut testfall/scenarios/utforskande test där avvikelser har hittats och rättats samt välj ut testfall/scenarios/utforskande test med högt riskvärde.
Hoppas att detta ger dig lite hjälp på traven, alla tester är olika och man behöver improvisera så att det passar organisationen, testnivå eller om det är i sprintar man jobbar med.
Vill du veta mer om varför du ska ta fram en teststrategi, vad den bör bestå av och få tips pm bra grunder för att lyckas med test? Då vill jag passa på att tipsa om vår guide "Teststrategi - Det här bör den innehålla". Ladda ner den via knappen nedan!