Risikobaseret test: tilgang, matrix, proces og eksempler

Risikobaseret test

Risikobaseret test (RBT) er en softwaretesttype, som er baseret på sandsynligheden for risiko. Det indebærer vurdering af risikoen baseret på softwarekompleksitet, forretningskriticitet, brugshyppighed, mulige områder med Defekt osv. Risikobaseret test prioriterer test af funktioner og funktioner i softwareapplikationen, som er mere virkningsfulde og sandsynligvis har defekter.

Risiko er forekomsten af en usikker begivenhed med en positiv eller negativ effekt på et projekts målbare succeskriterier. Det kan være begivenheder, der er sket i fortiden eller aktuelle begivenheder eller noget, der kunne ske i fremtiden. Disse usikre begivenheder kan have en indvirkning på omkostningerne, forretningsmæssige, tekniske og kvalitetsmæssige mål for et projekt.

Risici kan være positive eller negative.

Positive risici omtales som muligheder og hjælp til virksomhedens bæredygtighed. For eksempel investering i et nyt projekt, Ændring af forretningsprocesser, Udvikling af nye produkter.
Negative risici omtales som trusler, og anbefalinger til at minimere eller eliminere dem skal implementeres for projektets succes.

Hvornår skal man implementere risikobaseret test

Risikobaseret test kan implementeres i

Projekter med tids-, ressource-, budgetbegrænsninger osv.
Projekter hvor risikobaseret analyse kan bruges til at opdage sårbarheder til SQL-injektionsangreb.
Sikkerhedstest i cloud computing-miljøer.
Nye projekter med høje risikofaktorer som Manglende erfaring med de anvendte teknologier, Manglende viden om forretningsdomæne.
Inkrementelle og iterative modeller mv.

Risikostyringsproces

Lad os nu forstå de trin, der er involveret i risikostyringsprocessen

Risikoidentifikation

Risikoidentifikation kan ske gennem risikoworkshops, tjeklister, brainstorming, interviews, Delphi-teknik, årsags- og virkningsdiagrammer, erfaringer fra tidligere projekter, rodårsagsanalyse, kontakt til domæneeksperter og emneeksperter.

Risikoregister er et regneark, som har en liste over identificerede risici, potentielle reaktioner og grundlæggende årsager. Det bruges til at overvåge og spore risici (både trusler og muligheder) gennem hele projektets levetid. Risikoresponsstrategier kan bruges til at håndtere positive og negative risici.

Risikonedbrydningsstruktur spiller en vigtig rolle i risikoplanlægning. Risikoopdelingsstrukturen vil hjælpe med at identificere de risikoudsatte områder og hjælper med effektiv evaluering og risikoovervågning i løbet af projektet. Det hjælper med at give tilstrækkelig tid og ressourcer til risikostyringsaktiviteter. Det hjælper også med at kategorisere mange kilder, hvorfra projektrisici kan opstå.

Eksempel på risikoopdelingsstruktur

Risikoanalyse (omfatter kvantitativ og kvalitativ analyse)

Når listen over potentielle risici er blevet identificeret, er næste trin at analysere dem og filtrere risikoen ud fra betydningen. En af de kvalitative risikoanalyseteknikker er at bruge Risk Matrix (dækket i næste afsnit). Denne teknik bruges til at bestemme sandsynligheden for og virkningen af risikoen.

Risk Response planlægning

På baggrund af analysen kan vi afgøre, om risiciene kræver en reaktion. For eksempel vil nogle risici kræve et svar i projektplanen, mens nogle kræver et svar i projektovervågningen, og nogle vil slet ikke kræve noget svar.

Risikoejeren er ansvarlig for at identificere muligheder for at reducere sandsynligheden og virkningen af de tildelte risici.

Risikobegrænsning er en risikoresponsmetode, der bruges til at mindske de negative virkninger af mulige trusler. Dette kan gøres ved at eliminere risiciene eller reducere dem til et acceptabelt niveau.

Risikoberedskab

Beredskab kan beskrives som en mulighed for en usikker begivenhed, men påvirkningen er ukendt eller uforudsigelig. En beredskabsplan er også kendt som handlingsplanen/backup-planerne for de værst tænkelige scenarier. Med andre ord bestemmer det, hvilke skridt der kan tages, når en uforudsigelig begivenhed indtræffer.

