Den ultimative guide til risikobaseret test: risikostyring i softwaretest

ultimate guide risk based testing

Den ultimative guide til risikobaseret test, risikostyring og dens tilgang med eksempler:

Hvad er risikobaseret test?

Risikobaseret testning er at udføre test eller at designe og udføre scenarierne, således at de øverste forretningsrisici, der vil have en negativ indvirkning på forretningen, som de er identificeret af kunden, bliver fundet i deres produkt eller funktion tidligt i livscyklussen og er afbødes ved at gennemføre afbødende foranstaltninger.

=> Klik her for en komplet testplan-selvstudieserie

Den negative indvirkning kan omfatte omkostningspåvirkning, utilfreds kunde, dårlig brugeroplevelse og endda i det omfang, at kunderne mister.

Med andre ord er RBT-metoden at sikre, at test udføres på en sådan måde, at selvom en bruger finder en fejl i produktionen forhindrer det ikke ham / hende i at bruge softwaren eller påvirker ikke virksomheden på en seriøs måde.

RBT testes udført på baggrund af produktrisici. RBT skal finde ud af det i god tid, da det er risikoen for, at en bestemt funktion eller funktionalitet svigter i produktionen og dens indvirkning på forretningen med hensyn til omkostninger og andre skader ved at bruge en prioriteringsteknik til testsagerne.

Derfor bruger risikobaseret test princippet om prioritering af testene af funktionerne, modulerne og funktionerne i et produkt eller en software. Prioriteringen er baseret på risikoen for sandsynligheden for fiasko af den funktion eller funktionalitet i produktionen og dens indvirkning på kunderne.

Hvad du vil lære:

• Risikobaseret test og dens relevans for Agile & DevOps
  • Risikobaseret testmetode
    • Hvornår bruger vi RBT-metoden?
    • Eksempel på RBT-tilgang
  • Måder at udføre risikoanalyse på
  • Procedure for risikoanalyse
  • Metode til risikoanalyse
    • Trin # 1) Brug af et 3X3 gitter
    • Trin # 2) Sandsynlighed og virkning af fiasko
    • Trin # 3) Test af prioritetsgitter
    • Trin # 4) Detaljer om testning
  • Hvordan er RBT relevant for Agile og DevOps?
  • Fordele ved risikobaseret testmetode
• Risikostyring under testplanlægning
  • Risikostyringsproces
    • # 1) Risikoidentifikation
    • # 2) Risikovurdering / risikovirkningsanalyse
    • # 3) Risikoreduktion
  • Konklusion
• Risikostyring ved testudførelsesfase (med eksempel)
  • Risikostyring - med fokus på AUT
  • Hvordan foregår test af risikobaser?
  • Konklusion
  • Anbefalet læsning

Risikobaseret test og dens relevans for Agile & DevOps

Tre hundrede timer brugt på udvikling af software kan gøres ubrugelige på kun 30 sekunder med en enkelt defekt identificeret i produktionen.

Dette kan igen ødelægge formålet med hele produktet uden nogen anden mulighed end bare at trække det ud af markedet. Og det er betydningen og behovet for 'kvalitetstest'.

Med den hurtige vækst i teknologi hostes softwaren i skyen, der understøtter flere operativsystemer, flere platforme, komplekse IT-infrastrukturer osv., Slutbrugerne bliver mere og mere nøjeregnende med funktionerne, mulighederne og de går aldrig på kompromis for kundetilfredshed .

I dag er 'Kvalitet' ved at blive en afgørende faktor i softwarelevering, hvor der løbende forbedres for at forbedre kvaliteten for at holde kunderne glade.

Vi bemærker ofte, at det er et almindeligt problem for næsten alle testere at være under et enormt pres, at deres testvindue er presset, og typisk overføres bygningen til dem til test i sidste øjeblik. Der er ikke nok tid og ressourcer til, at de kan køre alle de tests, de har designet, og automatiseringsdækningen er ikke altid 100%, og den har sine egne udfordringer.

Leveringstidslinjen kan ikke gå glip af, og samtidig kan kvaliteten heller ikke kompromitteres. Uanset plan B, at tilføje yderligere testressourcer ved at trække sig ud fra de andre hold, ikke fungerer, Plan C, stoppe med at gøre alle de andre aktiviteter og omdirigere indsatsen til dette alene, hjælper ikke rigtig. Men meget tilføjelse af testressourcer til sidst ikke fungerer.

Der er ingen anden mulighed end bare at køre begrænsede og vigtige tests inden for den tilgængelige tid og ressourcer.

Så hvordan beslutter vi, hvilken test der er vigtig på dette stadium? Uanset hvad en tester anser for vigtig, er det måske ikke rigtig vigtigt for kunderne. Fra hvis perspektiv er vigtigheden af ​​funktionen eller en funktionalitet bestemt? Hvem bestemmer, hvilke vigtige tests der er? Og der opstår mange andre spørgsmål.

