Man kan aldrig testa allt, därför måste man fundera över vilka affärsrisker som finns i utvecklingsprojektet. Med detta som utgångspunkt kan man planera i vilken ordning man ska testa, hur man ska minimera riskerna kring testerna och hur testerna ska prioriteras, så att man testar det mest kritiska först. Din teststrategi kommer då att ha samma affärsprioritet som styr hela utvecklingsprojektet. I det här blogginlägget beskriver jag hur du bör tänka när det gäller riskbaserad testning.
Det finns ett affärsmässigt perspektiv på hur viktigt det är att testa. Den bransch där ditt system utvecklas är också viktig. Om ditt projekt till exempel rör bank, försäkring, medicinteknik eller myndigheter har företaget ett rykte om sig att det ska fungera korrekt. Även om felet bara är en stavfel kan det minska förtroendet för hela företaget. I andra fall kan det vara av yttersta vikt för det företag du arbetar för att få ut en produkt på marknaden före alla andra, så det kan hända att de accepterar att den första versionen av produkten innehåller vissa buggar. I alla projekt finns det vanligtvis en avvägning mellan tid, kostnad och kvalitet. Om du prioriterar kvalitet kommer det att påverka tid och kostnad. Om tid är viktigast kommer kostnad och kvalitet att påverkas.
Med andra ord är faktorerna tid, kostnad och kvalitet också viktiga parametrar för din testplanering . Det finns faktiskt en risk att du testar ”för mycket” i förhållande till projektets övergripande prioritering. Detta är viktigt för att testinsatserna ska ske med samma mål som hela projektet ska mätas mot. När du planerar dina tester tar du fram testfall, testscenarier eller förutsättningar för utforskande tester och får en lista över allt som ska testas. Men inte alla tester är lika viktiga; det finns alltid funktioner i systemet som körs många gånger, medan andra funktioner körs mindre ofta. Det finns också andra faktorer som avgör om en funktion i systemet kräver mer eller mindre testning. Hur komplex en funktion är vad gäller krav och utveckling har stor betydelse för hur du prioriterar testerna.
Ett riskbaserat test bygger på en riskanalys som vanligtvis utgår från vad som ska testas inom en viss testnivå, till exempel systemtest eller inom en sprint. Vilken typ av riskanalys du väljer är inte särskilt viktigt; det viktiga är att du tar hänsyn till sannolikheten och konsistensen hos de aspekter som valts ut av projektet, såsom affärskritiska aspekter, komplexa implementeringar, komplexa data och så vidare. Beakta även de tids-, kostnads- och kvalitetsfaktorer som nämns ovan.
En riskbaserad testanalys kan genomföras på olika sätt; detta är ett förslag som visar hur du kan gå tillväga. Det kanske inte passar just dig och ditt projekt, men vi delar med oss av några bra tips som du kan använda.
1. Utse en person till riskansvarig som ska leda den riskbaserade testanalysen – helst testledaren.
2. Riskerna måste först och främst identifieras inom uppdragets omfattning, vilket kan göras på klassiskt vis med hjälp av ”gula lappar”. Eller varför inte använda mind mapping, där ni skriver ner risker – både höga och låga. Detta görs bäst i grupp, till exempel i ett gemensamt rum, så att ni kan inspireras av varandra, bli mer kreativa och tänka utanför ramarna.
3. När insamlingen av risker är klar måste de grupperas, vilket vanligtvis görs efter funktioner eller områden. Men det kan finnas andra sätt att gruppera riskerna som passar uppdraget bättre. Grupperingen görs av riskchefen.
4. Riskchefen sammankallar ett nytt möte för riskanalys där han presenterar riskerna och deras gruppindelning. Nu kan deltagarna komma med synpunkter och lägga till nya risker; vid behov kan riskerna brytas ned i mer detalj. Efter det mötet ska riskkartan vara färdig, och förutsättningarna för att genomföra en riskanalys där sannolikheter och konsekvenser utvärderas ska ha identifierats.
5. Riskchefen sammankallar en ny workshop där själva riskanalysen genomförs.Exempel på deltagare ärtestledare,erfaren testare,kund,arkitekt, projektledare,produktägare/systemansvarig ocherfaren utvecklare.
6. Sannolikhet och konsekvens måste vägas mot varandra för varje risk. Börja med att gå igenom sannolikheten för att risken ska inträffa (på en skala från 1 till 4) och föra in den i kalkylbladet.
När det gäller sannolikheten tar vi hänsyn till olika faktorer som påverkar sannolikheten för att risken ska inträffa.
Fortsätt att viktiga konsekvenserna för varje risk. Dölj kolumnen Sannolikhet så att den inte påverkar viktningen av konsekvensen.
Här är det viktigt att identifiera alla relevanta intressenter och fundera över om vissa av dessa är viktigare än andra och, i så fall, hur de bör viktas.
7. Multiplicera sannolikheten med konsekvensen så får du ett riskvärde. Fördela riskerna efter deras riskvärde:
8. Bestäm hur riskerna ska elimineras:
9. Börja arbeta med de risker som har det högsta riskvärdet:
10. Därefter är det dags att börja skriva testfall/scenarier/angiva villkor för utforskande tester på detaljnivå.
11. Om du vill ha fullständig täckning av kraven kan du, parallellt med att testerna specificeras, kontrollera hur väl kraven testas. I punkt 9 har risker, krav och tester kartlagts; nu kan du kontrollera om det finns krav som inte har definierade tester. Om det finns krav som inte täcks av testfall/scenarier/explorativa tester, notera dem och lägg in dem, helst under en ny flik i Excel-arket.
12. Utför steg 3–10 för de krav som inte omfattades av riskanalysen. Hantera kraven på samma sätt som riskerna, dvs. ta fram ett riskvärde, vilket hjälper dig att planera i vilken ordning testerna ska utformas och genomföras.
13. Nu har du ett system som kommer att testas med fullständig kravtäckning och du har eliminerat alla höga risker genom att ha testfall/scenarier/explorativa tester som säkerställer att all viktig funktionalitet testas.
14. När det är dags för nästa leverans/sprint är det bra att följa upp den tidigare riskanalysen och ställa sig följande frågor:
15. När du planerar den kommande leveransen/sprinten gör du på samma sätt som beskrivs ovan, men här måste även regressionstester identifieras. Ett tips är då att välja testfall/scenarier/explorativa tester där avvikelser har upptäckts och korrigerats samt att välja testfall/scenarier/explorativa tester med högt riskvärde.
—
Hoppas detta ger dig lite hjälp på traven. Alla tester är olika och du måste improvisera så att det passar organisationen, testnivån eller de sprintar du arbetar med.