Risikoovervågning og -kontrol

Risikokontrol og overvågningsproces bruges til at spore de identificerede risici, overvåge resterende risici, identificere nye risici, opdatere risikoregisteret, analysere årsagerne til ændringen, eksekvere risikoresponsplan og overvåge risikotriggere osv. Evaluer deres effektivitet med hensyn til at reducere risici. .

Dette kan opnås ved risikorevurderinger, risikorevisioner, varians- og trendanalyser, teknisk præstationsmåling, statusopdateringsmøder og retrospektive møder.

Tabellen nedenfor giver oplysninger om

Input til risikoovervågning og -kontrol	Værktøjer og teknikker til risikoovervågning og -kontrol	Output fra risikoovervågning og -kontrol
Risikostyringsplan	Projektrisikoreaktionsrevisioner	Løsningsplaner
Risikoresponsplan	Periodiske projektrisikovurderinger	Korrigerende handling
Projektkommunikationsplan	Optjent værdianalyse	Anmodninger om projektændringer
Yderligere risikoidentifikation og analyse	Teknisk præstationsmåling	Opdateringer af risikoresponsplanen og tjeklisten til risikoidentifikation
Omfangsændringer	Yderligere risikoberedskabsplanlægning	Risikodatabase

Vi skal huske, at risikoen stiger med ændringer i teknologien, projektets størrelse, projektets længde (Længere projekttidsramme), antallet af sponsorerende bureauer, projektestimater, indsats og mangel på passende færdigheder.

Risikobaseret testmetode

Analyser kravene.
Dokumenter (SRS, FRS, Usecases) gennemgås. Denne aktivitet udføres for at finde og eliminere fejl og uklarheder.
Kravafskrivning er en af de risikoreducerende teknikker til at undgå indførelse af sene ændringer i projekterne. Enhver ændring af krav, efter at dokumentet er baselinet, vil involvere en ændringskontrolproces og efterfølgende godkendelser.
Vurder risiciene ved at beregne sandsynligheden og indvirkningen, som hvert krav kan have på projektet under hensyntagen til de definerede kriterier såsom omkostninger, tidsplan, ressourcer, omfang, teknisk ydeevne, sikkerhed, pålidelighed, kompleksitet osv..
Identificer sandsynligheden for fejl og højrisikoområder. Dette kan gøres ved hjælp af risikovurderingsmatrix.
Brug et risikoregister til at liste de identificerede risici. Opdater, overvåg og spor risici med jævne mellemrum.
Risikoprofilering skal udføres på dette stadium for at forstå risikokapaciteten og risikotoleranceniveauerne.
Prioriter kravene ud fra vurderingen.
Risikobaseret testproces er defineret
Meget kritiske og mellemstore risici kan tages i betragtning til afbødningsplanlægning, implementering og fremskridtsovervågning. Lav risiko kan overvejes på en overvågningsliste.
Kvalitetsvurdering af risikodata foretages for at analysere kvaliteten af dataene.
Planlæg og definer test i henhold til bedømmelsen
Anvend passende testmetoder og testdesignteknikker til at designe testcaserne på en måde, så emnerne med den højeste risiko testes først. Produkter med høj risiko kan testes af ressourcen med god domænekendskabserfaring.
Forskellige testdesignteknikker kan bruges til f.eks. at bruge beslutningstabelteknikken på testelementer med høj risiko og "kun" ækvivalensopdeling til testelementer med lav risiko.
Testcases er også designet til at dække flere funktionaliteter og forretningsscenarier fra ende til ende.
Forbered testdata og testbetingelser og testleje.
Revse testplanerne, teststrategien, testsager, testrapporter eller ethvert andet dokument, der er oprettet af testteamet.
Peer review er et vigtigt skridt i defektidentifikation og risikoreduktion.
Udfør tørkørsler og kvalitetstjek af resultaterne
Testcases udføres i henhold til risikopostens prioritet.
Oprethold sporbarhed mellem risikoelementer, test, der dækker dem, resultater af disse tests og defekter fundet under test. Alle teststrategier, der udføres korrekt, vil reducere kvalitetsrisici.
Risikobaseret test kan bruges på alle testniveauer, f.eks. komponent-, integrations-, system- og accepttest
På systemniveau skal vi fokusere på, hvad der er vigtigst i ansøgningen. Dette kan bestemmes ved at se på funktionernes synlighed, på hyppigheden af brug og på de mulige omkostninger ved fejl.
Evaluering af exitkriterier. Alle højrisikoområder er fuldt testet, med kun mindre resterende risici udestående.
Risikobaseret testresultatrapportering og metrikanalyse.
Revurder eksisterende risikohændelser og nye risikohændelser baseret på Key Risk Indicators.
Opdatering af risikoregister.
Beredskabsplaner- Dette fungerer som en reserveplan/nødplaner for de høje eksponeringsrisici.
Fejlanalyse og fejlforebyggelse for at eliminere defekterne.
Gentestning og regressionstest for at validere fejlrettelserne baseret på forudberegnet risikoanalyse og højrisikoområder bør dækkes mest intensivt.
Risikobaseret automatiseringstest (hvis det er muligt)
Restrisikoberegning
Risikoovervågning og -kontrol
Udgangskriterier eller gennemførelseskriterier kan bruges til forskellige risikoniveauer. Alle nøglerisici er blevet behandlet med passende handlinger eller beredskabsplaner. Risikoeksponering er på eller under det niveau, der er aftalt som acceptabelt for projektet.
Revurdering af risikoprofilering og kundefeedback.

