Den ultimate guiden til risikobasert testing: risikostyring i programvaretesting

ultimate guide risk based testing

Den ultimate guiden til risikobasert testing, risikostyring og dens tilnærming med eksempler:

Hva er risikobasert testing?

Risikobasert testing er å utføre tester eller å designe og utføre scenariene, slik at de viktigste forretningsmessige risikoene som vil ha en negativ innvirkning på virksomheten som identifisert av kunden, blir avdekket i deres produkt eller funksjon tidlig i livssyklusen og er avbøtes ved å iverksette avbøtende tiltak.

=> Klikk her for fullstendig testplanopplæringsserie

Den negative effekten kan inkludere kostnadseffekt, misfornøyd kunde, dårlig brukeropplevelse, og til og med i den grad at kundene mister.

Med andre ord er RBT-tilnærmingen å sikre at testing blir gjort på en slik måte at selv om en bruker finner en feil i produksjonen, som ikke hindrer ham / henne i å bruke programvaren eller ikke påvirker virksomheten på en seriøs måte.

RBT tester utført basert på produktrisiko. RBT skal finne ut av det i god tid, da hva er risikoen for svikt i en bestemt funksjon eller funksjonalitet i produksjonen og dens innvirkning på virksomheten når det gjelder kostnader og andre skader ved å bruke en prioriteringsteknikk for testsakene.

Derfor bruker risikobasert testing prinsippet om prioritere testene av funksjonene, modulene og funksjonene til et produkt eller en programvare. Prioriteringen er basert på risikoen for sannsynligheten for svikt i den funksjonen eller funksjonaliteten i produksjonen og dens innvirkning på kundene.

Hva du vil lære:

• Risikobasert testing og dens relevans for Agile & DevOps
  • Risikobasert testtilnærming
    • Når bruker vi RBT-tilnærmingen?
    • Eksempel på RBT-tilnærming
  • Måter å gjennomføre risikoanalyse på
  • Prosedyre for risikoanalyse
  • Metode for risikoanalyse
    • Trinn 1) Bruke et 3X3 rutenett
    • Trinn 2) Sannsynlighet og virkning av feil
    • Trinn 3) Testing av prioritetsnett
    • Trinn 4) Detaljer om testing
  • Hvordan er RBT relevant for Agile og DevOps?
  • Fordeler med risikobasert testtilnærming
• Risikostyring under testplanlegging
  • Risikostyringsprosess
    • # 1) Risikoidentifikasjon
    • # 2) Risikovurdering / risikovirkningsanalyse
    • # 3) Risikoreduksjon
  • Konklusjon
• Risikostyring i testutførelsesfasen (med eksempel)
  • Risikostyring - med fokus på AUT
  • Hvordan foregår testing av risikobaser?
  • Konklusjon
  • Anbefalt lesing

Risikobasert testing og dens relevans for Agile & DevOps

Tre hundre timer brukt på å utvikle programvare kan gjøres ubrukelig på bare 30 sekunder med en enkelt feil identifisert i produksjonen.

Dette kan igjen ødelegge formålet med hele produktet uten noe annet alternativ enn bare å trekke det ut av markedet. Og det er betydningen og behovet for ‘Quality testing’.

Med den raske veksten i teknologi, er programvaren vert på skyen som støtter flere operativsystemer, flere plattformer, komplekse IT-infrastrukturer, etc., sluttbrukerne blir mer og mer masete om funksjonene, alternativene, og de går aldri på akkord for kundetilfredshet. .

I dag blir ‘Kvalitet’ en avgjørende faktor i programvarelevering, der kontinuerlige forbedringer skjer for å forbedre kvaliteten for å holde kundene fornøyde.

Vi merker ofte at det er et vanlig problem for nesten alle testere å være under et enormt press for at testvinduet deres blir presset, og vanligvis blir bygningen overlevert til dem for testing i siste øyeblikk. Det er ikke nok tid og ressurser til at de kan kjøre alle testene de har designet, og automatiseringsdekningen er ikke alltid 100%, og den har sine egne utfordringer.

Leveringstidslinjen kan ikke gå glipp av, og samtidig kan ikke kvaliteten også kompromitteres. Uansett plan B, å legge til flere testressurser ved å trekke ut fra de andre teamene, ikke fungerer, Plan C, slutte å gjøre alle de andre aktivitetene og vende innsatsen til dette alene, hjelper egentlig ikke. Uansett hvor mye tilførsel av testressurser, til slutt, ikke fungerer.

Det er ikke noe annet alternativ enn bare å kjøre begrensede og viktige tester innen tilgjengelig tid og ressurser.

Så hvordan bestemmer vi hvilken test som er viktig på dette stadiet? Uansett hva en tester anser som viktig, er det kanskje ikke veldig viktig for kundene. Fra hvilket perspektiv er viktigheten av funksjonen eller en funksjonalitet bestemt? Hvem bestemmer hvilke viktige tester? Og mange andre spørsmål fortsetter å oppstå.

For å svare på alle disse spørsmålene og for å håndtere den ovennevnte situasjonen effektivt, ble en testtilnærming kalt ‘Risikobasert testing’ , ringte kort tid 'RBT' , kom til, der teamet tydelig har planlagt og identifisert testscenariene basert på ‘Project Risk’-kriteriene.

Selv om QA-teamet har et klart bilde av viktige tester, er RBT en påvist metode for å identifisere viktige og viktige tester fra kunde- og forretningsperspektiv gjennom en 'Risikoanalyse' fremgangsmåte .

Så, i motsetning til den tradisjonelle måten å bare identifisere feilene i programvaren, har QA-tilnærmingen og målet endret seg med tiden på grunn av endringen i teknologien, økt konkurranse i markedet for å gi ut en kvalitetsprogramvare, innføring av 'Automate Everything', og i en helhet introduksjon av Agile og DevOps praksis med å levere programvaren over noen få timer.

Derfor er den nåværende trenden med 'Testing Principle' ikke bare 'å identifisere feilene', men også å

#1) Fokuser på det området av produktet der det er stor innvirkning på virksomheten på grunn av svikt eller stor sannsynlighet for svikt i produksjonen.

#to) Fokuserer på identifisere manglene tidlig og la et team fikse det så tidlig som mulig og dermed la programvaren / produktet eller funksjonen gjøre det ‘Fail Fast’.

# 3) Det viktigste aspektet ved Service av QA-teamet nå er å fokusere på at kunden gir verdi til kunden ved å øke fokuset på ‘Slutt til slutt kundeopplevelse’.

Risikobasert testtilnærming

Det er alltid som å forberede seg til en undersøkelse, at man ikke kan si at testing er nok, og det er ikke flere feil i programvaren, selv om de designer og utfører et stort antall tester.

Det er et poeng der programvarestabilitet ikke kommer til å bli dobbelt garantert ved å øke antall testsaker alene. På dette tidspunktet er det ikke bare å fokusere på antall tester, men på hva kunden faktisk forventer av utgivelsen.

Derfor er det viktig å finne en balanse i å optimalisere testingen for å oppnå maksimal nytte med en rimelig innsats for testing. Og dette er viktigere når testtidslinjene er veldig stramme og det ikke er nok ressurser til å utføre tilstrekkelig testing.

I dette tilfellet spiller RBT-tilnærmingen en nøkkelrolle i å optimalisere QA-innsatsen og maksimere testfordelen med den minste forretningsrisikoen.

Så hvis vi fokuserer på det ovennevnte aspektet, vil arbeidet med en kvalitetssikring være mye lettet. De trenger ikke å brenne helgene på kontoret, kontinuerlig teste programvaren og bli bekymret for hver S4 (alvorlighetsgrad 4) og P4 (prioritet 4) -feil som kommer ut av testingen.

Vel, 4 betraktes som den laveste prioriteten og alvorlighetsgraden av defektene ved testing. De kan bedre investere tiden sin i andre nyttige aspekter av prosjektet.

For å oppsummere de viktigste driverne for tilnærmingen ‘Risikobasert testing’:

• For å muliggjøre testing av 'hva kundene ønsker' fra et forretningsperspektiv.
• For å oppfylle tidsplanen med forventet kvalitet.
• For å optimalisere QA-innsatsen.

Når bruker vi RBT-tilnærmingen?

Dette brukes under scenariene nedenfor:

• RBT-tilnærming kan brukes når det er en begrensning eller begrensning på tid, kostnader og ressurser til et prosjekt og når det er behov for å optimalisere ressursene.
• RBT-tilnærming brukes når programmet er mer komplekst og tilpasser ny teknologi og dermed innebærer mange utfordringer.
• Når programmet er et FoU-prosjekt og det er av første type, og det er en rekke ukjente og risikoer i prosjektet.

Eksempel på RBT-tilnærming

Flere risikobaserte analysetilnærminger brukes i IT-bransjen for å overvinne risikoen som produksjonen står overfor og dens innvirkning.

Nedenfor er en slik tilnærming:

Denne tilnærmingen til RBT inkluderer å identifisere 'Vital Functionalities or Key Features' av produktet og vurdere risikoen som hver av disse funksjonene blir utsatt for i produksjonen og implementere egnede avbøtende tiltak på plass for å senke eller redusere risikoen.

Derfor inkluderer RBT-tilnærmingen testing av funksjonalitetene som har sannsynligheten for svikt og størst innvirkning på virksomheten. Typer av feil kan være operasjonelle eller forretningsmessige, tekniske, eksterne osv.

Måter å gjennomføre risikoanalyse på

Det er ingen standardprosess eller mal definert som sådan for å utføre risikoanalysen i programvaretesting for hver eneste funksjon i et produkt. Ulike organisasjoner bruker sin egen tilnærming til risikoanalysemetoder.

Risikoanalyse kan utføres på forskjellige prosjektelementer for å identifisere risikoen og for å implementere en RBT-tilnærming for analyse. Disse elementene inkluderer,

• Egenskaper
• Funksjonaliteter
• Brukerhistorier
• Krav
• Bruk tilfeller
• Test tilfeller

La oss i dette tilfellet bare fokusere på testsaker for å forstå implementeringen av risikobasert testing.

Prosedyre for risikoanalyse

Risikoanalyse inkluderer involvering av relevante interessenter i programmet fra både Teknisk team og forretningsteam ’ , som inkluderer, Eier av produktet, produktledere, forretningsanalytikere, arkitekter, testere og kundepresentanter.

Brainstorming-økter som involverer disse interessentene vil bli organisert for å gjennomføre diskusjonen for å identifisere viktigheten av hver funksjon av et produkt og prioritere dem basert på risikoen for svikt og dens innvirkning på sluttbrukerne i produksjonen.

Forskjellige ‘Prosjektdokumenter’ som Kravdokument, Tekniske spesifikasjonsdokumenter, Arkitektur- og designdokumenter, Forretningsprosessdokument, Bruk saksdokument osv., Blir inngangen til idédugnad.

Interessentens kunnskap om produktet og det eksisterende produktet i markedet vil også være en innsatsfaktor for diskusjonen.

Få andre kilder til innganger kan også omfatte,

• Å samle innspill på den mest brukte funksjonaliteten.
• Innspill fra å konsultere en domenekspert.
• Data fra forrige versjon av produktet eller lignende produkt i markedet.

I løpet av idédugnad sesjon identifiseres risikoen knyttet til hver av disse funksjonene. Risikotypene kan være en virksomhet, teknisk eller forretningsrelatert. Testene og scenariene knyttet til dem vektes og risikovurderinger vurderes ut fra sannsynligheten for risikoforekomst og innvirkning av risikoen.

‘Sannsynligheten for risikoforekomst’ kan skyldes:

• Dårlig forståelse av funksjonen fra produktutviklingsteamet.
• Feil arkitektur og design.
• Utilstrekkelig tid til å designe.
• Inhabilitet i teamet.
• Utilstrekkelige ressurser - mennesker, verktøy og teknologi.

‘Effekten av risikoen’ er effekten av feil for brukerne og virksomheten hvis den oppstår. Virkningen kan være,

• Kostnadspåvirkning, noe som resulterer i tap.
• Virksomhetspåvirkning som resulterer i tap av virksomhet eller tap av markedsandel, Advokatprosedyrer, Tap av lisens
• Kvalitetspåvirkning, noe som resulterer i substandard eller inkompetent produktutgivelse.
• Dårlig brukeropplevelse, som resulterer i misfornøyd og tap av en kunde.

Fokusområdet for å vurdere risikoen til en funksjon eller et produkt kan være,

• Område for virksomhetens kritikk av funksjonaliteten.
• Mest brukte funksjoner og viktig funksjonalitet.
• Defekte utsatte områder
• Funksjonalitet som bærer sikkerhets- og sikkerhetspåvirkningen.
• Område med kompleks design og arkitektur.
• Endringer gjort fra tidligere versjoner.

Metode for risikoanalyse

La oss forstå den “risikobaserte testmetoden” i detalj nå.

Den risikobaserte testtilnærmingen bruker RISK som kriterier i alle testfaser av testsyklusen, dvs. testplanlegging , testdesign, testimplementering, testutførelse , og testrapportering. Ideelt sett kan man designe et stort antall mulige testscenariokombinasjoner.

Derfor inkluderer RBT-tilnærmingen en rangering av testene basert på alvorlighetsgraden av risikoen for å finne ut det mest defekte eller risikable området for svikt, noe som gir stor innvirkning på virksomheten.

Hovedmålet med risikoanalyse er å skille mellom 'Høy verdi' elementer som produktegenskaper, funksjonalitet, krav, brukerhistorier , og prøvesaker, og ‘ Lav verdi ’ de og dermed senere til mer fokus på 'High value' Test Cases, ved mindre fokus på 'Low value' Test Cases. Dette er det første trinnet i risikoanalysen før du starter den risikobaserte testen.

Hovedoppgaven med kategorisering eller gruppering av testtilfeller i høy verdi og lav verdi og tildeling av prioritetsverdien til hver av disse testtilfellene inkluderer følgende trinn:

Trinn 1) Bruke et 3X3 rutenett

Risikoanalyse utføres ved hjelp av et 3X3-rutenett, der hver funksjonalitet, ikke-funksjonalitet og tilhørende testsaker vurderes av et team av interessenter for deres 'Sannsynlighetav svikt 'og' Innvirkning av svikt '.

Sannsynligheten for svikt i hver funksjonalitet i produksjonen er vanligvis tilgjengelig av en gruppe 'tekniske eksperter' og er kategorisert som 'sannsynlig å mislykkes, ganske sannsynlig og usannsynlig' langs den vertikale aksen på rutenettet.

hvordan åpne en dat-fil på windows

På samme måte opplever sluttkunden 'Impact of failure' av disse funksjonene og funksjonalitetene i produksjonen, hvis den ikke testes blir vurdert av en gruppe ' Business Specialists ”og er kategorisert under kategoriene‘ Mindre, synlige og avbrudd ’langs den horisontale aksen på rutenettet.

Trinn 2) Sannsynlighet og virkning av feil

Alle testtilfellene er plassert i kvadrantene til 3 X 3-rutenettet basert på de identifiserte verdiene for sannsynligheten for svikt og innvirkning av svikt, som vises som prikker i bildet nedenfor.

Åpenbart er høy sannsynlighet for svikt og stor innvirkning på svikt (avbrudd) gruppert øverst i høyre hjørne av rutenettet, noe som er av stor betydning, og det er derfor identifisert at 'High Value' tester og 'Low Value' tester er gruppert i nederst i venstre hjørne som er av minst eller ingen betydning for kunden, hvor det kan gis mindre fokus på disse funksjonene eller testtilfellene.

Trinn 3) Testing av prioritetsnett

Basert på den ovennevnte plasseringen av testtilfellene i rutenettet, blir testene prioritert og merket med prioriteringer 1,2,3,4 og 5 og er merket mot hver av dem. De viktigste testene er plassert i en 1^St.rutenett som er tildelt prioritet 1 og tilsvarende mindre viktige rangeres som 2, 3, 4 og 5.

Til slutt sorteres alle testsakene ut fra deres prioritetsnummer og blir hentet for utførelse i prioritetsrekkefølgen. De som har høy prioritet blir plukket opp for utførelse først, og de som er lavt prioriterte blir enten utført senere eller avviklet.

Trinn 4) Detaljer om testing

Neste trinn er å bestemme nivået på detaljer for testing for det definerte omfanget av testing. Dybden av omfanget av testingen kan bestemmes ut fra ovennevnte rangering i henhold til rutenettet nedenfor.

Tester med høy prioritet med rangering 1 er 'grundigere' testet, og derfor blir eksperter distribuert for å teste disse funksjonene med høy kritikk og tilhørende testtilfeller. Tilsvarende tester saker med prioritet 2, 3 og 4. Det kan tas en beslutning om å avvikle prioritet 5-funksjoner og tester basert på tilgjengelig tid og ressurser.

Derfor hjelper detaljnivået i testtilnærmingen med å prioritere funksjonene og dens testtilfeller ikke bare testere til å identifisere 'High-Value Tests', men også veilede dem til å bestemme deres 'detaljnivå for testing' basert på disse prioriterte rangeringene og hjelper dem med å utføre bedre testing og reduserer testkostnadene ved optimaliseringsprosessen.

Hvordan er RBT relevant for Agile og DevOps?

Nå, etter å ha forstått den risikobaserte testtilnærmingen til å utføre testene basert på prioritering av tester, avhengig av 'risikoen for svikt' av en bestemt funksjon og dens 'innvirkning på kunden' i live, ville man åpenbart reise spørsmålet om relevansen av risikobasert testing i Agile og DevOps Practices.

'Automatiser alt', 'Test alt', 'Test kontinuerlig', 'Test gjentatt' er nøkkelbegrepene i denne praksisen.

Hver gang, når det er en endring i koden eller det er en utgivelse, kjøres alle de designede testene gjennom den automatiserte Kontinuerlig integrasjon (CI) / Kontinuerlig levering (CD) rørledningen raskt og gjentatte ganger, uavhengig av prioritering.

Hva er så forholdet mellom RBT og DevOps? Hvor ville RBT passe inn og bli relevant i Agile og DevOps ???

#1) Ja, som jeg sa tidligere, er det ikke at alle bransjer og hvert produkt har 100% automatiseringsdekning for sine testutførelser. Så hvis teamet i det hele tatt må velge prioritering for testutførelse fra valg av manuelle testsaker og ønsker å spare energi og krefter på testressursene mot andre aktiviteter, så er RBT det beste valget.

Den risikobaserte tilnærmingen er også et bedre alternativ for å kjøre automatiserte tester med høy prioritet og teste tidligst.

#to) QA-teamet kan ta i bruk RBT-tilnærmingen mer effektivt under Kravsanalysen ved å analysere kravene og gi en forhåndsrapport om sannsynlige risikoer ved produktene og funksjonene, slik at passende tiltak kan tas proaktivt av programteamet for å redusere det.

# 3) RBT-tilnærming kan brukes effektivt i utformingen av testtilfeller og scenarier basert på høy risiko slik at mer fokus kan rettes mot høyrisiko-funksjoner og funksjoner.

# 4) Identifisering av ”High Risk” -områdene gjør det mulig for QA-teamet å fokusere sin testinnsats på disse områdene for å teste “grundigere” ved hjelp av “High Skilled Testers”.

# 5) 'Fail Fast', som vi alle vet, er konseptet 'Agile' og 'DevOps', som RBT-tilnærming hjelper til med å identifisere de 'høyrisiko' områdene i programvaren, identifisere feilene tidlig og la dem mislykkes raskt og mislykkes først og la teamet fikse det.

# 6) Det endelige målet for Agile / DevOps er 'Kundefokus', og dermed gjør RBT-tilnærmingen QA i stand til å fokusere på kundeopplevelse enn bare å finne feil.

Fordeler med risikobasert testtilnærming

Vi har allerede forstått hensikten og bruken av RBT-metoden for å analysere kravene, designe og utføre testscenariene. Det er flere fordeler med RBT.

Vi kan konsolidere og liste fordelene med risikobasert testing som:

• Hjelper med en mer effektiv og optimalisert bruk av testressurser.
• Hjelper med å lette QA-arbeidet, Testing, Test Design & Development og Test Preparation-aktiviteter ved å prioritere.
• Hjelper med å bedre administrere QA-ressursene ved å tildele nøkkelressursene til områder med høyt fokus.
• Det hjelper i effektiv utnyttelse av ressurser og omdirigerer tid og energi på bedre ting i prosjektet.
• Hjelper QA-teamet med å planlegge testinnsatsen basert på risikovurdering og identifisering av flyktige og høyrisikoområder.
• Det hjelper teamet med å optimalisere testene som skal utføres, avhengig av viktigheten og dermed avvikle lavverditester etter avtale med interessentene.
• Samlet sett hjelper det med kostnadsreduksjon gjennom optimaliserte og reduserte testaktiviteter.
• RBT-tilnærming gjør det mulig for QA-teamet å teste høyrisikoområdene først, og lar produktet “mislykkes raskt” og fikse raskt.
• RBT-tilnærming hjelper til med å bringe klarhet i Testdekning ' og 'Test Scope' til hele gruppen av interessenter.
• Teamet kan øke fokuset på høyrisikoområder og holde mindre fokus på lavrisikoområdet.
• RBT lar teamet bestemme i god tid på implementeringen av den mest effektive måten å redusere produktrisikoen på.
• RBT hjelper til med å unngå effekten av upassende implementering av begrensninger.
• Risikobasert testing lar teamet ta passende tiltak enten for å redusere eller planlegge for beredskap eller for å plassere en løsning for å overvinne feilen eller redusere innvirkningen hvis risikoen oppstår i Live.
• RBT hjelper til med å minimere restrisikoen i utgivelsen.
• Det hjelper med å oppnå 'forbedret kvalitet' gjennom mindre kostbare mangler i produksjonen.
• Hjelper til slutt i 'Forbedret kundeopplevelse' og 'Tilfreds kunde'.

Deretter vil vi lære å håndtere risikoer i testplanlegging og testutførelsesfaser i programvaretestets livssyklus.

Risikostyring under testplanlegging

Hvordan håndtere risiko under testplanleggingsfasen:

Livet er fullt av risikoer, og det samme er et programvareprosjekt. Alt kan gå galt når som helst. Vi er alltid på tærne for å gjøre ting riktig - men hva med å sørge for at ingenting går galt, og at når vi vet nøyaktig hva vi skal gjøre? Gå inn i risikostyring - dette er en del av et programvaretestprosjekt som forbereder oss på å forhindre, forstå, finne og komme over risiko.

En risiko er rett og slett et problem som sannsynligvis vil oppstå, og når den oppstår, vil den føre til tap.

Tapet kan være hva som helst - penger, tid, krefter eller et kompromiss i kvalitet. Tapet er aldri bra. Uansett hvor mye snurr vi gir det, er det ikke positivt - og vil aldri være. Derfor Risikostyring er en integrert del av programvareprosjekter for å sikre at vi håndterer risiko og forebygger / reduserer tap.

Risikobasert testing : Siden vi er et kvalitetssamfunn, la oss være spesifikke for risikoer og prosessen knyttet til det i vår kvalitetssikringsverden. Risikoen vurderes og håndteres omtrent i to faser av vår Programvaretest livssyklus . STLC kan kategoriseres i 3 faser - Testplanlegging, Testdesign og Testutførelse.

Risikostyringsprosessen skjer to ganger i løpet av:

1. Testplanlegging
2. Test saksdesign (slutt) eller noen ganger i testutførelsesfasen

Det er obligatorisk i tilfelle 1, men med tilfelle 2 er det mer en ”behovsgrunnlag” -situasjon.

To-delt artikkelserie:

Selv om den underliggende prosessen er den samme, er typer risikoer adressert i begge disse områdene er helt forskjellige. For å gjøre rettferdighet mot dem hver for seg, skal vi håndtere dem annerledes som en todelt serie.

Denne delen kommer til å handle om “Risikostyring under testplanlegging”.

Risikostyringsprosess

Den generiske prosessen for risikostyring involverer tre viktige trinn:

1. Risikoidentifikasjon
2. Analyse av risikoeffekter
3. Risikoreduserende tiltak

Test av risiko og avbøtende eksempler:

# 1) Risikoidentifikasjon

Som det er sagt, er det første trinnet for å løse et problem å identifisere det. Dette stadiet innebærer å lage en liste over alt som potensielt kan komme opp og forstyrre den normale strømmen av hendelser.

Hovedresultatet av dette trinnet er en liste over risikoer.

Dette risikobaserte testingstrinnet ledes ofte av QA-lederen / lederen / representanten. Imidlertid vil ledelsen ikke være i stand til å komme opp med hele listen - hele QA-teamets innspill gir stor innvirkning. Vi kan si at dette er en kollektiv aktivitet ledet av QA-ledelsen.

Risikoen som identifiseres under testplanleggingsfasen, er også mer 'ledelsesmessig' i retning, noe som betyr at vi skal se på alt som kan påvirke QA-prosjektets tidsplan, innsats, budsjett, endringer i infrastruktur osv. Fokuset her er ikke AUT, men slik QA-fasen vil fortsette.

Risiko under testplanlegging: Eksempler på risikobasert testing

Følgende er en utvalgsliste over risikoer som kan være oppført under testplanleggingsfasen. Vær oppmerksom på at AUT og dens funksjonalitet ikke er i fokus her.

1. Testplanen er stram. Hvis teststart er forsinket på grunn av designoppgaver, kan ikke testen forlenges utover den planlagte UAT-startdatoen.
2. Ikke nok ressurser, ressurser ombord for sent (prosessen tar rundt 15 dager.)
3. Mangler blir funnet på et sent stadium av syklusen eller i en sen syklus; feil oppdaget sent skyldes mest sannsynlig uklare spesifikasjoner og er tidkrevende å løse.
4. Omfang ikke definert helt definert
5. Naturkatastrofer
6. Ikke tilgjengelig av Independent Test miljø og tilgjengelighet
7. Forsinket testing på grunn av nye problemer

På dette tidspunktet kan du velge å være så grundig som du vil, avhengig av hvor lang tid som er tilgjengelig.

Når alle risikoene er oppført, går vi videre til risikovurdering / risikokonsekvensanalyse.

# 2) Risikovurdering / risikovirkningsanalyse

Er risikoanalysen din noe slikt? :)

Risikoanalyse ved programvaretesting : Alle risikoene blir kvantifisert og prioritert i dette trinnet. Hver risikos sannsynlighet (sjansen for forekomst) og innvirkning (mengden tap som den ville forårsake når denne risikoen materialiserer seg) bestemmes systematisk.

Høy - middels lav , verdier er tildelt både sannsynligheten og effekten av hver risiko. Risikoen med “høy” sannsynlighet og “Høy” innvirkning blir ivaretatt først, og deretter følger bestillingen.

Tabell for risikokonsekvensanalyse:

hvilken app lar deg laste ned youtube-videoer

Etter disse trinnene vil tabellen for risikokonsekvensanalyse for de ovennevnte risikoene se ut slik (alle verdier er hypotetiske og bare for forståelsesformål):

# 3) Risikoreduksjon

Det siste trinnet i denne risikobaserte testingen (RBT) er å finne løsninger for å planlegge hvordan man skal håndtere hver av disse situasjonene. Disse planene kan variere fra selskap til selskap, prosjekt til prosjekt og til og med person til person.

Risikoreduserende teknikker:

Her er et eksempel på hva Risikos tabell forvandler seg til når denne fasen er fullført:

Noen få punkter å merke seg:

1. Jo raskere risikostyring starter i en QA-prosjektplanleggingsfase, jo bedre.
2. Av alle 3 trinnene, Risikoidentifisering er det viktigste . Hvis noe ikke er oppført og vurderes for ytterligere trinn, blir risikoen uhåndtert.
3. Prøv å finne en ideell tidsramme for denne aktiviteten. Husk at for mye planlegging gir for lite tid til å gjøre.
4. Også etter risikostyringsprosessen, hvis en ny situasjon kommer opp, kan risikostyringsplanen endres eller oppdateres for å gjenspeile den nyeste tilstanden.
5. Historisk data kan være veldig nyttig for å lykkes med denne prosessen.

Konklusjon

Dette fører oss til en slutt på risikostyring i testplanleggingsfasen. Selv om de underliggende trinnene og prinsippene er like, er risikostyringsprosessen mer konsentrert mot AUT når det skjer i testdesign / utførelsesfasen.

I vår neste seksjon vil vi dekke - Risikostyring i testutførelsesfasen.

Risikostyring i testutførelsesfasen (med eksempel)

I vår reise til å forstå risikostyringsprosessen snakket vi om hvordan det går utelukkende i Testplanleggingsfase av risikobasert testing . Vi forsto også den generiske prosessen som involverer - risikoidentifisering, risikovurdering og risikoreduserende plan.

Hvordan håndtere risiko ved testdesign eller testutførelsesfase:

Det er en annen form for Risikostyring (også noen ganger referert til som, Risikobasert testing ) som oppstår under testdesignen eller testutførelsesfasen, avhengig av situasjonen. Nå, hvilken situasjon snakker vi om? La oss prøve å forstå det først.

Vi vet alle at testarbeidet vårt er reaktivt. Ingen krav (eller omfang definert), vi kan ikke utføre en gjennomførbarhetsanalyse og skrive testscenarier eller planlegge for testaktiviteter.

På samme måte, når koden ikke er klar, har vi ingenting å teste, uansett hvor mye forarbeid vi kanskje har vært klare innen testtilfeller, testdata osv. Dessuten er testing det eneste trinnet igjen før produktet går bo.

Risikostyring - med fokus på AUT

La oss forstå dette bedre med et eksempel:

Hvis testingen skulle begynne på nevnte dato, 1. jan^St.og måtte fortsette til 14. januar^th- når testingen er ferdig, blir produktets Go-live-dato vanligvis løst umiddelbart. La oss si - 15. jan^thfor enkelhets skyld. Nå, i perfekte verden, ville ting gå akkurat som planlagt. Men vi kjenner alle til virkeligheten.

La oss i dette tilfellet anta at testingen av en eller annen grunn ikke startet før 7. jan^th, noe som betyr at vi mistet halvparten av testtiden vår. Men vi trenger 14 dager for å teste produktet grundig. Vi kan flytte go-live-datoen lenger med 7 dager - men; dette er vanligvis ikke et alternativ. Fordi produktet er lovet å komme på markedet på en bestemt dato, og eventuelle forsinkelser er ikke bra for virksomheten.

Så, vanligvis, må vi testteamene absorbere forsinkelsene, kompensere på en eller annen måte, jobbe med den tilgjengelige tiden og sørge for at produktet blir testet godt. Tøff jobb, ikke sant?

Dette er hvor risikostyringsprosessen igjen blir brukt.

• Nå, hvis forsinkelser forventes på forhånd før selv testingen begynner - prosessen finner sted i testdesignfasen.
• Hvis forsinkelser skjer i løpet av en Testutførelsesfase som startet normalt - prosessen følges i løpet av testutførelsesfasen.
• Trinnene og metoden er de samme uansett hvilket stadium det skjer.

Hva er prosessen?

Risikostyring finner sted for å bestemme hvilke områder av AUT (Application Under Test) som trenger maksimal fokus. Dette er vanligvis funksjonsområdene (moduler eller komponenter) som er kritiske for suksessen til sluttproduktet og som er mest utsatt for svikt.

Les også=> Feilmodus og effektanalyse (FMEA) er en teknikk for risikostyring

Hvem utfører det?

Siden det gjelder AUT, er kunnskapen om det ikke bare med QA, men med alle de andre teamene - Dev, BA, Client, Project management teams osv. Derfor er det en kollektiv innsats, drevet av testteamet.

Hvordan foregår testing av risikobaser?

Trinn 1) Risikoidentifikasjon

Identifiser alle funksjonsområdene til AUT. Dette inkluderer ganske enkelt å lage en liste.

Steg 2) Risikovurdering

Alle risikoene blir kvantifisert og prioritert i dette trinnet. Kvantifisering er ganske enkelt å tilordne et tall til hver risiko i listen som vil gi en indikasjon på hvilken prioritet det må adresseres med.

Hver risikos sannsynlighet (sjansen for forekomst) og innvirkning (mengden tap som den ville forårsake når denne risikoen realiseres) avgjøres.

Den typiske metoden er å tildele rangeringene. For eksempel, Sannsynligheten kan ta verdiene 1 til 5. 1 er sannsynligheten for at forekomsten er lav (ikke sannsynlig i det hele tatt) og 5 er høy (vil helt sikkert skje).

På samme måte kan Impact også tildeles en 1-5 vurdering. 1 med liten innvirkning (selv om denne risikoen virkeliggjøres, er tapet minimum) og 5 med stor innvirkning (store tap når det skjer).

Trinn 3)

Lag et bordformat og sirkuler til alle teamrepresentantene - Dev, BA, Client, PM, QA og alle andre relevante.

Trinn 4)

Be hvert team om å fylle ut verdiene basert på deres vurdering for sannsynlighet og innvirkning.

Siden sannsynlighets- og påvirkningsverdiene er numeriske, vil det gjøre beregningen av 'Risikofaktor' -verdien enkel.

Risikofaktor = Sannsynlighet X Påvirkning. Jo høyere risikofaktor, jo alvorligere er problemet.

Et eksempel:

Vær oppmerksom på at dette på dette tidspunktet ganske enkelt er resultatet av ett lags vurdering. For et prosjekt der 5 forskjellige team er involvert, vil QA-teamet ende opp med 5 forskjellige tabeller.

Trinn 5)

Ta et gjennomsnitt av risikofaktorverdiene. For eksempel, hvis det er 5 team, for hver modul, legg til alle risikofaktorverdiene og del den med 5. Dette er de endelige verdiene vi skal håndtere. Si at dette er de gjennomsnittlige risikofaktorene:

Jo mer risikofaktoren er, desto mer må modulen testes.

Så modul 5 og 2 er avgjørende for suksessen til virksomheten. Del resultatene med alle lagene.

Trinn 6)

Risikoreduserende plan : Dette er trinnet som endres fra prosjekt til prosjekt. Vi har identifisert at modulene 5 og 2 er de som må konsentreres mest.

Eksemplerav planen kan være:

1. Modulene 5 og 2 vil bli testet grundig ved å sørge for at alle testtilfellene som er relatert til dem, blir testet. De andre modulene vil bli testet på utforskende basis.
2. Moduler 5 og 2 skal testes først, og avhengig av tilgjengeligheten vil de andre bli tatt vare på.

Når en plan er laget, når alle teamene enighet og følger den for å teste produktet med tanke på risikofaktoren.

Det er det!

Noen viktige punkter å merke seg:

• Siden dette er en kollektiv aktivitet som tar alles mening i betraktning ; sjansene for at det er nøyaktig og effektivt er høyere.
• Dette er ikke en formell metode og trenger ikke være en del av hvert QA-prosjekt.
• Noen ganger, selv om teamet velger å ikke tegne tabeller og tildele verdier - a enkel idédugnad med alle tilstedeværende kan gi QA-teamet god veiledning om hvordan de skal gå frem.
• De utviklingsteamets innspill er veldig viktig fordi det er de som lager produktet, slik at de vet hva som kan fungere og hva som kan trenge ytterligere kontroll. Sørg for å være på utkikk etter det.
• Selv om det er flere trinn i prosessen, det tar ikke mye tid å utføre dem . Spesielt hvis alle lagene kan sitte sammen og jobbe samtidig.
• Husk denne prosessen, og resultatet er bare alternativet . Å få så mye tid som planlagt for testing er den beste måten å utføre QA-aktiviteten på.

Konklusjon

Den risikobaserte testtilnærmingen indikerer tydelig at testens fokus ikke bare er å fortsette å utforske feilene, uavhengig av alvorlighetsgrad og prioritet. Nå har ting endret seg, og testere må jobbe smarte, og de må forstå det klare behovet for kunden og brukerens ønsker.

De må studere produktet grundig og forstå hvilken som er den mest brukte funksjonen i produksjonen, som er den mest kritiske veien for inntektsgenerering, og hvordan de kan beskytte og beskytte kundene mot produksjonsproblemer og forretningstrusler.

Derfor utdanner RBT-tilnærmingen tydelig 3 testere at bare å teste alt eller teste omfattende ikke betyr at testingen er fullført, eller at det ikke er noen feil i produktet. Å teste effektivt i en fastsatt tid og sikre at kritiske og store forretningspåvirkninger blir opphevet, og det er ganske viktig for testeren.

Dermed er risikobasert testing det mest effektive verktøyet for QA-teamet for å veilede interessentene i prosjektet basert på prosjektrisikoen. RBT-tilnærming hjelper QA-teamet med kontinuerlig identifisering av risiko og oppløsning som kan true oppnåelsen av de overordnede prosjektmålene og hjelper til å oppnå det endelige målet for QA Group.

P.S. Ordene QA og Testing har blitt brukt om hverandre i hele dokumentet.

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

Gayathri er en SME med programvaretest med mer enn 2 tiårs erfaring med programvaretesting og har i stor grad tatt i bruk 'Risk-Based Testing' -tilnærmingen som en del av Test Industrialization i flere oppdrag og har innsett fordelen med Test ressursoptimalisering og kvalitetstesting.

Var risikobasert testing utfordrende for deg? Har du noen interessante fakta å legge til i opplæringen vår? Uttrykke gjerne tankene dine i kommentarfeltet nedenfor !!

=> Besøk her for komplett testplanopplæringsserie

Anbefalt lesing

• Kontinuerlig integrasjonsprosess: Hvordan forbedre programvarekvaliteten og redusere risikoen
• Feilmodus og effektanalyse (FMEA) - Hvordan analysere risikoen for bedre programvarekvalitet og fornøyde kunder!
• Den ultimate guiden til risikobasert testing: risikostyring i programvaretesting
• Topp 10 risikovurderings- og styringsverktøy og teknikker
• Typer av risikoer i programvareprosjekter
• Noen interessante spørsmål om intervjuer med programvaretesting
• Velge programvaretesting som din karriere
• Programvaretestkurs Tilbakemelding og anmeldelser