Risikobaseret test: tilgang, matrix, proces og eksempler

Risikobaseret test

Risikobaseret test (RBT) er en type softwaretestning, der er baseret på sandsynligheden for risiko. Det involverer vurdering af risikoen baseret på softwarens kompleksitet, virksomhedens kritiske karakter, brugshyppighed og de områder, der mest sandsynligt indeholder en defektRisikobaseret testning prioriterer testning af de funktioner i softwareapplikationen, som har størst effekt og er mere tilbøjelige til at have defekter.

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

Risici kan være positive eller negative.

• Positive risici omtales som muligheder og hjælp til forretningsmæssig bæredygtighed. Eksempler omfatter investering i et nyt projekt, ændring af forretningsprocesser og udviklingping Nye produkter.
• Negative risici betegnes som trusler, og anbefalinger til at minimere eller eliminere dem skal implementeres for at projektet skal lykkes.

Fordi teknikken allokerer indsats i stedet for at tilføje et nyt testniveau, placeres det oven på det andet typer af softwaretestning i stedet for at erstatte nogen af ​​dem.

Hvornår skal man implementere risikobaseret testning

Risikobaseret testning kan implementeres i

• Projekter med tids-, ressource- eller budgetbegrænsninger.
• 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, såsom manglende erfaring med de anvendte teknologier eller manglende viden om forretningsområdet.
• Inkrementelle og iterative leveringsmodeller.

Risikostyringsproces

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

Risikoidentifikation

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

Et risikoregister er et regneark, der indeholder en liste over identificerede risici, potentielle reaktioner og underliggende årsager. Det bruges til at overvåge og track risiciene (både trusler og muligheder) i hele projektets levetid. Risikohåndteringsstrategier kan bruges til at håndtere positive og negative risici.

En risikoopdelingsstruktur spiller en vigtig rolle i risikoplanlægning. Den hjælper med at identificere de risikofyldte områder og understøtter effektiv evaluering og risikoovervågning i løbet af projektet. Den hjælper med at afsætte tilstrækkelig tid og ressourcer til risikostyringsaktiviteter og med at kategorisere de mange kilder, hvorfra projektrisici kan opstå.

Eksemplet nedenfor viser, hvordan en risikoopdelingsstruktur grupperer risici i kategorier, så ingen risikokilder overses.

Risikoanalyse (omfatter kvantitativ og kvalitativ analyse)

Når listen over potentielle risici er identificeret, er næste skridt at analysere dem og filtrere risiciene efter betydning. En af de kvalitative risikoanalyseteknikker er risikomatricen (behandles i et senere afsnit). Denne teknik bruges til at bestemme sandsynligheden og virkningen af ​​risikoen.

Planlægning af risikorespons

Baseret på analysen kan vi afgøre, om risiciene kræver en reaktion. For eksempel vil nogle risici kræve en reaktion i projektplanen, nogle kræver en reaktion i projektovervågningen, og nogle vil slet ikke kræve nogen reaktion.

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

Risikoreduktion er en risikohåndteringsmetode, 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. Diagrammet nedenfor placerer risikohåndteringsplanlægning inden for den bredere risikostyringscyklus.

Risikoberedskab

Beredskab kan beskrives som muligheden for en usikker begivenhed, hvis indvirkning er ukendt eller uforudsigelig. En beredskabsplan er også kendt som en handlingsplan eller backup-plan for værst tænkelige scenarier. Med andre ord bestemmer den, hvilke skridt der kan tages, når en uforudsigelig begivenhed indtræffer.

Risikoovervågning og -kontrol

Risikostyrings- og overvågningsprocessen bruges til at track de identificerede risici, overvåge resterende risici, identificere nye risici, opdatere risikoregisteret, analysere årsagerne til enhver ændring, udføre risikohåndteringsplanen og overvåge risikoudløsere. Deres effektivitet i at reducere risiko evalueres derefter.

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, værktøjer og output til risikoovervågning og -kontrol.

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

Risikobaseret testmetode

Ovenstående styringsprocessen understøtter testmetoden nedenfor. Hvert nummereret trin producerer input, som det næste trin bruger.

1. Analyser kravene.
   • Dokumenter (SRS, FRS, use cases) gennemgås. Denne aktivitet udføres for at finde og eliminere fejl og tvetydigheder.
   • Kravgodkendelse er en af ​​risikoreducerende teknikker til at undgå forsinkede ændringer i projektet. Enhver ændring af et krav, efter dokumentet er baselinet, involverer en ændringskontrolproces og efterfølgende godkendelser.
2. Vurder risici ved at beregne sandsynligheden og indvirkningen af ​​hvert krav på projektet, under hensyntagen til de definerede kriterier såsom omkostninger, tidsplan, ressourcer, omfang, teknisk ydeevne, sikkerhed, pålidelighed og kompleksitet.
   • Identificer sandsynligheden for fiasko og områder med høj risiko. Dette kan gøres ved hjælp af en risikovurderingsmatrix.
   • Brug et risikoregister til at liste de identificerede risici. Opdater, overvåg og track risiciene periodisk med jævne mellemrum.
   • Risikoprofilering skal udføres på dette stadium for at forstå risikokapaciteten og risikotoleranceniveauerne.
3. Prioriter kravene ud fra vurderingen.
   • Den risikobaserede testproces er defineret.
   • Meget kritiske og mellemstore risici kan tages i betragtning i forbindelse med planlægning, implementering og overvågning af afværgeforanstaltninger. Lave risici kan holdes på en overvågningsliste.
   • Kvalitetsvurdering af risikodata foretages for at analysere kvaliteten af ​​dataene.
4. Planlæg og definer testene i henhold til vurderingen.
   • Anvend en passende testtilgang og testdesignteknikker, så de elementer med den højeste risiko testes først. Elementer med høj risiko kan testes af en ressource med god domæneviden og -erfaring.
   • Forskellige testdesignteknikker kan anvendes – for eksempel beslutningstabel teknik på højrisikotestemner, og kun ækvivalensopdeling for testgenstande med lav risiko.
   • Test tilfælde er også designet til at dække flere funktionaliteter og komplette forretningsscenarier.
   • Forbered testdata, testbetingelser og testbed.
5. Revse testdokumentationen — testplaner, teststrategi, testcases, testrapporter og ethvert andet dokument udarbejdet af testteamet.
   • Peer review er et vigtigt skridt i defektidentifikation og risikoreduktion.
6. Udfør prøvekørsler og kvalitetskontroller af resultaterne.
   • Testcases udføres i henhold til risikopostens prioritet.
   • Vedligehold tracforskel mellem risikoelementer, de tests, der dækker dem, resultaterne af disse tests og de defekter, der findes under testningen. Alle teststrategier, der udføres korrekt, vil reducere kvalitetsrisici.
   • Risikobaseret testning kan bruges på alle testniveauer — komponent, integration, systemet og accepttest.
   • På systemniveau skal vi fokusere på, hvad der er vigtigst i applikationen. Dette kan bestemmes ved at se på funktionernes synlighed, brugshyppigheden og de mulige omkostninger ved fejl.
   • Evaluering af exitkriterier: alle højrisikoområder er fuldt testet, med kun mindre restrisici udestående.
7. Rapportér de risikobaserede testresultater og analyser målingerne.
   • Revurder eksisterende risikohændelser og nye risikohændelser baseret på Key Risk Indicators.
   • Opdater risikoregisteret.
   • Beredskabsplaner fungerer som en reserve- eller nødplan for høje eksponeringsrisici.
   • Fejlanalyse og fejlforebyggelse bruges til at eliminere fejlene.
   • Gentestning og Regressionstest Valider fejlrettelserne baseret på den forudberegnede risikoanalyse, og områder med høj risiko bør dækkes mest intensivt.
   • Risikobaseret automatiseringstest, hvis det er muligt.
   • Beregning af restrisiko.
8. Overvåg og styr risiciene.
   • Afslutningskriterier eller færdiggørelseskriterier kan defineres separat for forskellige risikoniveauer. Alle nøglerisici er blevet adresseret med passende handlinger eller beredskabsplaner, og risikoeksponeringen er på eller under det niveau, der er aftalt som acceptabelt for projektet.
   • Revurdering af risikoprofilering og kundefeedback.

Risikobaseret testmetode til systemtesten

1. Teknisk systemtest — Dette kaldes miljøtest og integrationstest. Miljøtesten omfatter test i udviklings-, test- og produktionsmiljøer.
2. Test af funktionelt system — Test af alle funktioner, funktioner, programmer og moduler. Formålet med denne test er at vurdere, om systemet opfylder de specificerede krav.
3. Ikke-funktionel systemtest — Test af ikke-funktionelle krav: ydeevne, belastningstest, stresstest, konfigurationstest, sikkerhedstest, backup og opsving procedurer og dokumentation (system-, drifts- og installationsdokumentation).

Diagrammet nedenfor giver et tydeligt overblik over ovennævnte proces.

Systemtestning omfatter både funktionelle tests og ikke-funktionelle tests.

Funktionel test sikrer, at produktet eller applikationen opfylder kundernes og virksomhedens krav. På den anden side, ikke-funktionel testning gøres for at verificere, om produktet lever op til kundens forventninger med hensyn til kvalitet, pålidelighed, brugervenlighed, ydeevne og kompatibilitet.

Sådan udfører du risikobaseret testning: Komplet proces

Dette afsnit dækker den risikobaserede testproces, som forløber i fem faser.

1. Risikoidentifikation
2. Risikoanalyse
3. Risikoreaktion
4. Test Scoping
5. Testproces definition

De fem faser hænger sammen, som vist nedenfor.

1. I denne proces identificeres og kategoriseres risiciene, der udarbejdes et udkast til et risikoregister, og der foretages risikosortering for at identificere de væsentlige risici.
2. Risikohåndtering involverer formulering af testmål ud fra risiciene og valg af passende teknikker, så testaktiviteten eller testteknikken opfylder disse testmål.
3. Dokumenterede afhængigheder, krav, omkostninger og den tid, der kræves til softwaretest, tages i betragtning for at beregne testeffektivitetsscoren.
4. Testscoreping er en gennemgangsaktivitet, der kræver deltagelse af alle interessenter og teknisk personale. Det er vigtigt at overholde det aftalte risikoområde. Disse risici skal håndteres ved testning, og alle medlemmer skal være enige om det tildelte ansvar og det budget, der er afsat til disse aktiviteter.
5. Når testomfanget er endeligt fastlagt, skal testmålene, antagelserne og afhængighederne for hvert testtrin samles i standardformatet.

Det nedenstående eksempel knytter hvert krav til den tilhørende risiko og til det testmål, der adresserer det.

Lad os se på de funktionelle krav F1, F2 og F3, og de ikke-funktionelle krav N1 og N2.

F1 — Funktionelt krav, R1 — Risiko forbundet med F1

• Testmål 1 — Demonstrer ved hjælp af en test, at systemets forventede funktioner og funktionaliteter fungerer korrekt, og at risiko R1 kan håndteres ved funktionel testning.
• Test — Test af browsersider udføres for at udføre vigtige brugeropgaver og verificere, at R1 (risikoen forbundet med F1) kan håndteres i en række scenarier.

F2 — Funktionelt krav, R2 — Risiko forbundet med F2

• Testmål 2 — Demonstrer ved hjælp af en test, at systemets forventede funktioner og funktionaliteter fungerer korrekt, og at risiko R2 kan håndteres ved funktionel testning.
• Test — Test af browsersider udføres for at udføre vigtige brugeropgaver og verificere, at R2 kan håndteres i en række scenarier.

F3 — Funktionelt krav, R3 — Risiko forbundet med F3

• Testmål 3 — Demonstrer ved hjælp af en test, at systemets forventede funktioner og funktionaliteter fungerer korrekt, og at risiko R3 kan håndteres ved funktionel testning.
• Test — Test af browsersider udføres for at udføre vigtige brugeropgaver og verificere, at R3 kan håndteres i en række scenarier.

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

• Testmål N1 — Demonstrer ved hjælp af en test, at systemets driftsmæssige egenskaber fungerer korrekt, og at risiko NR1 kan håndteres ved ikke-funktionel testning.
• Test — Brugervenlighedstest er en teknik, der bruges til at vurdere, hvor nemme brugergrænseflader er at bruge, og til at verificere, at NR1 kan løses ved hjælp af brugervenlighedstest.

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

• Testmål N2 — Demonstrer ved hjælp af en test, at systemets driftsmæssige egenskaber fungerer korrekt, og at risiko NR2 kan håndteres ved ikke-funktionel testning.
• Test — Sikkerhedsprøvning er en teknik, der bruges til at kontrollere, om en applikation er sikker eller sårbar over for angreb, om der er informationslækage, og til at verificere, at NR2 kan adresseres ved sikkerhedstest.

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

Procedure til design af den risikobaserede testproces

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

Kolonne 1 og 2 i dette register indeholder identifikatoren og risikobeskrivelsen. De resterende kolonner er beskrevet nedenfor.

Sandsynligheden (1 lav, 5 høj) og konsekvenserne (1 lav, 5 høj) for hver risiko vurderes, da de to registre f.eks.tracts nedenfor viser.

• Testeksponeringen beregnes.
• Testeren analyserer hver risiko og vurderer, om risikoen kan testes eller ej.
• Testmål er defineret for de testbare risici.
• Testeren specificerer den testaktivitet, 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 opdeles i faser (komponenttestning eller enhedstest, integrationstest, systemtest, accepttest).
• Til tider kan en risiko håndteres af mere end én testfase.
• Identificer afhængigheder og antagelser (tilgængelighed af færdigheder, værktøjer, testmiljøer og ressourcer).
• Testeffektivitet beregnes. Testeffektivitet relaterer sig til testerens konfidensniveau for, at risikoen definitivt vil blive adresseret gennem testning. Testeffektivitetsscoren er et tal mellem et og fem (5 = høj konfidens, 1 = lav konfidens).
• Estimer indsatsen, den nødvendige tid og omkostningerne til at forberede og udføre disse tests.

De næste to eks.tracts viser de resterende registerkolonner og den gældende testeffektivitetsscore.

• Testprioritetstallet beregnes. Det er produktet af sandsynligheden, konsekvenserne og testeffektivitetsscorerne.
• 125 (maksimum) — en meget alvorlig risiko, der kunne opdages ved testning.
• 1 (minimum) — en meget lav risiko, der ikke ville blive opdaget ved testning.
• Baseret på testprioritetsnummeret kan testvigtigheden klassificeres som Høj (rød), Mellem (gul) og Lav (grøn). Elementerne med den højeste risiko testes først.
• Tildel testaktiviteterne til testfaserne. Udpeg den gruppe, der skal udføre test for hvert mål i de forskellige testfaser (enhedstest, integrationstest, systemtest, accepttest).

Fordelingen på tværs af testfaserne er vist nedenfor.

Hvad der er inden for og uden for testområdet, afgøres i testscenariet.ping fase.

• For hver fase defineres testmål, komponent under test, ansvar, miljø, startkriterier, slutkriterier, værktøjer, teknikker og leverancer.

Generiske testmål — disse generiske mål gælder for flere projekter og applikationer.

• Komponenten 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, og grænsefladekompatibilitet mellem komponenterne er sikret.
• Systemet opfylder de specificerede funktionelle og ikke-funktionelle krav.
• Produktkomponenter opfylder slutbrugerens behov i deres tilsigtede driftsmiljø.
• En risikostyringsstrategi bruges til at identificere, analysere og mindske risici.
• Systemet opfylder branchebestemmelsernes krav.
• Systemet opfylder kravenetracfaktiske forpligtelser.
• Institutionalisering og opnåelse af andre specifikke mål såsom omkostnings-, tidsplan- og kvalitetsmål.
• Systemer, processer og mennesker opfylder forretningskravene.

Generiske testmål kan defineres for de forskellige testfaser.

• Komponenttestning
• Integrationstest
• Systemtest
• Acceptantestning

Lad os se på systemtestfasen.

1. G4 og G5 viser, at systemet opfylder de funktionelle krav (F1, F2, F3) og de ikke-funktionelle krav (N1, N2).
2. Demonstrer ved hjælp af test, at systemets forventede funktioner og funktionaliteter fungerer korrekt, og at risiciene forbundet med F1, F2 og F3 kan imødegås ved funktionel testning.
3. Demonstrer ved hjælp af test, at systemets driftsmæssige egenskaber fungerer korrekt, og at risiciene forbundet med N1 og N2 kan imødegås ved ikke-funktionel test.
4. Baseret på testens prioritetsnummer kan testens vigtighed klassificeres som Høj (rød), Mellem (gul) og Lav (grøn).

Prioriterings- og risikovurderingsmatrix