Risikobaseret testmetode til systemtesten

Teknisk systemtest – Dette kaldes miljøtest og integrationstest. Miljøtest omfatter test i udvikling, test og produktionsmiljø.
Test af funktionelt system– Test af alle funktioner, funktioner, programmer, moduler. Formålet med denne test er at vurdere, om systemet opfylder de specificerede krav.
Ikke-funktionel systemtest-Test af ikke-funktionelle krav ydeevne, belastningstest, stresstest, konfigurationstest, sikkerhedstest, backup og gendannelsesprocedurer og dokumentation (system, drift og installationsdokumentation).

Nedenstående diagram giver et klart overblik over ovennævnte proces

Systemtest omfatter både funktionelle tests såvel som ikke-funktionelle tests.

Funktionstest sikrer, at produktet/applikationen lever op til kundernes og virksomhedens krav. På den anden side udføres ikke-funktionel test for at verificere, om produktet lever op til kundens forventninger med hensyn til kvalitet, pålidelighed, anvendelighed, ydeevne, kompatibilitet osv.

Sådan laver du risikobaseret test: Fuldstændig proces

Dette afsnit dækker, Risikobaseret testproces

Risikoidentifikation
Risikoanalyse
Risikoreaktion
Test Scoping
Testproces definition

I denne proces identificeres og kategoriseres risici, udarbejdes et udkast til register over risici, risikosortering foretages for at identificere de væsentlige risici.
Risikorespons involverer at formulere testmålene ud fra risici og udvælge passende teknikker til at demonstrere testaktiviteten/testteknikken for at opfylde testmålene.
Dokumentafhængigheder, krav, omkostninger, tid, der kræves til softwaretest osv., anses for at beregne testens effektivitetsscore.
Testomfang er en gennemgangsaktivitet, der kræver deltagelse af alle interessenter og teknisk personale. Det er vigtigt at overholde det aftalte omfang af risici. Disse risici skal håndteres ved test, og alle medlemmer er enige i det ansvar, de er tildelt, og det budget, der er afsat til disse aktiviteter.
Efter at omfanget af testen er blevet afsluttet, skal testmålene, antagelserne og afhængighederne for hver testfase kompileres i standardformatet.

Lad os overveje de funktionelle krav F1, F2, F3 og ikke-funktionelle krav N1 & N2

F1-Funktionelt krav, R1-Risiko forbundet med F1

Testmål 1- Demonstrere ved hjælp af en test, at de forventede funktioner og funktionaliteter i systemet fungerer fint, og risikoen R1 kan adresseres ved funktionel test
Test-Browsersidetest udføres for at udføre vigtige brugeropgaver og verificere, at R1 (risiko forbundet med F1) kan løses i en række scenarier.