For at besvare alle disse spørgsmål og håndtere ovennævnte situation effektivt kaldes en testtilgang 'Risikobaseret test' , kort kaldet 'RBT' , opstod, hvor teamet tydeligt har planlagt og identificeret testscenarierne baseret på 'Project Risk' kriterierne.

Selvom QA-teamet har et klart billede af de vigtige tests, er RBT en gennemprøvet metode til at identificere de vigtige og vigtige tests fra kunde- og forretningsperspektiv gennem en 'Risikoanalyse' procedure .

Så i modsætning til den traditionelle måde at simpelthen identificere manglerne i softwaren på, har QA-tilgangen og målet ændret sig med tiden på grund af ændringen i teknologien, stigende konkurrence på markedet for at frigive en kvalitetssoftware, introduktion af 'Automatiser alt' og i sin helhed introduktion af Agile og DevOps praksis med at levere softwaren i løbet af få timer.

Derfor er den nuværende tendens med 'Testing Principle' ikke kun 'identificering af defekterne', men også

# 1) Fokuser på det område af produktet, hvor der er stor indflydelse på forretningen på grund af fiasko eller stor sandsynlighed for fiasko i produktionen.

#to) Med fokus på identificere manglerne tidligt og tillade et team at ordne det så tidligt som muligt og dermed lade softwaren / produktet eller funktionen gøre det 'Fejler hurtigt'.

# 3) Det vigtigste aspekt af QA-teamets service er nu at fokusere på kunden ved at skabe værdi for kunden ved at øge fokus på 'Ende til slut kundeoplevelse'.

Risikobaseret testmetode

Det er altid som at forberede sig til en undersøgelse, at man ikke kan sige, at test er nok, og der ikke er flere fejl i softwaren, selvom de designer og udfører et stort antal tests.

Der er et punkt, hvor softwarestabilitet ikke vil blive garanteret dobbelt ved at øge antallet af testtilfælde alene. På dette tidspunkt er det ikke kun at fokusere på antallet af tests, men på hvad kunden faktisk forventer af frigivelsen.

Derfor er det vigtigt at finde en balance i optimeringen af ​​testen for at opnå den maksimale fordel med den rimelige testindsats. Og dette er vigtigere, når testtidslinjerne er meget stramme, og der ikke er nok ressourcer til rådighed til at udføre tilstrækkelig test.

I dette tilfælde spiller RBT-tilgangen således en nøglerolle i optimeringen af ​​QA-indsatsen og maksimering af testfordelen med den minimale forretningsrisiko.

Så hvis vi fokuserer på ovenstående aspekt, vil arbejdet med en QA blive meget lettet. De behøver ikke at brænde deres weekender på kontoret, løbende teste softwaren og blive bekymrede over alle S4 (Severity 4) og P4 (Priority 4) defekter, der kommer ud af testen.

Nå betragtes 4 som den laveste prioritet og sværhedsgrad af defekterne ved testning. De kan bedre investere deres tid i andre nyttige aspekter af projektet.

For at opsummere de vigtigste drivkræfter for den 'risikobaserede testning' tilgang:

• For at muliggøre test af 'hvad kunder ønsker' ud fra et forretningsperspektiv.
• At opfylde tidsplanen med forventet kvalitet.
• For at optimere QA-indsatsen.

Hvornår bruger vi RBT-metoden?

Dette bruges under nedenstående scenarier:

• RBT-tilgang kan bruges, når der er en begrænsning eller begrænsning af projektets tid, omkostninger og ressourcer, og når der er behov for at optimere ressourcerne.
• RBT-tilgang bruges, når programmet er mere komplekst og tilpasser ny teknologi og dermed indebærer en masse udfordringer.
• Når programmet er et F & U-projekt, og det er af en første type, og der er en række ukendte og risici i projektet.

Eksempel på RBT-tilgang

Flere risikobaserede analysemetoder anvendes i it-branchen til at overvinde de risici, som produktionen står over for, og dens indvirkning.

Nedenfor er en sådan tilgang:

Denne tilgang til RBT inkluderer identifikation af 'Vital Functionalities eller Key Features' af produktet og vurdering af de risici, som hver af disse funktionaliteter udsættes for i produktionen, og implementering af passende afbødningsforanstaltninger på plads for at mindske eller mindske risikoen.

Derfor inkluderer RBT-metoden test af funktionaliteter, der har sandsynligheden for fiasko og den største indvirkning på virksomheden. Typerne af fejl kan være operationelle eller forretningsmæssige, tekniske, eksterne osv.

Måder at udføre risikoanalyse på

Der er ingen standardproces eller skabelon defineret som sådan til at udføre risikoanalysen i softwaretest for hver eneste funktion af et produkt. Forskellige organisationer bruger deres egen tilgang til risikoanalysemetoder.

Risikoanalyse kan udføres på forskellige projektelementer for at identificere risiciene og implementere en RBT-tilgang til analyse. Disse emner inkluderer,

• Funktioner
• Funktioner
• Brugerhistorier
• Krav
• Brug sager
• Test tilfælde

Lad os i dette tilfælde kun fokusere på testsager for at forstå implementeringen af ​​risikobaseret testning.

Procedure for risikoanalyse

Risikoanalyse inkluderer involvering af relevante interessenter i programmet fra både Teknisk team og forretningsteam ' , som inkluderer, Ejer af produktet, Produktledere, Forretningsanalytikere, Arkitekter, Testere og Kundepræsentanter.

Brainstorming-sessioner, der involverer disse interessenter, vil blive arrangeret for at gennemføre diskussionen for at identificere vigtigheden af ​​hver funktion af et produkt og prioritere dem baseret på risikoen for fiasko og dets indvirkning på slutbrugerne i produktionen.

Forskellige 'projektdokumenter' såsom kravsdokument, tekniske specifikationsdokumenter, arkitekturdokumenter og designdokumenter, forretningsprocesdokument, brugssagdokument osv. Bliver input til brainstormingssessionen.

Interessentens viden om produktet og det eksisterende produkt på markedet vil også være en inputfaktor for diskussionen.

Få andre kilder til input kan også omfatte,

• At samle input om den mest anvendte funktionalitet.
• Indgange fra høring af en domæneekspert.
• Data fra den tidligere version af produktet eller lignende produkt på markedet.

Under brainstorming session identificeres risikoen for hver af disse funktioner. Typerne af risici kan være en operation, teknisk eller forretningsrelateret. Testene og scenarierne i forbindelse hermed vægtes, og risikoværdier vurderes ud fra sandsynligheden for, at der opstår risiko og risikoen.

'Sandsynligheden for risikohændelse' kan skyldes:

• Produktudviklingsteamets dårlige forståelse af funktionen.
• Forkert arkitektur og design.
• Utilstrækkelig tid til at designe.
• Holdets inhabilitet.
• Utilstrækkelige ressourcer - mennesker, værktøjer og teknologi.

'Risikovirkningen' er virkningen af, at brugerne og virksomheden svigter, hvis den opstår. Virkningen kan være,

• Omkostningseffekt, hvilket resulterer i et tab.
• Virksomhedspåvirkning, der resulterer i tab af forretning eller tab af markedsandel, retssag, tab af licens
• Kvalitetspåvirkning, hvilket resulterer i en substandard eller inkompetent frigivelse af produktet.
• Dårlig brugeroplevelse, hvilket resulterer i utilfreds og tab af en kunde.

Fokusområdet for vurdering af risikoen ved en funktion eller et produkt kan være,

• Område med forretningskritisk funktionalitet.
• Mest anvendte funktioner og vigtig funktionalitet.
• Defekte udsatte områder
• Funktionalitet med sikkerheds- og sikkerhedspåvirkninger.
• Område med kompleks design og arkitektur.
• Ændringer foretaget fra tidligere versioner.

Metode til risikoanalyse

Lad os forstå den 'risikobaserede testmetode' i detaljer nu.

Den risikobaserede testmetode bruger RISK som kriterier i alle testfaser af testcyklussen, dvs. testplanlægning , test design, test implementering, testudførelse og testrapportering. Ideelt set kan man designe et stort antal mulige kombinationer af testscenarier.

Derfor inkluderer RBT-metoden en rangordning af testene baseret på sværhedsgraden af ​​risiciene for at finde ud af det mest defekte eller risikable svigtområde, hvilket medfører stor indflydelse på virksomheden.

Hovedformålet med risikoanalyse er at skelne mellem 'Høj værdi' emner som produktfunktioner, funktionaliteter, krav, brugerhistorier , og testsager, og ' Lav værdi ' dem og dermed senere til mere fokus på 'Høj værdi' test tilfælde ved mindre fokus på 'lave værdi' test tilfælde. Dette er det indledende trin i risikoanalysen, inden den risikobaserede test påbegyndes.

Hovedopgaven med kategorisering eller gruppering af testsager i høj værdi og lav værdi og tildeling af prioritetsværdien til hver af disse testsager inkluderer følgende trin:

Trin # 1) Brug af et 3X3 gitter

Risikoanalyse udføres ved hjælp af et 3X3-gitter, hvor hver funktionalitet, ikke-funktionalitet og dens relaterede testsager vurderes af et team af interessenter for dets 'Sandsynlighedaf fiasko 'og' virkning af fiasko '.

Sandsynligheden for fiasko for hver funktionalitet i produktionen er normalt tilgængelig af en gruppe af 'tekniske eksperter' og er kategoriseret som 'sandsynligvis mislykkes, ganske sandsynligt og usandsynligt' langs gitterets lodrette akse.

hvordan man finder netværkssikkerhedsnøgle på Windows 10

Tilsvarende oplever slutkundens 'virkningen af ​​fiasko' af disse funktioner og funktionaliteter i produktionen, hvis den ikke testes vurderes af en gruppe af '' Forretningsspecialister ”og er kategoriseret under kategorierne“ Mindre, synlige og afbrydelser ”langs den vandrette akse i nettet.

Trin # 2) Sandsynlighed og virkning af fiasko

Alle testsagerne er placeret i kvadranterne i 3 X 3-gitteret baseret på de identificerede værdier for sandsynligheden for fiasko og virkningen af ​​fiasko, som vises som prikker i billedet nedenfor.

Det er åbenbart, at høj sandsynlighed for fiasko og stor indvirkning på fiasko (afbrydelse) er grupperet i øverste højre hjørne af nettet, hvilket er af stor betydning, og det identificeres derfor, at 'High Value' test og 'Low Value' tests er grupperet i nederste venstre hjørne, der har mindst eller ingen betydning for kunden, hvor der kan gives mindre fokus på disse funktioner eller testsager.

Trin # 3) Test af prioritetsgitter

Baseret på ovenstående placering af testsagerne i nettet prioriteres og mærkes testene med prioriteterne 1,2,3,4 og 5 og markeres mod hver af dem. De vigtigste tests er placeret i en 1^St.gitter, der er tildelt prioritet 1, og tilsvarende mindre vigtige rangeres som 2, 3, 4 og 5.

Endelig sorteres alle testsagerne efter deres prioritetsnumre og afhentes til udførelse i prioritetsrækkefølgen. De med høj prioritet afhentes til udførelse først, og de med lav prioritet udføres enten senere eller fjernes.

Trin # 4) Detaljer om testning

Det næste trin er at beslutte niveauet for detaljer i test for det definerede testomfang. Dybden af ​​testens omfang kan bestemmes på baggrund af ovenstående placering i henhold til nedenstående gitter.

Test med høj prioritet med rang 1 testes 'Mere grundigt', og derfor implementeres eksperter for at teste disse funktioner med høj kritisk betydning og dens relaterede testtilfælde. Test ligeledes sager med prioritet 2, 3 og 4. Der kan træffes en beslutning om at afvænke prioritet 5-funktioner og test baseret på den tilgængelige tid og ressourcer.

Derfor hjælper niveauet for testning af testmetoden med at prioritere funktionerne og dens testtilfælde ikke kun testere til at identificere 'højværdistests', men guider dem også til at beslutte deres 'detaljerede testniveau' baseret på disse prioriterede placeringer og hjælper dem med at udføre bedre test og reducerer testomkostningerne ved optimeringsprocessen.

Hvordan er RBT relevant for Agile og DevOps?

Efter at have forstået den risikobaserede testtilgang til at udføre testene baseret på prioriteringen af ​​test afhængigt af 'risikoen for fiasko' af en bestemt funktion og dens 'indvirkning på kunden' i live, ville man naturligvis rejse spørgsmålet om relevansen af ​​risikobaseret testmetode i Agile og DevOps-praksis.

'Automatiser alt', 'Test alt', 'Test kontinuerligt', 'Test gentagne gange' er nøglebegreberne i denne praksis.

Hver gang, når der sker en ændring i koden, eller der er en frigivelse, køres alle de designede tests gennem den automatiserede Kontinuerlig integration (CI) / Kontinuerlig levering (CD) pipeline hurtigt og gentagne gange, uanset deres prioritering.

Hvad er så forholdet mellem RBT og DevOps? Hvor ville RBT passe ind og blive relevant i Agile og DevOps ???

# 1) Ja, som jeg sagde tidligere, er det ikke, at hver branche og hvert produkt har 100% automatiseringsdækning til deres testudførelser. Så hvis teamet overhovedet skal træffe valget mellem prioritering til testudførelse ud fra valget af manuelle testtilfælde og gerne vil spare energi og kræfter fra testressourcerne mod andre aktiviteter, så er RBT det bedste valg.

Den risikobaserede tilgang er også en bedre indsats for at køre automatiske tests med højprioriterede og tidligst teste.

#to) QA-teamet kan anvende RBT-metoden mere effektivt under kravanalysen ved at analysere kravene og levere en forhåndsrapport om de sandsynlige risici ved produkterne og funktionerne, således at passende handlinger kunne træffes proaktivt af programteamet for at afbøde det.

# 3) RBT-tilgang kan bruges effektivt til at designe testtilfælde og scenarier baseret på høj risiko, så der kan lægges mere fokus på højrisikofunktioner og -funktioner.

# 4) Identifikation af 'High Risk' områder gør det muligt for QA-teamet at fokusere deres testindsats på disse områder for at teste 'mere grundigt' ved hjælp af 'High Skilled Testers'.

# 5) 'Fail Fast', som vi alle ved, er begrebet 'Agile' og 'DevOps', for hvilken RBT-tilgang hjælper med at identificere 'højrisiko'-områderne i softwaren, identificere defekterne tidligt og lade dem mislykkes hurtigt og fejler først og lad holdet ordne det.

# 6) Det ultimative mål for Agile / DevOps er 'Kundefokus', og dermed gør RBT-tilgangen, at QA kan fokusere på kundeoplevelse end blot at finde mangler.

Fordele ved risikobaseret testmetode

Vi har allerede forstået formålet med og brugen af ​​RBT-metoden til at analysere kravene, designe og udføre testscenarierne. Der er flere fordele ved RBT.

Vi kan konsolidere og liste fordelene ved risikobaseret test som:

• Hjælper med en mere effektiv og optimeret brug af testressourcer.
• Hjælper med at lette QA-arbejdet, test, testdesign og udvikling og testforberedelsesaktiviteter ved prioritering.
• Hjælper med bedre styring af QA-ressourcer ved at allokere nøgleressourcerne til områder med højt fokus.
• Det hjælper med effektiv udnyttelse af ressourcer og omdirigerer deres tid og energi på bedre ting i projektet.
• Hjælper QA-teamet med at planlægge testindsatsen baseret på risikovurderingen og identifikationen af ​​flygtige områder med høj risiko.
• Det hjælper holdet med at optimere de tests, der skal udføres afhængigt af vigtigheden og dermed afvænke test af lav værdi efter aftale med interessenterne.
• Samlet set hjælper det med omkostningsreduktion gennem optimerede og reducerede testaktiviteter.
• RBT-tilgang gør det muligt for QA-teamet at teste højrisikoområderne først og giver produktet mulighed for at 'fejle hurtigt' og rette hurtigt.
• RBT-tilgang hjælper med at bringe klarhed i ' Testdækning ' og 'Test Scope' til hele gruppen af ​​interessenter.
• Holdet kan øge deres fokus på højrisikoområder og holde mindre fokus på lavrisikoområdet.
• RBT giver teamet mulighed for at beslutte i god tid om implementeringen af ​​den mest effektive måde at afbøde for produktrisici på.
• RBT hjælper med at undgå effekten af ​​uhensigtsmæssig implementering af afbødninger.
• Risikobaseret test giver holdet mulighed for at tage passende skridt enten for at afbøde eller planlægge for beredskab eller placere enhver løsning for at overvinde fejlen eller reducere dens indvirkning, hvis risikoen opstår i Live.
• RBT hjælper med at minimere den resterende risiko i frigivelsen.
• Det hjælper med at opnå 'forbedret kvalitet' gennem billigere defekter i produktionen.
• Hjælper i sidste ende med 'Forbedret kundeoplevelse' og 'Tilfreds kunde'.

Derefter lærer vi, hvordan vi styrer risici i testplanlægning og testudførelsesfaser af softwaretestets livscyklus.

Risikostyring under testplanlægning

Sådan håndteres risici under testplanlægningsfasen:

Livet er fuld af risici, og det samme er et softwareprojekt. Alt kan gå galt når som helst. Vi er altid på tæerne for at gøre tingene rigtige - men hvad med at sikre, at intet går galt, og at når det ved, ved vi nøjagtigt hvad vi skal gøre? Indtast risikostyring - dette er en del af et softwaretestprojekt, der forbereder os på at forhindre, forstå, finde og komme over risici.

En risiko er simpelthen et problem, der sandsynligvis vil opstå, og når det sker, vil det medføre et tab.

Tabet kan være hvad som helst - penge, tid, kræfter eller et kompromis i kvalitet. Tabet er aldrig godt. Uanset hvor meget et spin vi giver det, er det ikke positivt - og vil aldrig være. Derfor Risikostyring er en integreret del af softwareprojekter for at sikre, at vi håndterer risici og forhindrer / reducerer tab.

Risikobaseret test : Da vi er et QA-samfund, skal vi udelukkende forblive specifikke for risici og processen relateret til det i vores QA-verden. Risici vurderes og håndteres omtrent i 2 faser af vores Software Test livscyklus . STLC kan kategoriseres i 3 faser - Testplanlægning, Testdesign og Testudførelse.

Risikostyringsprocessen forekommer to gange i løbet af:

1. Testplanlægning
2. Test sagsdesign (slut) eller undertiden i testudførelsesfasen

Det er obligatorisk i tilfælde 1, men i tilfælde 2 er det mere en ”behovsbaseret” situation.

To-delt artikelserie:

Selvom den underliggende proces er den samme, er typer risici behandlet i begge disse områder er helt forskellige. For at gøre retfærdighed over for dem individuelt vil vi håndtere dem forskelligt som en todelt serie.

Dette afsnit vil handle om “Risikostyring under testplanlægning”.

Risikostyringsproces

Den generiske proces for risikostyring involverer 3 vigtige faser:

1. Risikoidentifikation
2. Analyse af risikovirkninger
3. Risikoreduktion

Testrisici og dæmpende eksempler:

# 1) Risikoidentifikation

Som det siges, er det første skridt til at løse et problem at identificere det. Denne fase involverer at lave en liste over alt, hvad der potentielt kan komme op og forstyrre den normale strøm af begivenheder.

Hovedresultatet af dette trin er en liste over risici.

Dette risikobaserede testtrin ledes almindeligvis af QA lead / Manager / repræsentant. Imidlertid vil føringen alene ikke være i stand til at komme op med hele listen - hele QA-holdets input har en enorm indflydelse. Vi kan sige, at dette er en kollektiv aktivitet ledet af QA-ledelsen.

Også de risici, der identificeres under testplanlægningsfasen, er mere 'ledelsesmæssige' i orientering, hvilket betyder, vi vil se på alt, hvad der kan påvirke QA-projektets tidsplan, indsats, budget, ændringer i infrastruktur osv. Fokus her er ikke AUT, men hvordan QA-fasen fortsætter.

Risici under testplanlægning: Eksempler på risikobaseret test

Følgende er en stikliste over risici, der kan være opført under testplanlægningsfasen. Bemærk venligst, at AUT og dens funktionalitet ikke er i fokus her.

1. Testplanen er stram. Hvis testens start er forsinket på grund af designopgaver, kan testen ikke forlænges ud over den planlagte UAT-startdato.
2. Ikke nok ressourcer, ressourcer ombordstigning for sent (processen tager cirka 15 dage.)
3. Defekter findes i et sent stadium af cyklussen eller i en sen cyklus; mangler opdaget sent skyldes sandsynligvis uklare specifikationer og er tidskrævende at løse.
4. Omfang ikke defineret fuldstændigt defineret
5. Naturkatastrofer
6. Ikke-tilgængelighed af uafhængig Test miljø og tilgængelighed
7. Forsinket test på grund af nye problemer

På dette tidspunkt kan du vælge at være så grundig, som du vil, afhængigt af den tilgængelige tid.

Når alle risiciene er angivet, går vi videre til risikovurdering / risikokonsekvensanalyse.

# 2) Risikovurdering / risikovirkningsanalyse

Er din risikoanalyse noget lignende? :)

Risikoanalyse ved softwaretest : Alle risici kvantificeres og prioriteres i dette trin. Enhver risikos sandsynlighed (chancen for forekomst) og påvirkning (det tabsbeløb, som den ville medføre, når denne risiko realiseres) bestemmes systematisk.

Høj - medium-lav værdier tildeles både sandsynligheden og effekten af ​​hver risiko. Risikoen med “høj” sandsynlighed og “Høj” indvirkning håndteres først, og derefter følger rækkefølgen.

Risikokonsekvensanalysetabel:

Efter disse trin ser tabellen over risikovirkningsanalyse for de ovennævnte risici sådan ud (alle værdier er hypotetiske og kun til forståelsesformål):

# 3) Risikoreduktion

Det sidste trin i denne RBT-proces (Risk-Based Testing) er at finde løsninger til at planlægge, hvordan man håndterer hver af disse situationer. Disse planer kan variere fra virksomhed til virksomhed, projekt til projekt og endda person til person.

Risikoreducerende teknikker:

Her er et eksempel på, hvad risikotabellen forvandles til, når denne fase er afsluttet:

Et par punkter at bemærke:

1. Jo hurtigere risikostyring starter i en QA-projektplanlægningsfase, jo bedre.
2. Af alle 3 trin Risikoidentifikation er den vigtigste . Hvis noget ikke er opført og overvejes for yderligere trin, bliver risikoen uhåndteret.
3. Prøv at finde en ideel tidsramme til denne aktivitet. Husk, for meget planlægning giver for lidt tid til at gøre.
4. Risikostyringsplanen kan også efter risikostyringsprocessen ændres eller opdateres for at afspejle den mest aktuelle tilstand, hvis en ny situation opstår.
5. Historiske data kan være meget nyttigt for succesen med denne proces.

Konklusion

Dette bringer os til en afslutning af risikostyring i testplanlægningsfasen. Selvom de underliggende trin og principper er ens, er risikostyringsprocessen mere koncentreret mod AUT, når det sker i testdesign / udførelsesfasen.

I vores næste afsnit vil vi dække - Risikostyring i testudførelsesfasen.

Risikostyring ved testudførelsesfase (med eksempel)

I vores rejse til forståelse af risikostyringsprocessen talte vi om, hvordan det går udelukkende i Testplanlægningsfase af risikobaseret test . Vi forstod også den generiske proces, der involverer - risikoidentifikation, risikovurdering og risikobegrænsningsplan.

Sådan styres risiko ved testdesign eller testudførelsesfase:

Der er en anden form for Risikostyring (også undertiden omtalt som, Risikobaseret test ) der opstår under testdesignet eller testudførelsesfasen afhængigt af situationen. Hvilken situation taler vi nu om? Lad os prøve at forstå det først.

Vi ved alle, at vores testarbejde er reaktivt. Ingen krav (eller omfang defineret), vi kan ikke udføre en gennemførlighedsanalyse og skrive testscenarier eller planlægge testaktiviteter.

Når koden ikke er klar, har vi intet at teste, uanset hvor meget forarbejde vi måske har været klar inden for testsager, testdata osv. Testning er også det eneste trin, der er tilbage, før produktet går Direkte.

hvad er den bedste computerrenser gratis?

Risikostyring - med fokus på AUT

Lad os forstå dette bedre med et eksempel:

Hvis testen skulle begynde den nævnte dato, 1. jan^St.og måtte fortsætte indtil 14. januar^th- når testen er udført, fastlægges produktets Go-live-dato normalt med det samme. Lad os sige - 15. jan^thfor enkelhedens skyld. I perfekte verden ville tingene gå nøjagtigt som planlagt. Men vi kender alle virkeligheden.

Lad os i dette tilfælde antage, at testningen af ​​en eller anden grund ikke startede før 7. januar^th, hvilket betyder, at vi mistede halvdelen af ​​vores testtid. Men vi har brug for 14 dage til at teste produktet grundigt. Vi kunne flytte go-live-datoen længere med 7 dage - dog; dette er normalt ikke en mulighed. Fordi produktet er lovet at komme på markedet på en bestemt dato, og eventuelle forsinkelser ikke er gode for virksomheden.

Så som regel er vi testteam nødt til at absorbere forsinkelserne, kompensere på en eller anden måde, arbejde med den tilgængelige tid og sørge for, at produktet testes godt. Hårdt arbejde, er det ikke?

Det er her, Risikostyringsprocessen igen anvendes.

• Nu, hvis forsinkelser forventes på forhånd inden testningen begynder - processen finder sted i testdesignfasen.
• Hvis forsinkelser sker under en Testudførelsesfase der startede normalt - processen følges under testudførelsesfasen.
• Trinene og metoden er de samme, uanset hvilket stadium det sker.

Hvad er processen?

Risikostyring finder sted for at bestemme, hvilke områder af AUT (Application Under Test), der har brug for maksimalt fokus. Disse er typisk de funktionelle områder (moduler eller komponenter), der er kritiske for det endelige produkts succes og er mest tilbøjelige til at mislykkes.

Læs også=> Failure Mode And Effects Analysis (FMEA) er en risikostyringsteknik

Hvem udfører det?

Da det vedrører AUT, er viden om det ikke kun hos QA, men med alle de andre teams - Dev, BA, Client, Project management teams osv. Derfor er det en kollektiv indsats, drevet af testteamet.

Hvordan foregår test af risikobaser?

Trin 1) Risikoidentifikation

Identificer alle funktionelle områder i AUT. Dette inkluderer simpelthen at oprette en liste.

Trin 2) Risikovurdering

Alle risici kvantificeres og prioriteres i dette trin. Kvantificering er simpelthen at tildele et nummer til hver risiko på listen, der giver en indikation af den prioritet, som det skal adresseres med.

Enhver risikos sandsynlighed (chancen for forekomst) og indvirkning (det tabsbeløb, som den ville medføre, når denne risiko realiseres), afgøres.

Den typiske metode er at tildele ratings. For eksempel, Sandsynligheden kan tage værdierne 1 til 5. 1 er sandsynligheden for, at en forekomst er lav (sandsynligvis ikke sker overhovedet) og 5 er høj (vil helt sikkert ske).

På samme måde kan Impact også tildeles en 1-5 rating. 1 har lav indvirkning (selvom denne risiko virkeliggøres, er tabet minimal) og 5 er stor indvirkning (enorme tab, når der sker).

Trin # 3)

Lav et tabelformat og cirkuler til alle teamrepræsentanter - Dev, BA, Client, PM, QA og alle andre relevante.

Trin # 4)

Instruer hvert hold at udfylde værdierne baseret på deres vurdering for sandsynlighed og effekt.

Da sandsynligheds- og påvirkningsværdier er numeriske, vil det gøre beregningen af ​​”Risikofaktor” -værdien let.

Risikofaktor = Sandsynlighed X Virkning. Jo højere risikofaktoren er, jo alvorligere er problemet.

Et eksempel:

Bemærk, at dette på dette tidspunkt simpelthen er resultatet af et holds vurdering. For et projekt, hvor 5 forskellige hold er involveret, ender QA-teamet med 5 forskellige tabeller.

Trin # 5)

Tag et gennemsnit af risikofaktorværdierne. For eksempel, hvis der er 5 hold for hvert modul, tilføj alle risikofaktorværdierne og divider det med 5. Dette er de endelige værdier, vi skal håndtere. Sig, dette er de gennemsnitlige risikofaktorer:

Jo mere risikofaktoren er, desto mere skal modulet testes.

Så modul 5 og 2 er mest afgørende for forretningens succes. Del resultaterne med alle holdene.

Trin # 6)

Risikobegrænsende plan : Dette er det trin, der skifter fra projekt til projekt. Vi har identificeret, at modul 5 og 2 er dem, der skal koncentreres mest om.

Eksempleraf planen kunne være:

1. Modul 5 og 2 testes grundigt ved at sikre, at alle testtilfælde, der er relateret til dem, testes. De andre moduler vil blive testet på sonderende basis.
2. Modul 5 og 2 testes først, og afhængigt af den tilgængelige tid, bliver de andre taget hånd om.

Når en plan er lavet, når alle holdene til enighed og følger den for at teste produktet under hensyntagen til risikofaktoren.

Det er det!

Et par vigtige punkter at bemærke:

• Da dette er en kollektiv aktivitet, der tager alles mening i betragtning ; chancerne for, at det er nøjagtigt og effektivt, er højere.
• Dette er ikke en formel metode og behøver ikke at være en del af ethvert QA-projekt.
• Nogle gange, selvom holdet vælger ikke at tegne tabeller og tildele værdier- a simpel brainstorming med alle tilstedeværende kan give QA-teamet god vejledning i, hvordan man fortsætter.
• Det udviklingsteams input er meget vigtigt, fordi det er dem, der opretter produktet, så de ved, hvad der kan fungere, og hvad der muligvis har brug for yderligere kontrol. Sørg for at være på udkig efter det.
• Selvom der er flere trin i processen, det tager ikke lang tid at udføre dem . Især hvis alle holdene kan sidde sammen og arbejde samtidigt.
• Husk denne proces, og dens resultat er kun alternativet . At få så meget tid som planlagt til test er den bedste måde at udføre QA-aktiviteten på.

Konklusion

Den risikobaserede testtilgang indikerer klart, at testens fokus ikke kun er at fortsætte med at udforske manglerne uanset sværhedsgrad og prioritet. Nu er tingene ændret, og testere skal arbejde smart, og de skal forstå det klare 'Kundens behov og brugerens ønsker'.

De har brug for at studere produktet grundigt og forstå, hvilket er det hyppigst anvendte element i produktionen, hvilket er den mest kritiske vej til indtægtsgenerering, og hvordan man beskytter og beskytter kunderne mod produktionsproblemer og forretningstrusler.

Derfor uddanner RBT-metoden tydeligt de 3 testere, at bare at teste alt eller teste omfattende ikke betyder, at testen er komplet, eller at der ikke er nogen fejl i produktet. Test effektivt i en fastsat tid og sikre, at kritiske og større forretningspåvirkninger ophæves, og det er ret vigtigt for testeren.

Derfor er risikobaseret test det mest effektive værktøj for QA-teamet til at guide projektets interessenter baseret på projektrisiciene. RBT-tilgang hjælper QA-teamet med den løbende identifikation af risiko og dets opløsning, der kan true opnåelsen af ​​de overordnede projektmål og mål og hjælper med at nå QA-gruppens ultimative mål.

P.S. Ordene QA og Testing er blevet udskifteligt brugt i hele dokumentet.

Om forfatteren: Denne artikel er skrevet af flere STH-teammedlemmer - Gayathri Subrahmanyam og Swati S.

Gayathri er en SMV med softwaretest med mere end 2 årtiers erfaring inden for softwaretest og har i vid udstrækning anvendt tilgangen til 'risikobaseret test' som en del af testindustrialisering i flere opgaver og har indset fordelen ved testressourceoptimering og kvalitetstest.

Var risikobaseret test en udfordrende test for dig? Har du nogle interessante fakta at tilføje til vores tutorial? Du er velkommen til at udtrykke dine tanker i kommentarfeltet nedenfor !!

=> Besøg her for en komplet testplan-tutorial-serie

Anbefalet læsning

• Kontinuerlig integrationsproces: Sådan forbedres softwarekvaliteten og reducerer risikoen
• Fejltilstand og effektanalyse (FMEA) - Sådan analyseres risici for bedre softwarekvalitet og tilfredse kunder!
• Den ultimative guide til risikobaseret test: risikostyring i softwaretest
• Top 10 risikovurderings- og styringsværktøjer og teknikker
• Typer af risici i softwareprojekter
• Nogle interessante softwaretestinterviewspørgsmål
• Valg af softwaretest som din karriere
• Feedback og anmeldelser om softwaretestkursus