Risikovurderingsmatricen er sandsynligheds-effektmatricen. Den giver projektteamet et hurtigt overblik over risiciene og den prioritet, hvormed hver af disse risici skal håndteres.

Risk rating = Probability x Severity

Sandsynlighed er et mål for chancen for, at en usikker begivenhed vil indtræffe, baseret på eksponering i form af tid, nærhed og gentagelse. Det udtrykkes som en procentdel.

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

• Hyppig — Forventes at forekomme flere gange under de fleste omstændigheder (91-100%).
• Sandsynlig — Forekommer sandsynligvis flere gange i de fleste tilfælde (61-90%).
• Lejlighedsvis — Kan forekomme på et tidspunkt (41-60%).
• Fjernbetjening — Det er usandsynligt, men det kan forekomme på et tidspunkt (11-40%).
• Usandsynligt — Kan forekomme under sjældne og exceptionelle omstændigheder (0-10%).
• slået — Umuligt at forekomme (0%).

Alvorlighed er graden af ​​​​påvirkning af skaden eller tabet forårsaget af den usikre begivenhed. Den scores fra 1 til 4 og kan klassificeres som Katastrofal = 1, Kritisk = 2, Marginal = 3 og 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 et stort tab. Projektet er alvorligt truet.
• Marginal — Kortvarig skade, der stadig kan vendes gennem genopretningsaktiviteter.
• ubetydelig — Lille eller minimal skade eller tab. Dette kan overvåges og håndteres ved hjælp af rutinemæssige procedurer.

Prioriteten er klassificeret i fire kategorier, som er kortlagt i forhold til risikoens alvorlighed og sandsynlighed, som vist på billedet nedenfor.

• Alvorlig
• Høj
• Medium
• Lav

Alvorlig: De risici, der falder i denne kategori, er markeret med gult. Aktiviteten skal stoppes, og der skal straks træffes foranstaltninger for at isolere risikoen. Effektive kontroller skal identificeres og implementeres. Desuden må aktiviteten ikke fortsætte, medmindre risikoen er reduceret til et lavt eller mellemstort niveau.

Høj: De risici, der falder ind under denne kategori, er markeret med rødt og kræver øjeblikkelig handling eller en risikostyringsstrategi. Der skal træffes øjeblikkelige foranstaltninger for at isolere, eliminere eller erstatte risikoen og implementere effektive risikokontroller. Hvis disse problemer ikke kan løses øjeblikkeligt, skal der defineres strenge tidsfrister for at løse dem.

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

Lav: De risici, der falder ind under denne kategori, er markeret med grønt og kan normalt accepteres, da de ikke udgør noget væsentligt problem. En periodisk gennemgang er stadig et must for at sikre, at kontrollerne forbliver effektive.

Generisk tjekliste til risikobaseret testning

Matricen bestemmer, hvordan en risiko vurderes. Tjeklisten nedenfor afgør, hvilke kandidater der i første omgang skal ind i matricen.

• Vigtige funktioner i projektet.
• Brugersynlig funktionalitet i projektet.
• Den funktionalitet, der har den største sikkerhedsmæssige indflydelse.
• Funktioner, der har den største økonomiske indvirkning på brugerne.
• Meget komplekse områder af kildekode og fejlbehæftet kode.
• Funktioner eller funktioner, der kan testes tidligt i udviklingscyklussen.
• Funktioner eller funktionaliteter, der blev tilføjet til produktdesignet i sidste øjeblik.
• Kritiske faktorer ved lignende eller relaterede tidligere projekter, der forårsagede problemer.
• Primære faktorer eller problemer ved lignende eller relaterede projekter, der havde en enorm indflydelse på drifts- og vedligeholdelsesudgifter.
• Dårlige krav, der fører til dårlige designs og tests, hvilket kan have en 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 skrottes fuldstændigt, hvilket vil forårsage alvorlig skade på virksomhedens omdømme. Identificér, hvilke problemer der er afgørende for produktets mål.
• Situationer eller problemer, der ville forårsage vedvarende kundeserviceklager.
• End-to-end tests, der nemt kunne fokusere på flere af systemets funktioner.
• Det optimale sæt af tests, der kan maksimere risikodækningen.
• Hvilke tests vil have det bedste forhold mellem højrisikodækning og den nødvendige tid?

Rapportering og målinger af risikobaserede testresultater

1. Udarbejdelse af testrapport. Rapportering af teststatus handler om effektivt at kommunikere testresultaterne til projektets interessenter, give en klar forståelse og vise sammenligningen af ​​testresultaterne med testmålene.
   • Antal planlagte versus udførte testcases.
   • Antal beståede eller mislykkede testtilfælde.
   • Antal identificerede defekter, samt deres status og alvorlighedsgrad.
   • Antal kritiske defekter, der stadig er åbne.
   • Miljømæssige nedetider, hvis nogen.
   • Showstoppere, hvis nogen.
   • Testoversigtsrapport og test dækning indberette.
2. Forberedelse af metrikker. En metrik er en kombination af to eller flere målinger, der bruges til at sammenligne softwareprocesser, projekter og produkter.
   • Variation i indsats og tidsplan.
   • Produktivitet i forberedelse af testcases.
   • Dækning af testdesign.
   • Produktivitet i testcase-udførelse.
   • Risikoidentifikationseffektivitet i %.
   • Risikoreduktionseffektivitet i %.
   • Testeffektivitet i %.
   • Dækning af testudførelse.
   • Produktivitet i testudførelsen.
   • Defekt lækage i %
   • Effektivitet af fejldetektering, og defektdensitet.
   • Kravsstabilitetsindeks.
   • Prisen for kvalitet.

Disse foranstaltninger sammenlignes derefter med risiciene:

• Analysér risiciene i ikke-funktionelle kategorier (ydeevne, pålidelighed og brugervenlighed) baseret på defektstatus og antallet af beståede eller ikke-beståede testresultater i forhold til risiciene.
• Analysér risiciene i funktionelle kategorier ved hjælp af testmålinger, defektstatus og teststatus for bestået eller ikke bestået, i forhold til risiciene.
• Identificer vigtige indikatorer for lead og lag, og opret tidlige advarselsindikatorer.
• Overvåg og rapporter om risikoindikatorer for lead og lag (nøglerisikoindikatorer) ved at analysere datamønstre, tendenser og indbyrdes afhængigheder.

Iboende risiko vs. resterende risikovurdering

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

• Iboende risiko: De risici, der blev identificeret eller allerede var til stede i systemet, før kontrollerne og reaktionerne blev implementeret. Iboende risici er også kendt som bruttorisici.
• Restrisiko: De risici, der er tilbage, efter at kontroller og reaktioner er implementeret. Resterende risici kaldes nettorisici.
• Sekundær risiko: Den nye risiko forårsaget af implementeringen af ​​risikoberedskabsplanen.
• Tilbagevendende risiko: Sandsynligheden for, at de oprindelige risici vil opstå igen.

Måling af testresultater baseret på risiko hjælper organisationen med at kende det resterende niveau af kvalitetsrisiko under testudførelse og med at træffe informerede 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, risikokapaciteten og risikotolerancen.

1. Risiko krævet er det risikoniveau, som kunden skal tage for at opnå et tilfredsstillende afkast.
2. Risikokapacitet er det niveau af økonomisk risiko, som klienten har råd til at tage.
3. Risikotolerance er det risikoniveau, som klienten foretrækker at tage.

Kunde feedback: indsamle kundefeedback og anmeldelser for at forbedre forretningen, produktet, servicen og oplevelsen.

Fordele ved risikobaseret test

Fordelene ved risikobaseret testning er angivet nedenfor.

• Forbedret produktivitet og omkostningsreduktion.
• Forbedrede markedsmuligheder (time to market) og levering til tiden.
• Forbedret serviceydelse.
• Forbedret kvalitet, da alle applikationens kritiske funktioner testes.
• Tydelig information om testdækning. Ved at bruge denne tilgang ved teamet, hvad der er blevet testet, og hvad der 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 informerede beslutninger om frigivelse.
• Optimeret testning med klart definerede risikovurderingsmetoder.
• Forbedret kundetilfredshed takket være kundeinvolvering og god rapportering og fremskridt trackonge.
• Tidlig opdagelse af potentielle problemområder, så effektive forebyggende foranstaltninger kan træffes.
• Løbende risikoovervågning og -vurdering gennem hele projektets livscyklus hjælper med at identificere og løse risici og med at håndtere de problemer, der kan bringe opnåelsen af ​​de overordnede projektmål i fare.

Ofte Stillede Spørgsmål