F2-Funktionelt krav, R2-Risiko forbundet med F2

Testmål 2- Demonstrere ved hjælp af en Test at systemets forventede funktioner og funktionaliteter fungerer fint, og risikoen R2 kan imødegås ved funktionel testning
Test-Browsersidetest udføres for at udføre vigtige brugeropgaver og verificere, at R2 kan løses i en række scenarier

F3-Funktionelt krav, R3-Risiko forbundet med F3

Testmål 3- Demonstrere ved hjælp af en Test at systemets forventede funktioner og funktionaliteter fungerer fint, og risikoen R3 kan imødegås ved funktionel testning
Test-Browsersidetest udføres for at udføre vigtige brugeropgaver og verificere, at R3 kan løses i en række scenarier

N1- Ikke-funktionelt krav, NR1-Risiko forbundet med N1

Testmål N1-Demonstrere ved hjælp af en Test at systemets operationelle karakteristika fungerer fint, og risikoen NR1 kan imødegås ved ikke-funktionel test
Test- Brugervenlighedstest er en teknik, der bruges til at vurdere, hvor lette brugergrænseflader er at bruge og verificere, at NR1 kan løses ved hjælp af usability test

N2- Ikke-funktionelt krav, NR2-Risiko forbundet med N2

Testmål N.2- Demonstrere ved hjælp af en test, at systemets operationelle karakteristika fungerer fint, og at risikoen NR2 kan løses ved ikke-funktionel test
Test-sikkerhedstest er en teknik, der bruges til at kontrollere, om applikationen er sikret eller sårbar over for angreb, om der er nogen informationslækage og verificerer, at NR2 kunne løses ved sikkerhedstest.

Specifikke testmål: De anførte risici og testmål er specifikke for testtyperne.

Procedure til at designe den risikobaserede testproces

Udarbejd et risikoregister. Dette registrerer de risici, der stammer fra generisk risikoliste, eksisterende tjekliste, brainstorming.
Inkluder de risici, der er forbundet med systemets funktionelle og ikke-funktionelle krav (brugervenlighed, sikkerhed, ydeevne)
Hver risiko tildeles en unik identifikator

Col No.	Kolonneoverskrift	Description
3	Sandsynlighed	Sandsynligheden for, at systemet er tilbøjeligt til denne fejltilstand
4	Konsekvenser	virkningen af denne fejlmetode
5	Eksponering	Produkt af sandsynlighed og konsekvenser (kolonne 3 og 4)
6	Test effektivitet	Hvor sikre er testerne på, at de kan håndtere denne risiko?
7	Testprioritetsnummer	Produkt af sandsynlighed, konsekvenser og testeffektivitet (kolonne 3,4 6)
8	Testmål	hvilket testmål vil blive brugt til at imødegå denne risiko
9	Test teknikker	hvilken metode eller teknik bruges til
10	Afhængigheder	Hvad antager og er testerne afhængige af
11	Indsats	Hvor meget indsats kræves der til denne test
12	Tidshorisont	Hvor meget tid kræves der for at udføre denne test
13	Testtrin A-Enhed TestsTest fase B-Integration TestTest Trin C-System Test	Navnet på den person eller gruppe, der udfører denne aktivitet

Sandsynligheden (1 lav -5 høj) og konsekvenserne (1 lav -5 høj) for hver risiko vurderes

Testeksponeringen beregnes
Testeren analyserer hver risiko og vurderer, om risikoen er testbar eller ej
Testmål er defineret for de testbare risici
Tester specificerer testaktiviteten, der skal udføres på en planlagt måde for at opfylde testmålet (statiske gennemgange, inspektioner, systemtest, integrationstest, accepttest, html-validering, lokaliseringstest osv.,)
Disse testaktiviteter kan klassificeres i faser (komponenttest/Enhedstest, Integrationstest, Systemtest, Accepttest)
Til tider kan en risiko håndteres af en eller flere testfaser
Identificer afhængighederne og antagelserne (tilgængelighed af færdigheder, værktøjer, testmiljøer, ressourcer)
Testens effektivitet beregnes. Testeffektivitet relaterer sig til testerens sikkerhed for, at risikoen vil blive endegyldigt behandlet gennem test. Testeffektivitetsscore er et tal mellem et og fem.(5-Høj selvtillid, 1-Lav selvtillid)
Estimat for indsatsen, den nødvendige tid, omkostningerne til at forberede og udføre disse tests.

