Riskbaserad testning: tillvägagångssätt, matris, process och exempel

Riskbaserad testning

Riskbaserad testning (RBT) är en typ av mjukvarutestning som baseras på sannolikheten för risk. Det innebär att bedöma risken baserat på mjukvarans komplexitet, verksamhetens kritiska karaktär, användningsfrekvens och de områden som sannolikt innehåller en risk. defektRiskbaserad testning prioriterar testning av de funktioner i programvaran som har störst effekt och är mer benägna att ha defekter.

Risk är förekomsten av en osäker händelse med en positiv eller negativ effekt på ett projekts mätbara framgångskriterier. Det kan vara en händelse som inträffat tidigare, en aktuell händelse eller något som kan hända i framtiden. Dessa osäkra händelser kan påverka ett projekts kostnads-, affärs-, tekniska och kvalitetsmål.

Risker kan vara positiva eller negativa.

• Positiva risker kallas möjligheter och hjälper till med hållbarhet i företaget. Exempel inkluderar investeringar i ett nytt projekt, förändringar av affärsprocesser och utvecklingping Nya produkter.
• Negativa risker kallas hot, och rekommendationer för att minimera eller eliminera dem måste implementeras för att projektet ska lyckas.

Eftersom tekniken fördelar ansträngning snarare än att lägga till en ny testnivå, placeras den ovanpå de andra typer av mjukvarutestning snarare än att ersätta någon av dem.

När man ska implementera riskbaserad testning

Riskbaserad testning kan implementeras i

• Projekt med tids-, resurs- eller budgetbegränsningar.
• Projekt där riskbaserad analys kan användas för att upptäcka sårbarheter för SQL-injektionsattacker.
• Säkerhetstestning i molnbaserade datormiljöer.
• Nya projekt med höga riskfaktorer, såsom bristande erfarenhet av de tekniker som används eller bristande kunskap inom affärsområdet.
• Inkrementella och iterativa leveransmodeller.

Riskhanteringsprocess

Låt oss nu förstå stegen som ingår i riskhanteringsprocessen.

Risk identifiering

Riskidentifiering kan göras genom riskworkshops, checklistor, brainstorming, intervjuer, Delphi-tekniken, orsak- och verkan-diagram, lärdomar från tidigare projekt, rotorsaksanalys och kontakt med områdesexperter och ämnesexperter.

Ett riskregister är ett kalkylblad som innehåller en lista över identifierade risker, potentiella åtgärder och bakomliggande orsaker. Det används för att övervaka och track riskerna (både hot och möjligheter) under hela projektets livslängd. Riskhanteringsstrategier kan användas för att hantera positiva och negativa risker.

En riskuppdelningsstruktur spelar en viktig roll i riskplanering. Den hjälper till att identifiera riskbenägna områden och stöder effektiv utvärdering och riskövervakning under projektets gång. Den hjälper till att avsätta tillräckligt med tid och resurser för riskhanteringsaktiviteter och att kategorisera de många källor från vilka projektrisker kan uppstå.

Exemplet nedan visar hur en riskuppdelningsstruktur grupperar risker i kategorier så att ingen riskkälla förbises.

Riskanalys (inkluderar kvantitativ och kvalitativ analys)

När listan över potentiella risker har identifierats är nästa steg att analysera dem och filtrera riskerna efter betydelse. En av de kvalitativa riskanalysteknikerna är riskmatrisen (behandlas i ett senare avsnitt). Denna teknik används för att fastställa sannolikheten och effekten av risken.

Riskhanteringsplanering

Baserat på analysen kan vi avgöra om riskerna kräver en åtgärd. Till exempel kommer vissa risker att kräva en åtgärd i projektplanen, andra kräver en åtgärd i projektövervakningen och vissa kommer inte att kräva någon åtgärd alls.

Riskägaren ansvarar för att identifiera alternativ för att minska sannolikheten och påverkan av de tilldelade riskerna.

Riskreducering är en riskhanteringsmetod som används för att minska de negativa effekterna av möjliga hot. Detta kan göras genom att eliminera riskerna eller reducera dem till en acceptabel nivå. Diagrammet nedan placerar riskhanteringsplanering inom den bredare riskhanteringscykeln.

