Den ultimata guiden till riskbaserad testning: riskhantering vid programvarutestning

ultimate guide risk based testing

Den ultimata guiden till riskbaserad testning, riskhantering och dess strategi med exempel:

Vad är riskbaserad testning?

Riskbaserad testning är att utföra testning eller att utforma och genomföra scenarierna, så att de bästa affärsriskerna som kommer att ha en negativ inverkan på verksamheten som identifierats av kunden upptäcks i sin produkt eller funktion tidigt i livscykeln och är mildras genom att genomföra mildrande åtgärder.

=> Klicka här för en komplett testplan-handledningsserie

Den negativa effekten kan inkludera kostnadspåverkan, missnöjd kund, dålig användarupplevelse och till och med i den utsträckning att förlora kunderna.

Med andra ord är RBT-metoden att säkerställa att testning görs på ett sådant sätt att även om en användare hittar ett fel i produktionen hindrar det inte honom / henne från att använda programvaran eller påverkar inte verksamheten på ett allvarligt sätt.

RBT testas utifrån produktrisker. RBT ska ta reda på det i god tid, eftersom det är risken för att en viss funktion eller funktionalitet i produktionen misslyckas och dess inverkan på verksamheten när det gäller kostnader och andra skador genom att använda en prioriteringsteknik för testfallet.

Därför använder riskbaserad testning principen om prioritering av testerna av funktionerna, modulerna och funktionerna hos en produkt eller programvara. Prioriteringen baseras på risken för sannolikheten för att den funktionen eller funktionaliteten i produktionen misslyckas och dess inverkan på kunderna.

Vad du kommer att lära dig:

• Riskbaserad testning och dess relevans för Agile & DevOps
  • Riskbaserad testmetod
    • När använder vi RBT-metoden?
    • Exempel på RBT-tillvägagångssätt
  • Sätt att genomföra riskanalys
  • Riskanalysförfarande
  • Metod för riskanalys
    • Steg 1) Använda ett 3X3-rutnät
    • Steg # 2) Sannolikhet och inverkan av misslyckande
    • Steg 3) Testa prioritetsnät
    • Steg 4) Detaljer om testning
  • Hur är RBT relevant för Agile och DevOps?
  • Fördelar med riskbaserad testmetod
• Riskhantering under testplanering
  • Process för riskhantering
    • # 1) Riskidentifiering
    • # 2) Riskbedömning / riskeffektanalys
    • # 3) Riskreducering
  • Slutsats
• Riskhantering vid testutförandefas (med exempel)
  • Riskhantering - med fokus på AUT
  • Hur sker test av riskbaser?
  • Slutsats
  • Rekommenderad läsning

Riskbaserad testning och dess relevans för Agile & DevOps

Tre hundra timmar på utveckling av programvara kan göras värdelösa på bara 30 sekunder med en enda defekt som identifierats i produktionen.

Detta kan i sin tur förstöra syftet med hela produkten utan något annat alternativ än bara att dra tillbaka den från marknaden. Och det är betydelsen och behovet av ”kvalitetstestning”.

Med den snabba tillväxten av teknik är mjukvaran värd i molnet som stöder flera operativsystem, flera plattformar, komplexa IT-infrastrukturer etc., slutanvändarna blir mer och mer noga med funktioner, alternativ och de kompromissar aldrig för kundnöjdhet. .

Numera blir ”Kvalitet” en avgörande faktor i leverans av programvara, där kontinuerliga förbättringar sker för att förbättra kvaliteten för att hålla kunderna nöjda.

Vi märker ofta att det är ett vanligt problem för nästan alla testare att vara under enormt tryck att deras testfönster pressas och vanligtvis överlämnas byggnaden till dem för testning i sista minuten. Det finns inte tillräckligt med tid och resurser för att de ska kunna köra alla tester som de har utformat och automatiseringstäckningen är inte alltid 100% och den har sina egna utmaningar.

Leveranstidslinjen kan inte missas och samtidigt kan kvaliteten inte äventyras också. Oavsett plan B, att lägga till ytterligare testresurser genom att dra ut från de andra lagen, inte fungerar, Plan C, sluta göra alla andra aktiviteter och avled ansträngningen till detta ensam, hjälper inte riktigt. Hur mycket som helst tillägg av testresurser, i slutändan, fungerar dock inte.

Det finns inget annat alternativ än bara att köra begränsade och viktiga tester inom tillgänglig tid och resurser.

Så hur bestämmer vi vilket test som är viktigt i detta skede? Oavsett vad en testare anser vara viktig kanske inte riktigt viktigt för kunderna. Från vems perspektiv bestäms vikten av funktionen eller en funktionalitet? Vem bestämmer vilka viktiga tester? Och många andra frågor fortsätter att uppstå.

För att svara på alla dessa frågor och för att hantera ovanstående situation effektivt, kallades en testmetod ”Riskbaserad testning” , ringde snart 'RBT' , tillkom, där teamet tydligt har planerat och identifierat testscenarierna baserat på ”Project Risk” -kriterierna.

Även om QA-teamet har en tydlig bild av de viktiga testerna är RBT en beprövad metod för att identifiera viktiga och viktiga tester ur kund- och affärsperspektiv genom en 'Riskanalys' procedur .

Så, mot det traditionella sättet att helt enkelt identifiera defekterna i programvaran, har QA-metoden och målet förändrats med tiden på grund av förändringen i tekniken, ökad konkurrens på marknaden för att släppa en kvalitetsprogramvara, introduktion av 'Automatisera allt' och i en helhet introduktion av Agile och DevOps praxis att leverera programvaran under några timmar.

Följaktligen är den nuvarande trenden med 'Testing Principle' inte bara 'att identifiera defekterna' utan också att

# 1) Fokusera på det område av produkten där det har stor påverkan på verksamheten på grund av fel eller stor sannolikhet för att produktionen går sönder.

#två) Fokuserar på identifiera bristerna tidigt och låta ett team fixa det så tidigt som möjligt och därmed låta programvaran / produkten eller funktionen göra det ”Misslyckas snabbt”.

# 3) Den viktigaste aspekten av QA-teamets service är nu att fokusera på kunden för att ge kunden värde genom att öka fokuset på ”Upplevelse från slut till slutkund”.

Riskbaserad testmetod

Det är alltid som att förbereda sig för en undersökning, att man inte kan säga att testning är tillräckligt och att det inte finns fler defekter i programvaran, även om de utformar och utför ett stort antal tester.

Det finns en punkt där mjukvarustabilitet inte kommer att garanteras dubbelt genom att öka antalet testfall enbart. Vid denna tidpunkt är det inte bara att fokusera på antalet tester utan på vad kunden faktiskt förväntar sig av släppet.

Därför är det viktigt att hitta en balans för att optimera testningen för att få maximal nytta med en rimlig testansträngning. Och detta är viktigare när testtidslinjerna är mycket snäva och det inte finns tillräckligt med resurser för att utföra tillräckliga tester.

I detta fall spelar således RBT-metoden en nyckelroll för att optimera QA-ansträngningen och maximera testfördelen med den minsta affärsrisken.

Så om vi fokuserar på ovanstående aspekt, kommer arbetet med en QA att bli mycket lättad. De behöver inte bränna sina helger på kontoret, kontinuerligt testa programvaran och bli oroliga för alla S4 (Severity 4) och P4 (Priority 4) defekter som kommer ut ur testet.

Tja, 4 anses vara den lägsta prioriteten och svårighetsgraden av defekterna vid testning. De kan bättre investera sin tid i andra användbara aspekter av projektet.

För att sammanfatta de viktigaste drivkrafterna för ”Riskbaserad testning”:

• Att möjliggöra testning av 'vad kunderna vill ha' ur ett affärsperspektiv.
• För att uppfylla tidsplanen med förväntad kvalitet.
• För att optimera QA-ansträngningen.

När använder vi RBT-metoden?

Detta används under nedanstående scenarier:

• RBT-tillvägagångssätt kan användas när det finns en begränsning eller begränsning av projektets tid, kostnad och resurser och när det finns ett behov av att optimera resurserna.
• RBT-tillvägagångssätt används när programmet är mer komplext och anpassar ny teknik och därmed innebär många utmaningar.
• När programmet är ett FoU-projekt och det är av första typen och det finns ett antal okända och risker i projektet.

Exempel på RBT-tillvägagångssätt

Flera riskbaserade analysmetoder används i IT-branschen för att övervinna de risker som produktionen står inför och dess påverkan.

Nedan följer en sådan metod:

Detta tillvägagångssätt för RBT inkluderar att identifiera produktens ”vitala funktioner eller nyckelfunktioner” och bedöma de risker som var och en av dessa funktioner utsätts för i produktionen och genomföra lämpliga mildrande åtgärder på plats för att sänka eller mildra risken.

Följaktligen inkluderar RBT-metoden att testa funktionerna som har sannolikheten för misslyckande och störst påverkan på verksamheten. Typerna av fel kan vara operativa eller affärsmässiga, tekniska, externa, etc.

Sätt att genomföra riskanalys

Det finns ingen standardprocess eller mall definierad som sådan för att utföra riskanalysen i programvarutestning för varje funktion i en produkt. Olika organisationer använder sin egen metod för riskanalysmetoder.

Riskanalys kan utföras på olika projektobjekt för att identifiera riskerna och för att implementera en RBT-metod för analys. Dessa artiklar inkluderar,

• Funktioner
• Funktioner
• Användarberättelser
• Krav
• Använd fodral
• Testfall

I det här fallet, låt oss bara fokusera på testfall för att förstå implementeringen av riskbaserad testning.

Riskanalysförfarande

Riskanalys inkluderar involvering av relevanta intressenter av programmet från både Tekniskt team och affärslag ” , som inkluderar ägare av produkten, produktchefer, affärsanalytiker, arkitekter, testare och kundrepresentanter.

Brainstorming-sessioner som involverar dessa intressenter skulle organiseras för att genomföra diskussionen för att identifiera vikten av varje funktion i en produkt och prioritera dem baserat på risken för misslyckande och dess inverkan på slutanvändarna i produktionen.

Olika ”projektdokument” som kravdokument, tekniska specifikationsdokument, arkitekturdokument och designdokument, affärsprocessdokument, användningsfallsdokument etc. blir ingången för brainstormningssessionen.

Intressentens kunskap om produkten och den befintliga produkten på marknaden kommer också att vara en input faktor för diskussionen.

Få andra ingångskällor kan också inkludera,

• Att samla ingångar om den mest använda funktionaliteten.
• Ingångar från att rådfråga en domenexpert.
• Data från den tidigare versionen av produkten eller liknande produkt på marknaden.

Under brainstorming session identifieras riskerna med var och en av dessa funktioner. Typerna av risker kan vara en operation, teknisk eller affärsrelaterad. Testerna och scenarierna relaterade till dem viktas och riskvärdena bedöms utifrån sannolikheten för att risken uppstår och effekterna av risken.

”Sannolikheten för riskförekomst” kan bero på:

• Dålig förståelse för funktionen av produktutvecklingsteamet.
• Felaktig arkitektur och design.
• Otillräcklig tid att designa.
• Teamets oförmåga.
• Otillräckliga resurser - människor, verktyg och teknik.

”Effekten av risken” är effekten av att användare och företag misslyckas om det inträffar. Effekten kan vara,

• Kostnadspåverkan, vilket resulterar i en förlust.
• Affärspåverkan som leder till att företag förlorar eller förlorar marknadsandelar, rättsliga förfaranden, förlust av licens.
• Kvalitetspåverkan, vilket resulterar i undermålig eller inkompetent produktutsläpp.
• Dålig användarupplevelse, vilket resulterar i missnöjd och förlust av en kund.

Fokusområdet för att bedöma risken för en funktion eller produkt kan vara,

• Affärsområdets kritiska funktion.
• Mest använda funktioner och viktig funktionalitet.
• Defekta utsatta områden
• Funktionalitet med säkerhets- och säkerhetspåverkan.
• Område för komplex design och arkitektur.
• Ändringar gjorda från tidigare versioner.

Metod för riskanalys

Låt oss förstå den ”riskbaserade testmetoden” i detalj nu.

Den riskbaserade testmetoden använder RISK som kriterier i alla testfaser i testcykeln, dvs. testplanering , testdesign, testimplementering, testkörning , och testrapportering. Helst kan man designa ett stort antal möjliga testscenariokombinationer.

Därför inkluderar RBT-metoden en rangordning av testerna baserat på riskernas svårighetsgrad för att ta reda på det mest defekta eller riskabla området för misslyckande, vilket orsakar stor inverkan på verksamheten.

Huvudsyftet med riskanalys är att skilja mellan 'Högt värde' artiklar som produktegenskaper, funktioner, krav, användarberättelser , och testfall, och Lågt värde' och därmed senare till mer fokus på 'Högt värde' Testfall, genom mindre fokusering på 'Lågt värde' Testfall. Detta är det första steget i riskanalys innan riskbaserad testning påbörjas.

Huvuduppgiften för kategorisering eller gruppering av testfall i högt värde och lågt värde och tilldelning av prioritetsvärdet till vart och ett av dessa testfall inkluderar följande steg:

Steg 1) Använda ett 3X3-rutnät

Riskanalys utförs med hjälp av ett 3X3-rutnät, där varje funktionalitet, icke-funktionalitet och dess relaterade testfall bedöms av ett team av intressenter för dess ”Sannolikhetav misslyckande ”och” Effekt av misslyckande ”.

Sannolikheten för att varje funktionalitet i produktionen misslyckas nås i allmänhet av en grupp ”tekniska experter” och kategoriseras som ”Sannolikt att misslyckas, ganska troligt och osannolikt” längs nätets vertikala axel.

bästa skräpfilrensaren för Windows 10

På samma sätt upplevs slutkundens 'inverkan av fel' av dessa funktioner och funktioner i produktionen, om den inte testas bedöms av en grupp '' Affärsspecialister ”och kategoriseras under kategorierna” Mindre, synligt och avbrott ”längs nätets horisontella axel.

Steg # 2) Sannolikhet och inverkan av misslyckande

Alla testfall placeras i kvadranten i 3 X 3-rutnätet baserat på de identifierade värdena för sannolikheten för fel och påverkan av fel som visas som punkter i bilden nedan.

Uppenbarligen är hög sannolikhet för misslyckande och stor påverkan av fel (avbrott) grupperade i det övre högra hörnet av rutnätet, vilket är av stor betydelse och därför identifieras det att '' High Value '' - tester och '' Low Value '' - tester är grupperade i nedre vänstra hörnet som är minst eller ingen betydelse för kunden, där mindre funktioner kan ges till dessa funktioner eller testfall.

Steg 3) Testa prioritetsnät

Baserat på ovanstående positionering av testfallet i nätet prioriteras och märks testerna med prioriteringarna 1,2,3,4 och 5 och markeras mot var och en av dem. De viktigaste testerna är placerade i en 1^strutnät som har prioritet 1 och liknande mindre viktiga rankas som 2, 3, 4 och 5.

Slutligen sorteras alla testfall baserat på deras prioritetsnummer och plockas upp för körning i prioritetsordning. De med hög prioritet plockas upp för körning först och de med låg prioritet antingen utförs senare eller avskopas.

Steg 4) Detaljer om testning

Nästa steg är att bestämma nivån på detaljer för testning för det definierade testomfånget. Djupet av testets omfattning kan bestämmas baserat på ovanstående rangordning enligt nedanstående rutnät.

Tester med hög prioritet med rankning 1 testas 'Mer noggrant' och därför används experter för att testa dessa högkritiska funktioner och dess relaterade testfall. På samma sätt testar fall med prioritet 2, 3 och 4. Ett beslut att avgränsa prioritet 5-funktioner och tester baserat på tillgänglig tid och resurser kan tas.

Följaktligen hjälper detaljnivån för testmetoden att prioritera funktionerna och dess testfall inte bara testarna att identifiera '' högvärdiga tester '' utan också vägleda dem att besluta om deras 'detaljnivå för testning' baserat på dessa prioriterade rankningar och hjälper dem att utföra bättre tester och minskar testkostnaderna genom optimeringsprocessen.

Hur är RBT relevant för Agile och DevOps?

Efter att ha förstått den riskbaserade testmetoden för att utföra testerna baserade på prioriteringen av testerna beroende på 'risk för misslyckande' för en viss funktion och dess 'inverkan på kunden' live, skulle man uppenbarligen ställa frågan om relevansen av riskbaserad testmetod i Agile och DevOps Practices.

'Automatisera allt', 'Testa allt', 'Testa kontinuerligt', 'Testa upprepade gånger' är nyckelbegreppen för dessa metoder.

Varje gång, när det ändras i koden eller det finns en release, körs alla designade tester automatiskt Kontinuerlig integration (CI) / Kontinuerlig leverans (CD) pipeline snabbt och upprepade gånger, oavsett deras prioritering.

Vad är förhållandet mellan RBT och DevOps? Var skulle RBT passa in och bli relevant i Agile och DevOps ???

# 1) Ja, som jag sa tidigare är det inte att varje bransch och varje produkt har 100% automatiseringstäckning för sina testkörningar. Så om teamet överhuvudtaget måste välja prioritering för testutförande från valet av manuella testfall och vill spara energi och ansträngning av testresurserna mot andra aktiviteter, är RBT det bästa valet.

Det riskbaserade tillvägagångssättet är också en bättre insats för att köra automatiserade tester med högprioriterade och testa tidigast.

#två) QA-teamet kan använda RBT-metoden mer effektivt under kravanalysen genom att analysera kraven och tillhandahålla en förhandsrapport om de sannolika riskerna med produkterna och funktionerna så att lämpliga åtgärder kan vidtas proaktivt av programteamet för att mildra det.

# 3) RBT-metoden kan användas effektivt vid utformning av testfall och scenarier baserat på hög risk så att mer fokus kan läggas mot högriskfunktioner och funktioner.

# 4) Genom att identifiera områdena ”Hög risk” kan QA-teamet fokusera sin testinsats på dessa områden för att testa ”Mer noggrant” med hjälp av ”Högkvalificerade testare”.

# 5) 'Fail Fast', som vi alla vet är begreppet 'Agile' och 'DevOps', för vilket RBT-tillvägagångssätt hjälper till att identifiera 'högriskområdena' i programvaran, identifiera defekterna tidigt och låta dem misslyckas snabbt och misslyckas först och låt laget fixa det.

# 6) Det ultimata målet för Agile / DevOps är ”Kundfokus” och därmed gör RBT-metoden QA att fokusera på kundupplevelse än att bara hitta defekter.

Fördelar med riskbaserad testmetod

Vi förstod redan syftet och användningen av RBT-metoden att analysera kraven, utforma och genomföra testscenarierna. Det finns flera fördelar med RBT.

Vi kan konsolidera och lista fördelarna med riskbaserad testning som:

• Hjälper till en mer effektiv och optimerad användning av testresurser.
• Hjälper till att underlätta QA-arbetet, testning, testdesign och utveckling och testförberedelser genom prioritering.
• Hjälper till att bättre hantera QA-resurserna genom att fördela nyckelresurserna till områden med hög fokus.
• Det hjälper till vid effektivt utnyttjande av resurser och leder tid och energi på bättre saker i projektet.
• Hjälper QA-teamet att planera testinsatserna baserat på riskbedömning och identifiering av flyktiga och högriskområden.
• Det hjälper teamet att optimera de tester som ska genomföras beroende på vikten och därmed avveckla test med lågt värde i överenskommelse med intressenterna.
• Sammantaget hjälper det till kostnadsminskning genom optimerade och minskade testaktiviteter.
• RBT-metoden gör det möjligt för QA-teamet att testa högriskområdena först och låta produkten “misslyckas snabbt” och fixa snabbt.
• RBT-metoden hjälper till att skapa tydlighet i Testtäckning ' och ”Test Scope” för hela gruppen av intressenter.
• Teamet kan öka sitt fokus på högriskområden och hålla mindre fokus på lågriskområdet.
• RBT gör det möjligt för teamet att i god tid besluta om genomförandet av det mest effektiva sättet att mildra produktriskerna.
• RBT hjälper till att undvika effekten av olämpligt genomförande av begränsningar.
• Riskbaserad testning gör det möjligt för teamet att vidta lämpliga åtgärder antingen för att mildra eller planera för beredskap eller att placera någon lösning för att övervinna felet eller minska dess inverkan om risken uppstår i Live.
• RBT hjälper till att minimera den kvarvarande risken i utsläppet.
• Det hjälper till att uppnå ”Förbättrad kvalitet” genom mindre kostsamma defekter i produktionen.
• Hjälper i slutändan i 'Förbättrad kundupplevelse' och 'Nöjd kund'.

Därefter lär vi oss att hantera risker i testplanering och testutförandefaser i programvarutestningens livscykel.

Riskhantering under testplanering

Hur man hanterar risker under testplaneringsfasen:

Livet är fullt av risker och ett mjukvaruprojekt också. Allt kan gå fel när som helst. Vi är alltid på tårna för att göra saker rätt - men hur är det med att se till att ingenting går fel och att när vi vet exakt vad vi ska göra? Gå in i riskhantering - detta är en del av ett programvarutestningsprojekt som förbereder oss för att förebygga, förstå, hitta och komma över risker.

En risk är helt enkelt ett problem som sannolikt kommer att uppstå och när det inträffar kommer det att orsaka förlust.

Förlusten kan vara allt - pengar, tid, ansträngning eller en kompromiss i kvalitet. Förlusten är aldrig bra. Oavsett hur mycket en snurr vi ger det är det inte positivt och kommer aldrig att bli. Därför Riskhantering är en integrerad del av mjukvaruprojekt för att säkerställa att vi hanterar risker och förhindrar / minskar förluster.

Riskbaserad testning : Eftersom vi är en QA-gemenskap, låt oss vara specifika för risker och processen relaterad till den i vår QA-värld exklusivt. Riskerna bedöms och hanteras ungefär i två faser av vår Programvarutest livscykel . STLC kan kategoriseras i tre faser - Testplanering, testdesign och testutförande.

Riskhanteringsprocessen sker två gånger under:

1. Testplanering
2. Testa Case Design (avsluta) eller ibland i Test Execution-fasen

Det är obligatoriskt i fall 1 men i fall 2 är det mer en ”behovsbaserad” situation.

Tvådelad artikelserie:

Även om den underliggande processen är densamma, är typer av risker behandlas inom båda dessa områden är helt olika. För att göra rättvisa åt dem individuellt kommer vi att hantera dem annorlunda som en tvådelad serie.

Detta avsnitt kommer att handla om “Riskhantering under testplanering”.

Process för riskhantering

Den generiska processen för riskhantering innefattar tre viktiga steg:

1. Risk identifiering
2. Analys av riskeffekter
3. Riskreducering

Testa risker och lindringsexempel:

# 1) Riskidentifiering

Som det sägs är det första steget för att lösa ett problem att identifiera det. Detta steg handlar om att göra en lista över allt som potentiellt kan komma och störa det normala flödet av händelser.

Huvudresultatet av detta steg är en lista över risker.

Detta riskbaserade teststeg leds vanligen av QA-ledaren / chefen / representanten. Men ledningen ensam kommer inte att kunna komma med hela listan - hela QA-teamets input har en enorm inverkan. Vi kan säga att detta är en kollektiv aktivitet som leds av QA-ledningen.

Dessutom är de risker som identifieras under testplaneringsfasen mer 'ledarskapande' i orientering, vilket betyder att vi kommer att titta på allt som kan påverka QA-projektets schema, ansträngning, budget, infrastrukturförändringar etc. Fokus här är inte AUT, utan hur QA-fasen fortsätter.

Risker under testplanering: Riskbaserade testexempel

Följande är ett exempel på en lista över risker som kan listas under testplaneringsfasen. Observera att AUT och dess funktionalitet inte är i fokus här.

1. Testschemat är tätt. Om testets start är försenad på grund av designuppgifter kan testet inte förlängas utöver det schemalagda startdatumet för UAT.
2. Inte tillräckligt med resurser, resurser ombord för sent (processen tar cirka 15 dagar.)
3. Fel upptäcks i ett sent skede av cykeln eller i en sen cykel; fel som upptäcks sent beror troligen på otydliga specifikationer och är tidskrävande att lösa.
4. Omfattning definieras inte helt definierad
5. Naturkatastrofer
6. Icke tillgängligt av Independent Testmiljö och tillgänglighet
7. Försenad testning på grund av nya problem

Vid den här tiden kan du välja att vara så grundlig som du vill, beroende på hur mycket tid som finns.

När alla riskerna är listade går vi vidare till riskbedömning / riskeffektanalys.

# 2) Riskbedömning / riskeffektanalys

Är din riskanalys ungefär så här? :)

Riskanalys vid programvarutestning : Alla risker kvantifieras och prioriteras i detta steg. Varje risks sannolikhet (chansen att inträffa) och påverkan (mängden förlust som den skulle orsaka när denna risk uppstår) bestäms systematiskt.

Hög - medel-låg , värden tilldelas både sannolikheten och effekten av varje risk. Riskerna med 'hög' sannolikhet och 'Hög' påverkan tas hand om först och sedan följer ordern.

Tabell för riskeffektanalys:

Efter dessa steg skulle tabellen för riskeffektanalys för ovannämnda risker se ut så här (alla värden är hypotetiska och endast för förståelseändamål):

# 3) Riskreducering

Det sista steget i denna riskbaserade testning (RBT) är att hitta lösningar för att planera hur man hanterar var och en av dessa situationer. Dessa planer kan skilja sig från företag till företag, projekt till projekt och till och med person till person.

Riskreducerande tekniker:

Här är ett exempel på vad riskens tabell förvandlas till när denna fas är klar:

Några punkter att notera:

1. Ju tidigare riskhantering börjar i en QA-projektplaneringsfas, desto bättre.
2. Av alla tre stegen, Riskidentifiering är det viktigaste . Om något inte listas och övervägs för ytterligare steg försvinner risken.
3. Försök hitta en idealisk tidsram för den här aktiviteten. Kom ihåg att för mycket planering ger för lite tid att göra.
4. Om en ny situation uppstår efter riskhanteringsprocessen kan riskhanteringsplanen ändras eller uppdateras för att återspegla det senaste tillståndet.
5. Historisk data kan vara mycket användbart för framgången för denna process.

Slutsats

Detta avslutar riskhanteringen i testplaneringsfasen. Även om de underliggande stegen och principerna är likartade är riskhanteringsprocessen mer koncentrerad mot AUT när det händer i testdesign / exekveringsfasen.

dot net intervju frågor och svar för erfarna

I vårt nästa avsnitt kommer vi att täcka - Riskhantering i testutförandefasen.

Riskhantering vid testutförandefas (med exempel)

Under vår resa för att förstå riskhanteringsprocessen pratade vi om hur det går uteslutande i Testplaneringsfas av riskbaserad testning . Vi förstod också den generiska processen som involverar - riskidentifiering, riskbedömning och riskreduceringsplan.

Hur man hanterar risk vid testdesign eller testutförandefas:

Det finns en annan form av Riskhantering (även ibland kallad, Riskbaserad testning ) som inträffar under testkonstruktionen eller testkörningsfasen beroende på situationen. Vilken situation pratar vi nu om? Låt oss försöka förstå det först.

Vi vet alla att vårt testarbete är reaktivt. Inga krav (eller omfattning definierat), vi kan inte utföra en genomförbarhetsanalys och skriva testscenarier eller planera för testaktiviteter.

På samma sätt, när koden inte är klar har vi inget att testa, oavsett hur mycket förarbete vi kan ha varit redo med avseende på testfall, testdata etc. Testning är också det enda steget kvar innan produkten går leva.

Riskhantering - med fokus på AUT

Låt oss förstå detta bättre med ett exempel:

Om testningen skulle börja på det datumet, 1 jan^stoch fick fortsätta till 14 jan^th- när testningen är klar fixas vanligtvis produktens Go-live-datum omedelbart. Låt oss säga - 15 jan^thför enkelhetens skull. Nu, i perfekt värld skulle saker gå exakt som planerat. Men vi känner alla till verkligheten.

Låt oss i det här fallet anta att testningen av någon anledning inte började förrän den 7 januari^thvilket innebär att vi förlorade hälften av vår testtid. Men vi behöver 14 dagar för att testa produkten noggrant. Vi kan flytta go-live-datumet längre med 7 dagar - dock; detta är vanligtvis inte ett alternativ. Eftersom produkten lovas att släppa ut marknaden på ett visst datum och eventuella förseningar är inte bra för verksamheten.

Så, vanligtvis måste vi testa team absorbera förseningarna, kompensera på något sätt, arbeta med den tillgängliga tiden och se till att produkten testas väl. Tufft jobb, eller hur?

Det är här riskhanteringsprocessen används igen.

• Nu om förseningar förväntas i förväg innan till och med testningen börjar - processen sker i testdesignfasen.
• Om förseningar inträffar under en Testutförandefas som startade normalt - processen följs under testutförandefasen.
• Stegen och metoden är desamma oavsett i vilken fas det händer.

Vad är processen?

Riskhantering äger rum för att avgöra vilka områden i AUT (Application Under Test) som behöver maximalt fokus. Dessa är vanligtvis de funktionella områdena (moduler eller komponenter) som är kritiska för den slutliga produktens framgång och som är mest benägna att misslyckas.

Läs också=> Failure Mode And Effects Analysis (FMEA) är en riskhanteringsteknik

Vem utför det?

Eftersom det gäller AUT är kunskapen om det inte bara med QA utan med alla andra team - Dev, BA, Client, Project management team etc. Det är därför en kollektiv insats, driven av testteamet.

Hur sker test av riskbaser?

Steg 1) Risk identifiering

Identifiera alla funktionella områden i AUT. Detta inkluderar helt enkelt att göra en lista.

Steg 2) Riskbedömning

Alla risker kvantifieras och prioriteras i detta steg. Kvantifiering är helt enkelt att tilldela ett nummer till varje risk i listan som ger en indikation på den prioritet som den behöver hanteras med.

Alla riskers sannolikhet (chansen att inträffa) och påverkan (mängden förlust som den skulle orsaka när denna risk uppstår) bestäms.

Den typiska metoden är att tilldela betyg. Till exempel, Sannolikheten kan ta värdena 1 till 5. 1 är sannolikheten för att händelsen är låg (sannolikt inte kommer att hända alls) och 5 är hög (kommer säkert att hända).

På samma sätt kan Impact också tilldelas en 1-5 rating. 1 med låg påverkan (även om denna risk inte uppnås är förlusten minimal) och 5 med hög påverkan (stora förluster när det händer).

Steg 3)

Gör ett tabellformat och cirkulera till alla teamrepresentanter - Dev, BA, Client, PM, QA och alla andra relevanta.

Steg 4)

Be varje team att fylla i värdena baserat på deras betyg för sannolikhet och påverkan.

Eftersom sannolikhets- och påverkansvärdena är numeriska kommer det att göra beräkningen av ”Risk Factor” -värdet enkelt.

Riskfaktor = Sannolikhet X Effekt. Ju högre riskfaktor, desto allvarligare är problemet.

Ett exempel:

Observera att detta just nu är resultatet av ett lags betyg. För ett projekt där 5 olika team är involverade skulle QA-teamet sluta med 5 olika tabeller.

Steg 5)

Ta ett genomsnitt av riskfaktorvärdena. Till exempel, om det finns 5 team, för varje modul, lägg till alla riskfaktorvärden och dela den med 5. Detta är de slutgiltiga värdena vi ska hantera. Säg, det här är de genomsnittliga riskfaktorerna:

Ju mer riskfaktor desto mer måste modulen testas.

Så, modul 5 och 2 är avgörande för företagets framgång. Dela resultaten med alla lag.

Steg 6)

Plan för riskreducering : Det här är steget som ändras från projekt till projekt. Vi har identifierat att modulerna 5 och 2 är de som behöver koncentreras mest.

Exempelav planen kan vara:

1. Modulerna 5 och 2 kommer att testas noggrant genom att se till att alla testfall relaterade till dem testas. De andra modulerna kommer att testas på utforskande basis.
2. Modulerna 5 och 2 kommer att testas först och sedan beroende på den tillgängliga tiden kommer de andra att tas om hand.

När en plan har gjorts når alla lag en överenskommelse och följer den för att testa produkten med hänsyn till riskfaktorn.

Det är allt!

Några viktiga punkter att notera:

• Eftersom detta är en kollektiv aktivitet som tar allas åsikt ; chanserna att det är korrekt och effektivt är högre.
• Detta är inte en formell metod och behöver inte vara en del av varje QA-projekt.
• Ibland, även om teamet väljer att inte rita tabeller och tilldela värden- a enkel brainstorming session med alla närvarande kan ge QA-teamet god vägledning om hur man går vidare.
• De utvecklingsgruppens bidrag är mycket viktigt eftersom det är de som skapar produkten så att de vet vad som kan fungera och vad som kan behöva ytterligare kontroll. Var noga med att hålla utkik efter det.
• Även om det finns flera steg i processen, det tar inte mycket tid att utföra dem . Speciellt om alla lag kan sitta tillsammans och arbeta samtidigt.
• Kom ihåg denna process och dess resultat är bara alternativet . Att få så mycket tid som planerat för testning är det bästa sättet att utföra QA-aktiviteten.

Slutsats

Den riskbaserade testmetoden indikerar tydligt att testarens fokus inte bara är att fortsätta utforska defekterna, oavsett svårighetsgrad och prioritet. Nu har saker och ting förändrats och testare måste arbeta smarta och de måste förstå det tydliga “Kundens behov och användarens önskemål”.

De måste studera produkten grundligt och förstå vilken som är den vanligaste funktionen i produktionen, vilken är den mest kritiska vägen för intäktsgenerering och hur man skyddar och skyddar kunderna från produktionsfrågor och affärshot.

Därför utbildar RBT-metoden tydligt de 3 testarna att bara testa allt eller testa omfattande inte betyder att testningen är komplett eller att det inte finns några defekter i produkten. Testa effektivt under en bestämd tid och se till att kritiska och större affärseffekter blir ogiltiga och det är ganska viktigt för testaren.

Således är riskbaserad testning det mest effektiva verktyget för QA-teamet för att vägleda projektets intressenter baserat på projektriskerna. RBT-tillvägagångssätt hjälper QA-teamet att kontinuerligt identifiera risker och dess lösning som kan äventyra uppnåendet av de övergripande projektmålen och hjälper till att uppnå det slutgiltiga målet för QA-gruppen.

P.S. Orden QA och Testing har använts utbytbart i hela dokumentet.

Om författaren: Denna artikel är skriven av flera STH-teammedlemmar - Gayathri Subrahmanyam och Swati S.

Gayathri är ett SME med mjukvarutest med 2+ decenniers erfarenhet av programvarutestning och har i stor utsträckning antagit ”riskbaserad testning” som en del av testindustriellisering i flera uppdrag och har insett fördelen med testresursoptimering och kvalitetstestning.

Var riskbaserad testning en utmanande för dig? Har du några intressanta fakta att lägga till i vår handledning? Känn dig fri att uttrycka dina tankar i kommentarfältet nedan !!

=> Besök här för en komplett testplan-handledningsserie

Rekommenderad läsning

• Kontinuerlig integrationsprocess: Hur man förbättrar programvarukvalitet och minskar risker
• Felläge och effektanalys (FMEA) - Hur man analyserar risker för bättre programvarukvalitet och nöjda kunder!
• Den ultimata guiden till riskbaserad testning: riskhantering vid programvarutestning
• Topp 10 Verktyg och tekniker för riskbedömning och hantering
• Typer av risker i programvaruprojekt
• Några intressanta frågor om mjukvarutestning
• Välja programvarutestning som din karriär
• Programvarutestning Feedback och recensioner