Testprioritetsnummer beregnes. Det er et produkt af sandsynlighed, konsekvenser og testeffektivitetsscore.
- 125-MaximumàEn meget alvorlig risiko, der kunne opdages med testning
- 1-Minimum àEn meget lav risiko, der ikke ville blive opdaget med test
Baseret på testprioritetsnummeret kan testens betydning klassificeres som Høj (rød), Medium (Gul) & Lav (grøn). Produkter med høj risiko testes først.
Tildel testaktiviteterne til teststadierne. Udpeg den gruppe, der skal udføre test for hvert mål i de forskellige teststadier (enhedstest, integrationstest, systemtest, accepttest)
Hvad der er i scope og uden for scope for test afgøres i test scoping-fasen
For hvert trins testmål defineres komponent under test, ansvar, miljø, adgangskriterier, exitkriterier, værktøjer, teknikker, leverancer.

Generiske testmål - Disse generiske mål gælder for flere projekter og applikationer

Komponent opfylder kravet og er klar til brug i større delsystemer
De risici, der er forbundet med de specifikke testtyper, behandles, og testmålene nås.
Integrerede komponenter er korrekt samlet. Sørg for kompatibilitet mellem komponenterne.
Systemet opfylder de specificerede funktionelle og ikke-funktionelle krav.
Produktkomponenter opfylder slutbrugernes behov i deres tilsigtede driftsmiljø
Risikostyringsstrategi bruges til at identificere, analysere og afbøde risici.
Systemet opfylder industriens krav
Systemet opfylder kontraktlige forpligtelser
Institutionalisering og opnåelse af andre specifikke fastsatte mål, såsom omkostninger, tidsplan og kvalitetsmål.
System, processer og mennesker opfylder forretningskrav

Generiske testmål kan defineres for de forskellige teststadier

Komponenttestning
Integrationstest
Systemtest
Acceptantestning

Lad os overveje systemteststadiet

G4 & G5 viser, at systemet opfylder de funktionelle (F1,F2,F3) og ikke-funktionelle krav (N1,N2).
Demonstrer ved hjælp af test, at de forventede funktioner og funktionaliteter i systemet fungerer fint, og at risikoen forbundet med F1, F2, F3 kan løses ved funktionel test
Demonstrer ved hjælp af test, at systemets operationelle egenskaber fungerer fint, og at risikoen forbundet med N1, N2 kan adresseres ved ikke-funktionel test
Baseret på testprioritetsnummeret kan testens betydning klassificeres som Høj (rød), Medium (Gul) & Lav (grøn).

Prioriterings- og risikovurderingsmatrix

Risikovurderingsmatrix er sandsynlighedspåvirkningsmatrixen. Det giver projektteamet et hurtigt overblik over risiciene og den prioritet, som hver af disse risici skal håndteres med.

Risk rating = Probability x Severity

Sandsynlighed er et mål for chancen for, at en usikker begivenhed indtræffer. Eksponering i form af tid, nærhed og gentagelse. Det er udtrykt i procent.

Dette kan klassificeres som Hyppig(A), Sandsynlig(B), Lejlighedsvis(C), Fjernbetjening(D), Usandsynlig(E), Elimineret(F)

Hyppig- Det forventes at forekomme flere gange i de fleste tilfælde (91 – 100 %)
Sandsynlig: Forekommer sandsynligvis flere gange i de fleste tilfælde (61 – 90 %)
Lejlighedsvis: Kan forekomme engang (41 – 60 %)
Fjernbetjening – Det er usandsynligt/kan forekomme på et tidspunkt (11 – 40 %)
Usandsynligt-kan forekomme i sjældne og ekstraordinære omstændigheder (0-10%)
Eliminer - Umuligt at forekomme (0%)

Alvorlighed er graden af påvirkning af skade eller tab forårsaget på grund af den usikre begivenhed. Scorede 1 til 4 og kan klassificeres som Katastrofal = 1, Kritisk = 2, Marginal = 3, Ubetydelig = 4