Risk beredskap

Beredskapsplan kan beskrivas som möjligheten av en osäker händelse vars inverkan är okänd eller oförutsägbar. En beredskapsplan är också känd som handlingsplan eller reservplan för värsta tänkbara scenarier. Med andra ord, den avgör vilka åtgärder som kan vidtas när en oförutsägbar händelse inträffar.

Riskövervakning och kontroll

Riskkontroll- och övervakningsprocessen används för att track de identifierade riskerna, övervaka kvarvarande risker, identifiera nya risker, uppdatera riskregistret, analysera orsakerna till eventuella förändringar, genomföra riskhanteringsplanen och övervaka riskutlösare. Deras effektivitet i att minska risker utvärderas sedan.

Detta kan uppnås genom riskomvärderingar, riskrevisioner, avvikelse- och trendanalyser, teknisk prestandamätning, statusuppdateringsmöten och retrospektiva möten.

Tabellen nedan ger information om input, verktyg och output för riskövervakning och -kontroll.

Vi måste komma ihåg att risken ökar med förändringar i teknik, projektets storlek, projektets längd (en längre projekttidsram), antalet sponsrande organ, projektuppskattningar, ansträngningar och brist på lämplig kompetens.

Riskbaserad testmetod

Ovanstående hanteringsprocessen matar testmetoden nedan. Varje numrerat steg producerar indata som nästa steg förbrukar.

1. Analysera kraven.
   • Dokument (SRS, FRS, användningsfall) granskas. Denna aktivitet görs för att hitta och eliminera fel och oklarheter.
   • Godkännande av krav är en av riskreduceringsteknikerna för att undvika att sena ändringar införs i projektet. Alla ändringar av ett krav efter att dokumentet har baslinjeberäknats involverar en ändringskontrollprocess och efterföljande godkännanden.
2. Bedöm riskerna genom att beräkna sannolikheten och effekten som varje krav kan ha på projektet, med hänsyn till definierade kriterier som kostnad, tidsplan, resurser, omfattning, teknisk prestanda, säkerhet, tillförlitlighet och komplexitet.
   • Identifiera sannolikheten för misslyckande och högriskområdena. Detta kan göras med hjälp av en riskbedömningsmatris.
   • Använd ett riskregister för att lista de identifierade riskerna. Uppdatera, övervaka och track riskerna regelbundet med jämna mellanrum.
   • Riskprofilering måste göras i detta skede för att förstå riskkapaciteten och risktoleransnivåerna.
3. Prioritera kraven utifrån betyget.
   • Den riskbaserade testprocessen är definierad.
   • Mycket kritiska och medelhöga risker kan beaktas för planering, implementering och övervakning av begränsningar. Låga risker kan hållas på en bevakningslista.
   • Kvalitetsbedömning av riskdata görs för att analysera kvaliteten på datan.
4. Planera och definiera testerna enligt bedömningen.
   • Tillämpa en lämplig testmetod och testdesigntekniker så att de objekt med högst risk testas först. Objekt med hög risk kan testas av en resurs med goda ämneskunskaper och erfarenhet.
   • Olika testdesigntekniker kan användas – till exempel beslutstabell teknik på högrisktestobjekt, och endast ekvivalensuppdelning för testobjekt med låg risk.
   • Testfall är också utformade för att täcka flera funktioner och heltäckande affärsscenarier.
   • Förbered testdata, testförhållanden och testbädd.
5. Revse testdokumentationen — testplaner, teststrategi, testfall, testrapporter och alla andra dokument som skapats av testteamet.
   • Peer review är ett viktigt steg för att identifiera defekter och minska risken.
6. Utför torrkörningar och kvalitetskontroller av resultaten.
   • Testfall utförs enligt riskpostens prioritet.
   • Bibehålla tracskillnad mellan riskposter, de tester som täcker dem, resultaten av dessa tester och de defekter som upptäcks under testningen. Alla teststrategier som utförs korrekt kommer att minska kvalitetsriskerna.
   • Riskbaserad testning kan användas på alla testnivåer — komponent, integrering, system och acceptanstestning.
   • På systemnivå behöver vi fokusera på vad som är viktigast i applikationen. Detta kan avgöras genom att titta på funktionernas synlighet, användningsfrekvensen och den möjliga kostnaden för fel.
   • Utvärdering av exitkriterier: alla högriskområden testades fullt ut, med endast mindre kvarvarande risker kvar.