katastrofale – Barske konsekvenser, der gør projektet fuldstændig uproduktivt og endda kan føre til projektnedlukning. Dette skal være en topprioritet under risikostyring.
Kritisk– Store konsekvenser, som kan føre til store tab. Projektet er alvorligt truet.
Marginal – Kortsigtede skader, der stadig kan reverseres gennem restaureringsaktiviteter.
ubetydelig– Lille eller minimal skade eller tab. Dette kan overvåges og styres af rutineprocedurer.

Prioriteten er klassificeret i fire kategorier, som er kortlagt mod sværhedsgraden og sandsynligheden for risikoen som vist på billedet nedenfor.

Alvorlig
Høj
Medium
Lav

Alvorlig: De risici, der falder ind under denne kategori, er markeret med ravfarvet. Aktiviteten skal stoppes, og der skal straks sættes ind for at isolere risikoen. Effektive kontroller skal identificeres og implementeres. Endvidere må aktiviteten ikke fortsætte, medmindre risikoen er reduceret til et lavt eller middel niveau.

Høj: De risici, der falder ind under denne kategori, er markeret med rød farvet handling eller risikostyringsstrategier. Der skal træffes øjeblikkelige foranstaltninger for at isolere, eliminere, erstatte risikoen og implementere effektive risikokontroller. Hvis disse problemer ikke kan løses med det samme, skal der defineres strenge tidslinjer for at løse disse problemer.

Medium: De risici, der falder ind under denne kategori, er markeret med gul farve. Der skal tages rimelige og praktiske foranstaltninger for at minimere risiciene.

Lav: De risici, der falder ind under denne kategori, er markeret med grøn farve), kan ignoreres, da de normalt ikke udgør noget væsentligt problem. Periodisk gennemgang er et must for at sikre, at kontrollerne forbliver effektive

Generisk tjekliste for risikobaseret test

Omfattende liste over vigtige punkter, der skal overvejes i risikobaseret test

Vigtige funktioner i projektet.
Brugersynlig funktionalitet i projektet
Den funktionalitet, der har den største sikkerhedspåvirkning
Funktioner, der har størst økonomisk indvirkning på brugerne
Meget komplekse områder med kildekode og fejludsatte koder
Funktioner eller funktioner, der kan testes tidligt i udviklingscyklussen.
Funktioner eller funktioner blev føjet til produktdesignet i det sidste minut.
Kritiske faktorer for lignende/relaterede tidligere projekter, der forårsagede problemer/problemer.
Primære faktorer eller problemer med lignende/relaterede projekter, som havde en enorm indflydelse på drifts- og vedligeholdelsesudgifterne.
Dårlige krav, der fører til dårlige designs og tests, der kan have indflydelse på projektets mål og leverancer.
I værste fald kan et produkt være så defekt, at det ikke kan omarbejdes og skal kasseres fuldstændigt, hvilket ville medføre alvorlig skade på virksomhedens omdømme. Identificer, hvilken slags problemer der er afgørende for produktmålene.
Situationer eller problemer, der ville forårsage vedvarende kundeserviceklager.
Slut-til-ende-tests kunne nemt fokusere på systemets mange funktioner.
Optimalt sæt af test, der kan maksimere risikodækningen
Hvilke test vil have det bedste forhold mellem højrisikodækning og tidskrævet?

Rapportering og målinger af risikobaserede testresultater

Testrapport forberedelseRapportering af teststatus handler om effektivt at kommunikere testresultaterne til projektets interessenter. Og for at give en klar forståelse og vise sammenligning af testresultater med testmål.

Antal planlagte testsager vs. udførte
Antal beståede/ikke beståede testsager
Antal identificerede defekter og deres status og alvor
Antal defekter og deres status
Antal kritiske defekter - stadig åben
Nedetider i miljøet – hvis nogen
Showstoppers – hvis nogen Testoversigtsrapport, testdækningsrapport

Forberedelse af metrikMetrics er en kombination af to eller flere mål, der bruges til at sammenligne softwareprocesser, -projekter og -produkter.
- Indsats og tidsplan variation
- Test Case Preparation Produktivitet
- Test designdækning
- Produktivitet for udførelse af testcase
- Risikoidentifikationseffektivitet %
- Risikobegrænsende effektivitet %
- Test effektivitet %
- Dækning for testudførelse
- Testudførelsesproduktivitet
- Defekt lækage %
- Effektivitet på detektering af fejl
- Krav stabilitetsindeks
- Omkostninger ved kvalitet