7. Rapportera de riskbaserade testresultaten och analysera mätvärdena.
   • Omvärdera befintliga riskhändelser och nya riskhändelser baserat på Key Risk Indicators.
   • Uppdatera riskregistret.
   • Beredskapsplaner fungerar som en reserv- eller nödplan för höga exponeringsrisker.
   • Felanalys och felförebyggande åtgärder används för att eliminera felen.
   • Omtestning och Regressionstestning validera felåtgärderna baserat på den förberäknade riskanalysen, och högriskområden bör täckas mest intensivt.
   • Riskbaserad automatiseringstestning, om möjligt.
   • Beräkning av kvarvarande risk.
8. Övervaka och kontrollera riskerna.
   • Avslutningskriterier eller slutförandekriterier kan definieras separat för olika risknivåer. Alla nyckelrisker har åtgärdats med lämpliga åtgärder eller beredskapsplaner, och riskexponeringen är på eller under den nivå som överenskommits som acceptabel för projektet.
   • Omvärdering av riskprofilering och kundfeedback.

Riskbaserad testmetod för systemtestet

1. Tekniskt systemtest — Detta kallas miljötest och integrationstest. Miljötestet omfattar testning i utvecklings-, test- och produktionsmiljöer.
2. Test av funktionssystem — Testning av alla funktioner, egenskaper, program och moduler. Syftet med detta test är att utvärdera om systemet uppfyller de specificerade kraven.
3. Icke-funktionellt systemtest — Testning av icke-funktionella krav: prestanda, belastningstester, stresstester, konfigurationstester, säkerhetstester, säkerhetskopiering och återvinning procedurer och dokumentation (system-, drift- och installationsdokumentation).

Diagrammet nedan ger en tydlig översikt över ovan nämnda process.

Systemtestning omfattar både funktionella tester och icke-funktionella tester.

Funktionell testning säkerställer att produkten eller applikationen uppfyller kundernas och företagets krav. Å andra sidan, icke-funktionell testning görs för att verifiera om produkten uppfyller kundens förväntningar vad gäller kvalitet, tillförlitlighet, användbarhet, prestanda och kompatibilitet.

Hur man utför riskbaserad testning: Hela processen

Det här avsnittet behandlar den riskbaserade testprocessen, som sker i fem faser.

1. Risk identifiering
2. Riskanalys
3. Riskrespons
4. Test Scoping
5. Testprocessdefinition

De fem faserna sammanfaller enligt nedan.

1. I denna process identifieras och kategoriseras riskerna, ett utkast till riskregister upprättas och risksortering görs för att identifiera de väsentliga riskerna.
2. Riskhantering innebär att formulera testmålen utifrån riskerna och välja lämpliga tekniker så att testaktiviteten eller testtekniken uppfyller dessa testmål.
3. Dokumenterade beroenden, krav, kostnader och den tid som krävs för programvarutestning beaktas för att beräkna testeffektivitetspoängen.
4. Testresultatping är en granskningsaktivitet som kräver deltagande av alla intressenter och teknisk personal. Det är viktigt att hålla sig till den överenskomna riskomfattningen. Dessa risker måste hanteras genom testning, och alla medlemmar måste vara överens om det ansvar som tilldelats dem och den budget som avsatts för dessa aktiviteter.
5. Efter att testomfattningen har fastställts måste testmålen, antagandena och beroenden för varje teststeg sammanställas i standardformatet.

Det bearbetade exemplet nedan kopplar varje krav till dess tillhörande risk och till det testmål som adresserar det.

Låt oss betrakta de funktionella kraven F1, F2 och F3, och de icke-funktionella kraven N1 och N2.

F1 — Funktionskrav, R1 — Risk i samband med F1

• Testmål 1 — Visa med hjälp av ett test att systemets förväntade funktioner och funktionaliteter fungerar korrekt, och att risk R1 kan åtgärdas genom funktionstestning.
• Test — Testning av webbläsarsidor utförs för att utföra viktiga användaruppgifter och verifiera att R1 (risken i samband med F1) kan åtgärdas i en rad olika scenarier.

F2 — Funktionskrav, R2 — Risk i samband med F2

• Testmål 2 — Visa med hjälp av ett test att systemets förväntade funktioner och funktionaliteter fungerar korrekt, och att risk R2 kan åtgärdas genom funktionstestning.
• Test — Testning av webbläsarsidor görs för att utföra viktiga användaruppgifter och verifiera att R2 kan hanteras i en rad olika scenarier.

F3 — Funktionskrav, R3 — Risk i samband med F3

• Testmål 3 — Visa med hjälp av ett test att systemets förväntade funktioner och funktionaliteter fungerar korrekt, och att risk R3 kan åtgärdas genom funktionstestning.
• Test — Testning av webbläsarsidor görs för att utföra viktiga användaruppgifter och verifiera att R3 kan hanteras i en rad olika scenarier.

N1 — Icke-funktionellt krav, NR1 — Risk i samband med N1

• Testmål N1 — Visa med hjälp av ett test att systemets driftsegenskaper fungerar korrekt och att risk NR1 kan åtgärdas genom icke-funktionell testning.
• Test — Användbarhetstestning är en teknik som används för att bedöma hur enkla användargränssnitt är att använda och för att verifiera att NR1 kan åtgärdas med användbarhetstestning.

N2 — Icke-funktionellt krav, NR2 — Risk i samband med N2

• Testmål N2 — Visa med hjälp av ett test att systemets driftsegenskaper fungerar korrekt och att risk NR2 kan åtgärdas genom icke-funktionell testning.
• Testa — Säkerhetstest är en teknik som används för att kontrollera om en applikation är säker eller sårbar för attacker, om det finns informationsläckor och för att verifiera att NR2 kan åtgärdas genom säkerhetstester.

Specifika testmål: De listade riskerna och testmålen är specifika för testtyperna, vilket sammanfattas nedan.

Procedur för att utforma den riskbaserade testprocessen

• Förbered ett riskregister. Detta registrerar riskerna som härrör från en generisk risklista, en befintlig checklista och brainstormingsessioner.
• Inkludera riskerna i samband med systemets funktionella och icke-funktionella krav (användbarhet, säkerhet, prestanda).
• Varje risk tilldelas en unik identifierare.

Kolumnerna 1 och 2 i det registret innehåller identifieraren och riskbeskrivningen. De återstående kolumnerna beskrivs nedan.

Sannolikheten (1 låg, 5 hög) och konsekvenserna (1 låg, 5 hög) för varje risk bedöms, eftersom de två registren t.ex.tracts nedan visar.

• Testexponeringen beräknas.
• Testaren analyserar varje risk och utvärderar om risken är testbar eller inte.
• Testmål definieras för de testbara riskerna.
• Testaren specificerar den testaktivitet som ska utföras på ett planerat sätt för att uppnå testmålet (statiska granskningar, inspektioner, systemtester, integrationstester, acceptanstester, HTML-validering, lokaliseringstester och så vidare).
• Dessa testaktiviteter kan delas in i etapper (komponenttestning eller enhetstestning, integrationstestning, systemtestning, acceptanstestning).
• Ibland kan en risk åtgärdas genom mer än ett teststeg.
• Identifiera beroenden och antaganden (tillgänglighet av kompetenser, verktyg, testmiljöer och resurser).
• Testeffektivitet beräknas. Testeffektivitet avser testarens konfidensnivå att risken definitivt kommer att åtgärdas genom testning. Testeffektivitetspoängen är ett tal mellan ett och fem (5 = hög konfidens, 1 = låg konfidens).
• Uppskatta ansträngningen, den tid som krävs och kostnaden för att förbereda och utföra dessa tester.

De kommande två exentracts visar de återstående registerkolumnerna och testets effektivitetspoäng på plats.

• Testprioritetsnumret beräknas. Det är produkten av sannolikhet, konsekvenser och testeffektivitetspoäng.
• 125 (maximalt) – en mycket allvarlig risk som skulle kunna upptäckas med testning.
• 1 (minimum) — en mycket låg risk som inte skulle upptäckas med testning.
• Baserat på testets prioritetsnummer kan testviktigheten klassificeras som Hög (röd), Medel (gul) och Låg (grön). De objekt med högst risk testas först.
• Fördela testaktiviteterna till teststegen. Utse den grupp som ska utföra testning för varje mål i de olika teststegen (enhetstestning, integrationstestning, systemtestning, acceptanstestning).

Fördelningen över teststegen visas nedan.

Vad som ingår och inte ingår i testningens omfattning bestäms i testets omfattning.ping fas.

• För varje steg definieras testmål, komponent som testas, ansvar, miljö, inträdeskriterier, utgångskriterier, verktyg, tekniker och leveranser.

Generiska testmål — dessa generiska mål är tillämpliga på flera projekt och tillämpningar.

• Komponenten uppfyller kravet och är redo att användas i större delsystem.
• Riskerna förknippade med de specifika testtyperna behandlas och testmålen uppnås.
• Integrerade komponenter är korrekt monterade och gränssnittskompatibilitet mellan komponenterna säkerställs.
• Systemet uppfyller de specificerade funktionella och icke-funktionella kraven.
• Produktkomponenterna tillgodoser slutanvändarnas behov i sin avsedda driftsmiljö.
• En riskhanteringsstrategi används för att identifiera, analysera och minska risker.
• Systemet uppfyller kraven i branschens regelverk.
• Systemet uppfyller kraventracfaktiska skyldigheter.
• Institutionalisering och uppnåendet av andra specifika mål såsom kostnads-, tidsplan- och kvalitetsmål.
• System, processer och människor uppfyller affärskraven.

Generiska testmål kan definieras för de olika teststegen.

• Komponenttestning
• Integrationstestning
• Kravhantering
• Acceptantestning

Låt oss titta på systemtestfasen.

1. G4 och G5 visar att systemet uppfyller de funktionella kraven (F1, F2, F3) och de icke-funktionella kraven (N1, N2).
2. Visa med hjälp av tester att systemets förväntade funktioner och funktionaliteter fungerar korrekt, och att riskerna i samband med F1, F2 och F3 kan åtgärdas genom funktionstestning.
3. Visa med hjälp av tester att systemets driftsegenskaper fungerar korrekt och att riskerna i samband med N1 och N2 kan åtgärdas genom icke-funktionell testning.
4. Baserat på testets prioritetsnummer kan testviktigheten klassificeras som Hög (röd), Medel (gul) och Låg (grön).

Prioriterings- och riskbedömningsmatris

Riskbedömningsmatrisen är sannolikhets-påverkansmatrisen. Den ger projektgruppen en snabb överblick över riskerna och prioriteringen med vilken var och en av dessa risker behöver hanteras.

Risk rating = Probability x Severity

Sannolikhet är ett mått på chansen att en osäker händelse inträffar, baserat på exponering i termer av tid, närhet och upprepning. Det uttrycks som en procentandel.

Detta kan klassificeras som Frekvent (A), Sannolikt (B), Enstaka (C), Fjärrstyrt (D), Osannolikt (E) och Eliminerat (F).

• Frekvent — Förväntas inträffa flera gånger under de flesta omständigheter (91–100 %).
• sannolikt — Förekommer sannolikt flera gånger under de flesta omständigheter (61–90 %).
• Enstaka — Kan förekomma någon gång (41–60 %).
• fjärr — Osannolikt att inträffa, men det kan inträffa någon gång (11–40 %).
• Osannolik — Kan förekomma under sällsynta och exceptionella omständigheter (0–10 %).
• Utslagen — Omöjligt att inträffa (0 %).

Allvarlighetsgraden är graden av påverkan av skadan eller förlusten orsakad av den osäkra händelsen. Den poängsätts från 1 till 4 och kan klassificeras som Katastrofal = 1, Kritisk = 2, Marginell = 3 och Försumbar = 4.

• Katastrofal — Hårda konsekvenser som gör projektet helt improduktivt och till och med kan leda till projektnedstängning. Detta måste vara högsta prioritet vid riskhantering.
• Kritisk — Stora konsekvenser som kan leda till stora förluster. Projektet är allvarligt hotat.
• Marginal — Kortsiktiga skador som fortfarande är reversibla genom återställningsåtgärder.
• Försumbar — Liten eller minimal skada eller förlust. Detta kan övervakas och hanteras genom rutinmässiga rutiner.

Prioriteten är klassificerad i fyra kategorier, vilka är kartlagda mot riskens allvarlighetsgrad och sannolikhet, såsom visas i bilden nedan.

• Allvarlig
• Hög
• Medium
• Låg

Allvarlig: Riskerna som faller inom denna kategori är markerade med gult. Aktiviteten måste stoppas och omedelbara åtgärder måste vidtas för att isolera risken. Effektiva kontroller måste identifieras och implementeras. Vidare får aktiviteten inte fortsätta om inte risken reduceras till en låg eller medelhög nivå.

Hög: Riskerna som faller inom denna kategori är markerade med rött och kräver omedelbara åtgärder eller en riskhanteringsstrategi. Omedelbara åtgärder måste vidtas för att isolera, eliminera eller ersätta risken och för att implementera effektiva riskkontroller. Om dessa problem inte kan lösas omedelbart måste strikta tidsfrister definieras för att lösa dem.

Medium: Riskerna som faller inom denna kategori är markerade med gult. Rimliga och praktiska åtgärder måste vidtas för att minimera riskerna.

Låg: Riskerna som faller inom denna kategori är markerade med grönt och kan vanligtvis accepteras, eftersom de inte utgör något betydande problem. En regelbunden översyn är fortfarande ett måste för att säkerställa att kontrollerna förblir effektiva.

Generisk checklista för riskbaserad testning

Matrisen avgör hur en risk bedöms. Checklistan nedan avgör vilka kandidater som ska ingå i matrisen från första början.

• Viktiga funktioner i projektet.
• Användarsynlig funktionalitet i projektet.
• Den funktionalitet som har störst säkerhetspåverkan.
• Funktioner som har störst ekonomisk påverkan på användarna.
• Mycket komplexa områden inom källkod och felbenägen kod.
• Egenskaper eller funktioner som kan testas tidigt i utvecklingscykeln.
• Funktioner eller funktionaliteter som lades till i produktdesignen i sista minuten.
• Kritiska faktorer i liknande eller relaterade tidigare projekt som orsakade problem.
• Primära faktorer eller problem i liknande eller relaterade projekt som hade en stor inverkan på drifts- och underhållskostnader.
• Dåliga krav som leder till dålig design och tester, vilket kan påverka projektets mål och leveranser.
• I värsta fall kan en produkt vara så defekt att den inte kan omarbetas och måste skrotas helt, vilket skulle orsaka allvarlig skada på företagets rykte. Identifiera vilka typer av problem som är avgörande för produktmålen.
• Situationer eller problem som skulle orsaka ihållande kundtjänstklagomål.
• Heltäckande tester som enkelt kan fokusera på flera av systemets funktioner.
• Den optimala uppsättningen tester som kan maximera risktäckningen.
• Vilka tester har det bästa förhållandet mellan högrisktäckning och tidsåtgång?

Riskbaserad testresultatrapportering och mätvärden

1. Förberedelse av testrapport. Att rapportera teststatus handlar om att effektivt kommunicera testresultaten till projektets intressenter, ge en tydlig förståelse och visa jämförelsen av testresultaten mot testmålen.
   • Antal planerade kontra utförda testfall.
   • Antal godkända eller misslyckade testfall.
   • Antal identifierade defekter, samt deras status och allvarlighetsgrad.
   • Antal kritiska defekter som fortfarande är öppna.
   • Miljöavbrott, om några.
   • Storslagna händelser, om några.
   • Testsammanfattningsrapport och testtäckning rapportera.
2. Förberedelse av mätvärden. Ett mätvärde är en kombination av två eller flera mått som används för att jämföra programvaruprocesser, projekt och produkter.
   • Variation i ansträngning och schema.
   • Produktivitet vid förberedelse av testfall.
   • Testdesignens täckning.
   • Produktivitet vid testfallskörning.
   • Riskidentifieringseffektivitet i %.
   • Riskreduceringseffektivitet i %.
   • Testeffektivitet i %.
   • Täckning av testkörning.
   • Produktivitet för testkörning.
   • Defektläckage i %
   • Effektivitet vid feldetektering, och defektdensitet.
   • Kravsstabilitetsindex.
   • Kostnaden för kvalitet.

Dessa åtgärder läses sedan tillbaka mot riskerna:

• Analysera riskerna i icke-funktionella kategorier (prestanda, tillförlitlighet och användbarhet) baserat på defektstatus och antalet godkända eller misslyckade testresultat, i relation till riskerna.
• Analysera riskerna i funktionella kategorier med hjälp av testmått, defektstatus och teststatus för godkänt eller misslyckat, i relation till riskerna.
• Identifiera viktiga indikatorer för lead och lag och skapa tidiga varningsindikatorer.
• Övervaka och rapportera riskindikatorer för lead och lag (nyckelriskindikatorer) genom att analysera datamönster, trender och ömsesidiga beroenden.

Inneboende risk kontra restriskbedömning

Riskidentifiering och analys bör även omfatta inneboende risker, kvarvarande risker, sekundära risker och återkommande risker.

• Inneboende risk: De risker som identifierades eller redan fanns i systemet innan kontrollerna och åtgärderna implementerades. Inneboende risker kallas även bruttorisker.
• Kvarstående risk: De risker som återstår efter att kontroller och åtgärder har implementerats. Kvarvarande risker kallas nettorisker.
• Sekundär risk: Den nya risken som orsakas av implementeringen av riskhanteringsplanen.
• Återkommande risk: Sannolikheten att de ursprungliga riskerna kommer att uppstå igen.

Mätning av testresultat baserad på risk hjälper organisationen att känna till den återstående nivån av kvalitetsrisk under testkörning och att fatta välgrundade beslut om release.

Riskprofilering och kundfeedback

Riskprofilering är en process för att hitta den optimala investeringsrisknivån för kunden, med hänsyn till den risk som krävs, riskkapaciteten och risktoleransen.

1. Risk krävs är den risknivå kunden måste ta för att få en tillfredsställande avkastning.
2. Riskkapacitet är den nivå av ekonomisk risk som klienten har råd att ta.
3. Risk tolerans är den risknivå som kunden föredrar att ta.

Feedback från kunder: samla in kundfeedback och recensioner för att förbättra verksamheten, produkten, tjänsten och upplevelsen.

Fördelar med riskbaserad testning

Fördelarna med riskbaserad testning anges nedan.

• Förbättrad produktivitet och kostnadsminskning.
• Förbättrade marknadsmöjligheter (time to market) och leverans i tid.
• Förbättrad serviceprestanda.
• Förbättrad kvalitet, eftersom alla kritiska funktioner i applikationen testas.
• Tydlig information om testomfattning. Med hjälp av denna metod vet teamet vad som har testats och vad som inte har testats.
• Fördelning av testansträngningar baserad på riskbedömning är det mest effektiva och effektiva sättet att minimera den kvarvarande risken vid utsläpp.
• Mätning av testresultat baserad på riskanalys gör det möjligt för organisationen att identifiera den kvarvarande nivån av kvalitetsrisk under testkörning och att fatta välgrundade beslut om release.
• Optimerad testning med tydligt definierade riskbedömningsmetoder.
• Förbättrad kundnöjdhet tack vare kundengagemang och god rapportering och framsteg trackung.
• Tidig upptäckt av potentiella problemområden, så att effektiva förebyggande åtgärder kan vidtas.
• Kontinuerlig riskövervakning och bedömning under hela projektets livscykel hjälper till att identifiera och lösa risker, och att ta itu med de problem som kan äventyra uppnåendet av de övergripande projektmålen.

Vanliga frågor