Analyser risici i ikke-funktionelle kategorier (ydeevne, pålidelighed og brugervenlighed) baseret på defektstatus og en række test bestået/ikke bestået status, baseret på deres forhold til risici.
Analyser risiciene i funktionelle kategorier målinger af test, defekt status og test bestået/ikke bestået status, baseret på deres forhold til risici.
Identificer vigtige lead- og lagindikatorer, og opret tidlige advarselsindikatorer
Overvåg og rapporter om lead- og lagrisikoindikatorer (Key Risk Indicators) ved at analysere datamønstre, tendenser og indbyrdes afhængighed.

Iboende risiko vs. resterende risikovurdering

Risikoidentifikation og -analyse bør også omfatte iboende risici, resterende risici, sekundære risici og tilbagevendende risici

Iboende risiko: De risici, der var identificeret/allerede til stede i systemet, før kontrollerne og reaktionerne blev implementeret. Iboende risici er også kendt som brutto risici
Restrisiko: De risici, der er tilovers, efter at kontrollerne og reaktionerne er implementeret. Restrisici er kendt som nettorisici
Sekundær risiko: Den nye risiko forårsaget af implementeringen af risikoberedskabsplanen
Tilbagevendende risici: Sandsynlighed for, at de indledende risici vil opstå.

Måling af testresultater baseret på risiko hjælper organisationen med at kende det resterende niveau af kvalitetsrisiko under testudførelsen og til at træffe smarte beslutninger om frigivelse.

Risikoprofilering og kundefeedback

Risikoprofilering er en proces til at finde det optimale niveau af investeringsrisiko for kunden under hensyntagen til den nødvendige risiko, risikokapacitet og risikotolerance.

Risk Required er det risikoniveau, kunden skal tage for at opnå et tilfredsstillende afkast
Risikokapacitet er den finansielle risiko, som kunden har råd til at tage
Risikotolerance er det risikoniveau, som klienten foretrækker at tage

Kundefeedback

Indsaml kundefeedback og anmeldelser for at forbedre forretningen, produktet, servicen og oplevelsen.

Fordele ved risikobaseret test

Fordelene ved risikobaseret test er angivet nedenfor

Forbedret produktivitet og omkostningsreduktion
Forbedret markedsmulighed (Time to market) og levering til tiden.
Forbedret serviceydelse
Forbedret kvalitet, da alle applikationens kritiske funktioner testes.
Giver klare oplysninger om testdækning. Ved at bruge denne tilgang ved vi, hvad der er/ikke er blevet testet.
Testindsatsfordeling baseret på risikovurdering er den mest effektive og effektive måde at minimere den resterende risiko ved frigivelse.
Måling af testresultater baseret på risikoanalyse gør det muligt for organisationen at identificere det resterende niveau af kvalitetsrisiko under testudførelse og at træffe smarte beslutninger om frigivelse.
Optimeret test med højt definerede risikovurderingsmetoder.
Forbedret kundetilfredshed – Grundet kundeinddragelse og god rapportering og fremdriftssporing.
Tidlig opdagelse af de potentielle problemområder. Effektive forebyggende foranstaltninger kan træffes for at overvinde disse problemer
Kontinuerlig risikoovervågning og -vurdering gennem hele projektets livscyklus hjælper med at identificere og løse risici og løse de problemer, der kan bringe opnåelsen af overordnede projektmål og -mål i fare.

Resumé

I Software Engineering er risikobaseret testning den mest effektive måde at guide projektet baseret på risici.

Testindsatsen er effektivt organiseret, og prioritetsniveauet for hver risikopost vurderes. Hver risiko er så forbundet med de relevante testaktiviteter, hvor en enkelt test har mere end én risikopost, så tildeles testen som den højeste risiko.

Test udføres i henhold til risikoprioriteringsrækkefølgen. Risikoovervågningsprocessen hjælper med at holde styr på de identificerede risici og reducere virkningerne af resterende risici.

Du kan lide: