Vrhunski vodič za testiranje na temelju rizika: Upravljanje rizicima u testiranju softvera

ultimate guide risk based testing

Vrhunski vodič za testiranje na temelju rizika, upravljanje rizikom i njegov pristup s primjerima:

Što je ispitivanje temeljeno na riziku?

Testiranje temeljeno na riziku je provođenje ispitivanja ili dizajniranje i izvršavanje scenarija, tako da se glavni poslovni rizici koji će imati negativan utjecaj na poslovanje, kako ih je prepoznao kupac, otkriju u njihovom proizvodu ili svojstvu rano u životnom ciklusu i ublažen provođenjem mjera ublažavanja.

=> Kliknite ovdje za potpunu seriju vodiča za plan ispitivanja

Negativni utjecaj može uključivati ​​utjecaj troškova, nezadovoljni kupac, loše korisničko iskustvo, pa čak i do mjere gubitka kupaca.

Drugim riječima, RBT pristup je osigurati da se testiranje provodi na takav način da čak i ako je korisnik pronalazi bubu u proizvodnji, to ga ne sprječava u korištenju softvera ili ne utječe na posao na ozbiljan način.

RBT se ispituje na temelju rizika proizvoda. RBT treba saznati unaprijed jer je to rizik od neuspjeha određene značajke ili funkcionalnosti u proizvodnji i njezinog utjecaja na poslovanje u smislu troškova i drugih šteta korištenjem tehnike prioritizacije za test slučajeve.

Stoga se ispitivanje temeljeno na riziku koristi načelo određivanje prioriteta testova značajki, modula i funkcionalnosti proizvoda ili softvera. Određivanje prioriteta temelji se na riziku vjerojatnosti kvara te značajke ili funkcionalnosti u proizvodnji i njezinog utjecaja na kupce.

Što ćete naučiti:

• Ispitivanje temeljeno na riziku i njegov značaj za agilne i razvojne programe
  • Pristup ispitivanja temeljenog na riziku
    • Kada koristimo RBT pristup?
    • Primjer RBT pristupa
  • Načini provođenja analize rizika
  • Postupak analize rizika
  • Metodologija analize rizika
    • Korak # 1) Korištenje mreže 3X3
    • Korak # 2) Vjerojatnost i utjecaj neuspjeha
    • Korak # 3) Testiranje prioritetne mreže
    • Korak # 4) Pojedinosti ispitivanja
  • Kako je RBT relevantan za Agile i DevOps?
  • Prednosti pristupa ispitivanja temeljenog na riziku
• Upravljanje rizikom tijekom planiranja ispitivanja
  • Proces upravljanja rizikom
    • # 1) Identifikacija rizika
    • # 2) Procjena rizika / Analiza utjecaja rizika
    • # 3) Ublažavanje rizika
  • Zaključak
• Upravljanje rizikom u fazi izvođenja testa (s primjerom)
  • Upravljanje rizikom - s naglaskom na AUT
  • Kako se odvija testiranje osnova rizika?
  • Zaključak
  • Preporučena literatura

Ispitivanje temeljeno na riziku i njegov značaj za agilne i razvojne programe

Tristo sati utrošenih na razvoj softvera može se učiniti beskorisnim u samo 30 sekundi s jednim nedostatkom utvrđenim u proizvodnji.

To zauzvrat može pokvariti svrhu cijelog proizvoda bez druge mogućnosti, već samo za njegovo povlačenje s tržišta. I to je značaj i potreba za 'ispitivanjem kvalitete'.

S brzim rastom tehnologije, softver se hostira u oblaku koji podržava više OS-a, više platformi, složenu IT infrastrukturu itd., A krajnji korisnici postaju sve nervozniji oko značajki, opcija i nikad ne dovode u pitanje zadovoljstvo kupca .

U današnje vrijeme ‘Kvaliteta’ postaje presudni čimbenik u isporuci softvera, gdje se događaju stalna poboljšanja kako bi se poboljšala kvaliteta kako bi kupci bili zadovoljni.

Često primjećujemo da je čest problem gotovo svih Testera da budu pod strašnim pritiskom zbog toga što se njihov prozor za testiranje stisne i obično im se zgrada preda u posljednji trenutak na testiranje. Nema dovoljno vremena i resursa da izvrše sve testove koje su osmislili, a pokrivenost automatizacijom nije uvijek 100% i ima svoje izazove.

Rok isporuke ne može se propustiti, a istovremeno se ne može ugroziti i kvaliteta. Bez obzira na plan B, dodavanje dodatnih resursa za testiranje povlačenjem iz ostalih timova, ne uspijeva, plan C, prestanite raditi sve ostale aktivnosti i preusmjerite napor samo na ovo, zapravo ne pomaže. Međutim, dodavanje resursa za testiranje, na kraju, ne uspijeva.

Ne postoji druga opcija, već samo pokretanje ograničenih i važnih testova unutar raspoloživog vremena i resursa.

Pa, kako da odlučimo koji je test važan u ovoj fazi? Sve što Tester smatra važnim, možda nije stvarno važno za kupce. Iz čije se perspektive odlučuje o važnosti značajke ili funkcionalnosti? Tko će odlučiti koji su važni testovi? I mnoštvo drugih pitanja nastaju.

Kako bi se odgovorilo na sva ova pitanja i učinkovito riješilo gornju situaciju, pozvao se pristup testiranju ‘Ispitivanje temeljeno na riziku’ , kratko nazvano 'RBT' , nastao je, gdje je tim jasno planirao i identificirao scenarije ispitivanja na temelju kriterija „Projektni rizik“.

Iako QA tim ima jasnu sliku o važnim testovima, RBT je dokazana metoda identificiranja presudnih i važnih testova iz perspektive kupaca i poslovanja kroz 'Analiza rizika' postupak .

Dakle, u odnosu na tradicionalni način jednostavnog prepoznavanja nedostataka u softveru, pristup i cilj osiguranja kvalitete promijenili su se s vremenom zbog promjene tehnologije, povećanja konkurencije na tržištu za objavljivanje kvalitetnog softvera, uvođenja 'Automatizirajte sve', i sveukupno uvođenje Agile i DevOps prakse isporuke softvera tijekom nekoliko sati.

Stoga trenutni trend „Načela ispitivanja“ nije samo „identificiranje nedostataka“ već i

# 1) Usredotočite se na područje proizvoda gdje postoji veliki utjecaj na poslovanje zbog neuspjeha ili velike vjerojatnosti neuspjeha u proizvodnji.

#dva) Usredotočujući se na utvrđivanje nedostataka rano i dopuštajući timu da to popravi što je ranije moguće, a time i dopuštajući softver / proizvod ili značajku ‘Fail Fast’.

# 3) Sada je najvažniji aspekt usluge QA tima fokusiranje na kupca u donošenju vrijednosti za kupca povećavanjem fokusa na 'Iskustvo krajnjeg kupca'.

Pristup ispitivanja temeljenog na riziku

Uvijek je poput pripreme za ispit, ne može se reći da je testiranje dovoljno i da više nema nedostataka u softveru, čak i ako dizajniraju i izvrše velik broj testova.

Postoji točka u kojoj stabilnost softvera neće biti dvostruko osigurana povećanjem broja testnih slučajeva. U ovom se trenutku ne usredotočuje samo na broj testova, već na ono što kupac zapravo očekuje od izdanja.

Stoga je neophodno postići ravnotežu u optimizaciji testiranja kako bi se postigla maksimalna korist uz razuman napor testiranja. A ovo je važnije kada su rokovi testiranja vrlo uski i kad nema dovoljno resursa za provođenje dovoljnog testiranja.

Stoga, u ovom slučaju, RBT pristup igra ključnu ulogu u optimizaciji napora u osiguranju kvalitete i maksimiziranju koristi od testiranja uz minimalan poslovni rizik.

Dakle, ako se usredotočimo na gornji aspekt, rad QA-a bit će znatno rasterećen. Vikende ne moraju spaljivati ​​u uredu, kontinuirano testirajući softver i brinući se za sve nedostatke S4 (ozbiljnost 4) i P4 (prioritet 4) koji proizađu iz testiranja.

Pa, 4 se smatra najnižim prioritetom i težinom nedostataka u ispitivanju. Oni mogu bolje uložiti svoje vrijeme u druge korisne aspekte projekta.

Sažeti ključne pokretače pristupa 'Testiranje temeljeno na riziku':

• Omogućiti testiranje 'onoga što kupci žele' iz poslovne perspektive.
• Ispunjavanje vremenskog rasporeda s očekivanom kvalitetom.
• Za optimizaciju QA napora.

Kada koristimo RBT pristup?

To se koristi u sljedećim scenarijima:

• RBT pristup može se koristiti kad god postoji ograničenje ili ograničenje vremena, troškova i resursa projekta i kad god postoji potreba za optimizacijom resursa.
• RBT pristup koristi se kada je program složeniji i prilagođava novu tehnologiju te stoga uključuje puno izazova.
• Kada je program istraživačko-razvojni projekt i on je prve vrste, a u projektu postoji niz nepoznanica i rizika.

Primjer RBT pristupa

Nekoliko pristupa analizi zasnovanih na riziku koristi se u IT industriji za prevladavanje rizika s kojima se suočava proizvodnja i njezin utjecaj.

Dolje je dat jedan takav pristup:

Ovaj pristup RBT-a uključuje prepoznavanje ‘vitalnih funkcionalnosti ili ključnih značajki’ proizvoda i procjenu rizika kojima se svaka od ovih funkcionalnosti izlaže u proizvodnji te provedbu odgovarajućih mjera ublažavanja kako bi se rizik smanjio ili umanjio.

Stoga pristup RBT uključuje ispitivanje funkcionalnosti koje imaju vjerojatnost kvara i najveći utjecaj na poslovanje. Vrste kvarova mogu biti operativne ili poslovne, tehničke, vanjske itd.

Načini provođenja analize rizika

Ne postoji standardni postupak ili predložak definiran kao takav za provođenje analize rizika u testiranju softvera za svaku značajku proizvoda. Razne organizacije koriste vlastiti pristup metodama analize rizika.

Analiza rizika može se provesti na različitim projektnim stavkama kako bi se identificirali rizici i primijenio RBT pristup za analizu. Ti predmeti uključuju,

• Značajke
• Funkcionalnosti
• Korisničke priče
• Zahtjevi
• Koristite slučajeve
• Ispitni slučajevi

U ovom slučaju, usredotočimo se samo na test slučajeve kako bismo razumjeli primjenu pristupa testiranja temeljenog na riziku.

Postupak analize rizika

Analiza rizika uključuje uključivanje relevantnih dionika programa iz „ Tehnički tim i poslovni tim ’ , što uključuje vlasnika proizvoda, voditelje proizvoda, poslovne analitičare, arhitekte, testere i predstavnike kupaca.

Mogle bi se organizirati sesije mozga na kojima bi sudjelovali ti dionici kako bi se provela rasprava kako bi se utvrdila važnost svake značajke proizvoda i dalo im se prioritet na temelju rizika od neuspjeha i njegovog utjecaja na krajnje korisnike u proizvodnji.

Razni „projektni dokumenti“, kao što su dokument zahtjeva, dokumenti tehničkih specifikacija, dokumenti arhitekture i dizajna, dokument poslovnog procesa, dokument slučaja upotrebe, itd., Postat će ulazni podaci za sesiju mozga.

Znanje dionika o proizvodu i postojećem proizvodu na tržištu također će biti ulazni čimbenik za raspravu.

Nekoliko drugih izvora ulaznih podataka također može uključivati,

• Za prikupljanje podataka o najčešće korištenoj funkcionalnosti.
• Ulozi savjetovanja sa stručnjakom za domenu.
• Podaci iz prethodne verzije proizvoda ili sličnog proizvoda na tržištu.

Tijekom mozganje Utvrđuju se rizici koji se odnose na svaku od ovih značajki. Vrste rizika mogu biti operativne, tehničke ili poslovne. Ispitivanja i scenariji povezani s njima ponderirani su i vrijednosti rizika procjenjuju se na temelju vjerojatnosti nastanka rizika i utjecaja rizika.

'Vjerojatnost pojave rizika' može biti posljedica:

• Loše razumijevanje značajke od strane tima za razvoj proizvoda.
• Nepravilna arhitektura i dizajn.
• Nedovoljno vremena za dizajn.
• Nesposobnost tima.
• Neadekvatni resursi - ljudi, alati i tehnologija.

'Učinak rizika' učinak je neuspjeha na korisnike i poslovanje ako se dogodi. Utjecaj bi mogao biti,

• Utjecaj troškova, što rezultira gubitkom.
• Učinak na poslovanje koji rezultira gubitkom posla ili gubitkom tržišnog udjela, pravni postupci, gubitak licence.
• Učinak na kvalitetu, što rezultira ispuštanjem nekvalitetnog ili nesposobnog proizvoda.
• Loše korisničko iskustvo, što rezultira nezadovoljstvom i gubitkom kupca.

Područje fokusa procjene rizika značajke ili proizvoda može biti,

• Područje poslovne kritičnosti funkcionalnosti.
• Najčešće korištene značajke i važne funkcije.
• Područja sklona oštećenjima
• Funkcionalnost koja utječe na sigurnost i sigurnost.
• Područje složenog dizajna i arhitekture.
• Promjene izvršene u odnosu na prethodne verzije.

Metodologija analize rizika

Dajmo sada detaljno razumjeti 'Metodologiju ispitivanja temeljenu na riziku'.

Pristup testiranja zasnovan na riziku koristi RIZIK kao kriterij u svim fazama ispitivanja ciklusa ispitivanja, tj. planiranje ispitivanja , dizajn testa, provedba testa, izvršenje testa i izvještavanje o testovima. U idealnom slučaju može se dizajnirati veliki broj mogućih kombinacija scenarija ispitivanja.

Stoga pristup RBT uključuje rangiranje testova na temelju ozbiljnosti rizika kako bi se otkrilo najviše neispravno ili rizično područje neuspjeha, što uzrokuje velik utjecaj na poslovanje.

Glavni cilj analize rizika je razlikovanje između 'Visoka vrijednost' stavke poput značajki proizvoda, funkcionalnosti, zahtjeva, korisničke priče , i test slučajevi, i Niska vrijednost ' one, a time i kasnije, da bi se više usredotočili na test slučajeve 'visoke vrijednosti', manje se fokusirajući na ispitne slučajeve 'male vrijednosti'. Ovo je početni korak analize rizika prije početka ispitivanja temeljenog na riziku.

Glavni zadatak kategorizacije ili grupiranja test slučajeva u visoku i nisku vrijednost i dodjeljivanje vrijednosti prioriteta svakom od ovih testnih slučajeva uključuje sljedeće korake:

Korak # 1) Korištenje mreže 3X3

Analiza rizika provodi se pomoću mreže 3X3, gdje tim dionika procjenjuje svaku funkcionalnost, nefunkcionalnost i s njima povezane ispitne slučajeve zbog „Vjerojatnostneuspjeha ’i‘ Učinak neuspjeha ’.

Vjerojatnosti kvara svake funkcionalnosti u proizvodnji općenito pristupa skupina 'Tehničkih stručnjaka' i kategorizirana je kao 'Vjerojatno će propasti, vrlo vjerojatno i malo vjerojatno' duž vertikalne osi mreže.

besplatno čišćenje sustava za Windows 7

Slično tome, krajnji kupac iskusi „učinak neuspjeha“ ovih značajki i funkcionalnosti u proizvodnji, ako ih se ne testira, procjenjuje skupina ' Poslovni stručnjaci 'i svrstani su u kategorije' Manji, vidljivi i prekidi 'duž vodoravne osi mreže.

Korak # 2) Vjerojatnost i utjecaj neuspjeha

Svi ispitni slučajevi smješteni su u kvadrante mreže 3 X 3 na temelju utvrđenih vrijednosti vjerojatnosti kvara i utjecaja kvara koji su prikazani kao točke na donjoj slici.

Očito su velika vjerojatnost kvara i veliki utjecaj kvara (prekida) grupirani u gornjem desnom kutu mreže, što je od velike važnosti, pa je stoga utvrđeno da su testovi 'visoke vrijednosti' i testovi 'niske vrijednosti' grupirani u donji lijevi kut koji je za kupca od najmanjeg ili nikakvog značaja, pri čemu se ove značajke ili testni slučajevi mogu malo usredotočiti.

Korak # 3) Testiranje prioritetne mreže

Na temelju gornjeg pozicioniranja test slučajeva u mreži, testovi su prioritetni i označeni prioritetima 1,2,3,4 i 5 i označeni su sa svakim od njih. Najvažniji testovi smješteni su u 1^svmreže koje su dodijeljene s prioritetom 1, a slično manje važne rangirane su kao 2, 3, 4 i 5.

Konačno, svi se testni slučajevi sortiraju na temelju njihovih brojeva prioriteta i preuzimaju se na izvršenje redoslijedom prioriteta. Oni s visokim prioritetom prvo se podižu na izvršenje, a oni s niskim prioritetom izvršavaju se kasnije ili se uklanjaju iz okvira.

Korak # 4) Pojedinosti ispitivanja

Sljedeći je korak odluka o razini detalja ispitivanja za definirani opseg ispitivanja. Dubina opsega ispitivanja može se odrediti na temelju gornjeg poretka prema donjoj mreži.

Ispitivanja visokog prioriteta s rangom 1 testirana su „Temeljito“, pa su prema tome angažirani stručnjaci koji će testirati ove značajke visoke kritičnosti i s njima povezane slučajeve ispitivanja. Slično tome, mogu se donijeti slučajevi s prioritetima 2, 3 i 4. Odluka o oduzimanju značajki i testova prioriteta 5 na temelju raspoloživog vremena i resursa.

Stoga pristup razine detaljnosti ispitivanja određivanju prioriteta značajki i njegovih testnih slučajeva ne samo da pomaže testerima da identificiraju 'testove visoke vrijednosti', već ih vodi i da odluče o svojoj 'detaljnoj razini testiranja' na temelju tih rangiranja prioriteta i pomaže im u boljem provođenju ispitivanja i smanjuje troškove ispitivanja postupkom optimizacije.

Kako je RBT relevantan za Agile i DevOps?

Sada, nakon razumijevanja pristupa ispitivanja temeljenog na riziku provođenja ispitivanja na temelju određivanja prioriteta testova, ovisno o 'riziku od neuspjeha' određene značajke i njegovom 'utjecaju na kupca' uživo, očito bi se postavilo pitanje relevantnost pristupa ispitivanja temeljenog na riziku u agilnim i DevOps praksama.

'Automatiziraj sve', 'Testiraj sve', 'Neprekidno testiraj', 'Testiraj više puta' ključni su pojmovi ovih praksi.

Svaki put, kada dođe do promjene koda ili kada dođe do izdanja, svi dizajnirani testovi prolaze se automatizirano Kontinuirana integracija (CI) / Kontinuirana isporuka (CD) cjevovoda brzo i opetovano, bez obzira na prioritet.

Kakva je onda veza između RBT-a i DevOps-a? Gdje bi se RBT uklopio i postao relevantan u Agileu i DevOpsu ???

# 1) Da, kao što sam rekao ranije, nije da svaka industrija i svaki proizvod imaju 100% pokrivenost automatizacijom za svoja pokusna izvršavanja. Dakle, ako tim uopće mora odabrati odabir prioriteta za provođenje testa od izbora ručnih ispitnih slučajeva i želi uštedjeti energiju i napor testnih resursa za druge aktivnosti, tada je RBT najbolji izbor.

Pristup temeljen na riziku također je bolja opklada za izvođenje automatiziranih testova s ​​onima s visokim prioritetom i za testiranje najranije.

#dva) QA tim može učinkovitije usvojiti RBT pristup tijekom Analize zahtjeva u analizi zahtjeva i pružanju prethodnog izvješća o vjerojatnim rizicima proizvoda i značajki kako bi programski tim mogao proaktivno poduzeti odgovarajuće radnje kako bi ga ublažio.

# 3) RBT pristup može se učinkovito koristiti u dizajniranju test slučajeva i scenarija temeljenih na visokom riziku, tako da se veći fokus može posvetiti visoko rizičnim značajkama i funkcionalnostima.

# 4) Prepoznavanje područja s „visokim rizikom“ omogućuje QA timu da svoj napor testiranja usmjeri na ta područja kako bi testirao „temeljitije“ pomoću „visokokvalificiranih testera“.

# 5) 'Fail Fast', kao što svi znamo, koncept je 'Agile' i 'DevOps', za koji RBT pristup pomaže identificirati područja 'visokog rizika' u softveru, rano prepoznati nedostatke i omogućiti im brzi i neuspjeh prvo i neka tim popravi.

# 6) Krajnji cilj Agile / DevOps-a je 'Usredotočenost na kupca' i stoga RBT pristup omogućuje QA-u da se usredotoči na iskustvo korisnika, a ne samo na pronalaženje nedostataka.

Prednosti pristupa ispitivanja temeljenog na riziku

Već smo razumjeli svrhu i upotrebu RBT pristupa analizi zahtjeva, dizajniranju i izvršavanju scenarija ispitivanja. Nekoliko je prednosti RBT-a.

Prednosti testiranja na temelju rizika možemo konsolidirati i navesti kao:

• Pomaže u učinkovitijem i optimiziranom korištenju testnih resursa.
• Pomaže u olakšavanju rada na osiguranju kvalitete, testiranju, dizajnu i razvoju testova te aktivnostima u pripremi ispitivanja određivanjem prioriteta.
• Pomaže u boljem upravljanju QA resursima raspoređivanjem ključnih resursa prema područjima s visokim fokusom.
• Pomaže u učinkovitom korištenju resursa i usmjerava njihovo vrijeme i energiju na bolje stvari u projektu.
• Pomaže QA timu u planiranju napora na ispitivanju na temelju procjene rizika i identifikacije nestabilnih i visoko rizičnih područja.
• Pomaže timu da optimizira testove koji će se provoditi, ovisno o važnosti, a time i smanjuje opseg testova male vrijednosti u dogovoru sa dionicima.
• Sveukupno pomaže u smanjenju troškova kroz optimizirane i smanjene aktivnosti testiranja.
• RBT pristup omogućuje QA timu da prvo testira područja s visokim rizikom, a omogućuje proizvodu da brzo otkaže i brzo popravi.
• RBT pristup pomaže u uvođenju jasnoće u „ Obuhvat testom i 'Opseg ispitivanja' za cijelu skupinu dionika.
• Tim se može usredotočiti na područja s visokim rizikom, a manje se fokusirati na područja s niskim rizikom.
• RBT omogućuje timu da unaprijed odluči o provedbi najučinkovitijeg načina ublažavanja rizika proizvoda.
• RBT pomaže u izbjegavanju učinka neprimjerene provedbe ublažavanja.
• Ispitivanje temeljeno na riziku omogućuje timu da poduzme odgovarajuće mjere ili za ublažavanje ili za planiranje nepredviđenih slučajeva ili za postavljanje bilo kakvih zaobilaznih rješenja kako bi se prevladao kvar ili smanjio njegov utjecaj ako se rizik pojavi u programu Live.
• RBT pomaže u smanjivanju rezidualnog rizika u ispuštanju.
• Pomaže u postizanju 'poboljšane kvalitete' kroz jeftinije nedostatke u proizvodnji.
• U konačnici pomaže u ‘Poboljšanom iskustvu kupaca’ i ‘Zadovoljnom kupcu’.

Zatim ćemo naučiti kako upravljati rizicima u fazama planiranja i izvršavanja ispitivanja životnog ciklusa testiranja softvera.

Upravljanje rizikom tijekom planiranja ispitivanja

Kako upravljati rizicima tijekom faze planiranja testa:

Život je pun rizika, a takav je i softverski projekt. Sve može poći po zlu bilo kad. Uvijek smo na putu da ispravimo stvari - ali što je s tim da pazimo da ništa ne krene po zlu i da kad to točno znamo što učiniti? Uđite u upravljanje rizikom - ovo je dio projekta testiranja softvera koji nas priprema za sprečavanje, razumijevanje, pronalaženje i prevladavanje rizika.

Rizik je jednostavno problem koji će se vjerojatno dogoditi, a kad se dogodi, uzrokovat će gubitak.

Gubitak može biti bilo što - novac, vrijeme, trud ili kompromis u kvaliteti. Gubitak nikad nije dobar. Bez obzira koliko ga okretali, to nije pozitivno - i nikada neće biti. Stoga Upravljanje rizicima sastavni je dio softverskih projekata kako bismo osigurali da se nosimo s rizicima i spriječimo / smanjimo gubitke.

Ispitivanje temeljeno na riziku : Budući da smo QA zajednica, budimo specifični za rizike i procese povezane s njima isključivo u našem QA svijetu. Rizici se procjenjuju i njima se upravlja u dvije faze Životni ciklus ispitivanja softvera . STLC se može svrstati u 3 faze - planiranje ispitivanja, projektiranje ispitivanja i izvršavanje ispitivanja.

Proces upravljanja rizikom događa se dva puta, tijekom:

1. Planiranje ispitivanja
2. Dizajn test slučaja (kraj) ili ponekad u fazi izvršenja testa

Obavezan je u slučaju 1, ali u slučaju 2 to je više situacija 'na osnovi potrebe'.

Dvodijelna serija članaka:

Iako je temeljni postupak isti, vrste rizika obrađena u oba ova područja potpuno su različita. Da bismo im pojedinačno ukazali pravdu, postupati ćemo s njima različito kao dvodijelne serije.

Ovaj će odjeljak biti o 'Upravljanje rizikom tijekom planiranja ispitivanja'.

Proces upravljanja rizikom

Generički postupak za upravljanje rizikom uključuje 3 važne faze:

1. Identifikacija rizika
2. Analiza utjecaja rizika
3. Ublažavanje rizika

Primjeri ispitivanja rizika i ublažavanja:

# 1) Identifikacija rizika

Kao što je rečeno, prvi korak u rješavanju problema je njegovo identificiranje. Ova faza uključuje izradu popisa svega što bi potencijalno moglo iskrsnuti i poremetiti normalan tijek događaja.

Glavni ishod ovog koraka je popis rizika.

Ovim korakom ispitivanja temeljenim na riziku obično rukovodi voditelj / menadžer / predstavnik za osiguranje kvalitete. Međutim, sam voditelj neće moći doći do cijelog popisa - cjelokupni doprinos QA tima ima ogroman utjecaj. Možemo reći da je ovo kolektivna aktivnost koju vodi QA voditelj.

Također, rizici koji su identificirani tijekom faze planiranja testa više su 'upravljački' u orijentaciji, što znači da ćemo pogledati sve što bi moglo utjecati na raspored, napor, proračun, infrastrukturne promjene QA projekta. Fokus je ovdje ne AUT, već način na koji će QA faza ići dalje.

Rizici tijekom planiranja ispitivanja: Primjeri ispitivanja temeljenih na riziku

Slijedi uzorak popisa rizika koji bi mogli biti navedeni tijekom faze planiranja ispitivanja. Imajte na umu da AUT i njegova funkcionalnost ovdje nisu fokus.

1. Raspored ispitivanja je strog. Ako je početak testiranja odgođen zbog projektnih zadataka, test se ne može produžiti nakon zakazanog datuma početka UAT-a.
2. Nema dovoljno resursa, resursi se ukrcavaju prekasno (postupak traje oko 15 dana.)
3. Defekti se nalaze u kasnoj fazi ciklusa ili u kasnoj fazi; kasno otkriveni nedostaci najvjerojatnije su posljedica nejasnih specifikacija i njihovo je rješavanje dugotrajno.
4. Opseg nije definiran u potpunosti definiran
5. Prirodne katastrofe
6. Neraspoloživost Independenta Test okruženje i pristupačnost
7. Odgođeno testiranje zbog novih izdanja

U ovom trenutku možete odlučiti biti temeljiti koliko god želite, ovisno o raspoloživom vremenu.

Jednom kad su navedeni svi rizici, prelazimo na procjenu rizika / analizu utjecaja rizika.

# 2) Procjena rizika / Analiza utjecaja rizika

Je li vaša Analiza rizika nešto slično? :)

Analiza rizika u testiranju softvera : Svi su rizici kvantificirani i prioritetni u ovom koraku. Vjerojatnost svakog rizika (vjerojatnost nastanka) i utjecaj (iznos gubitka koji bi prouzročio kada se taj rizik ostvari) utvrđuju se sustavno.

Visoka - srednje niska , vrijednosti se dodjeljuju i vjerojatnosti i utjecaju svakog rizika. Prvo se rješavaju rizici s 'velikom' vjerojatnošću i 'velikim' utjecajem, a zatim slijedi redoslijed.

Tablica analize utjecaja rizika:

Slijedom ovih koraka, tablica analize utjecaja za gore navedene rizike izgledala bi otprilike ovako (sve su vrijednosti hipotetičke i samo u svrhu razumijevanja):

# 3) Ublažavanje rizika

Posljednji korak u ovom postupku testiranja na temelju rizika (RBT) jest pronaći rješenja za planiranje postupanja u svakoj od ovih situacija. Ti se planovi mogu razlikovati od tvrtke do tvrtke, od projekta do projekta, pa čak i od osobe do osobe.

Tehnike ublažavanja rizika:

Evo primjera u što se pretvara tablica rizika kada je ova faza završena:

Nekoliko napomena:

1. Što prije upravljanje rizikom započne u fazi planiranja osiguranja kvalitete, to bolje.
2. Od sva 3 koraka, Identifikacija rizika je najvažnija . Ako nešto nije navedeno i razmotreno za daljnje korake, rizik se ne rješava.
3. Pokušajte pronaći idealan vremenski okvir za ovu aktivnost. Zapamtite, previše planiranja ostavlja premalo vremena za obavljanje.
4. Također, nakon postupka upravljanja rizikom, ako se pojavi nova situacija, plan upravljanja rizikom može se izmijeniti ili ažurirati tako da odražava najnovije stanje.
5. Povijesni podaci može biti vrlo korisno za uspjeh ovog procesa.

Zaključak

To nas dovodi do kraja upravljanja rizicima u fazi planiranja ispitivanja. Iako su temeljni koraci i principi slični, postupak upravljanja rizikom koncentriran je na AUT kada se to dogodi u fazi projektiranja / izvršenja testa.

U sljedećem ćemo odjeljku pokriti - Upravljanje rizicima u fazi izvršavanja testa.

Upravljanje rizikom u fazi izvođenja testa (s primjerom)

Na našem putu ka razumijevanju procesa upravljanja rizikom razgovarali smo o tome kako on ide isključivo u Faza planiranja ispitivanja ispitivanja temeljenog na riziku . Također smo razumjeli generički postupak koji uključuje - identifikaciju rizika, procjenu rizika i plan ublažavanja rizika.

Kako upravljati rizikom u fazi projektiranja ili izvođenja testa:

Postoji još jedan oblik Upravljanje rizicima (također se ponekad naziva i, Ispitivanje temeljeno na riziku ) koji se javlja tijekom izrade testa ili faze izvođenja testa, ovisno o situaciji. Sada, o kojoj situaciji govorimo? Pokušajmo to prvo razumjeti.

Svi znamo da je naš rad na testiranju reaktivan. Nema zahtjeva (ili opsega nije definirano), ne možemo izvršiti analizu izvedivosti i napisati scenarije ispitivanja niti planirati aktivnosti ispitivanja.

Slično tome, kada kôd nije spreman, nemamo što testirati, bez obzira na to koliko pripremnih radnji bismo mogli biti spremni u okviru test slučajeva, podataka testa itd. Također, testiranje je jedini preostali korak prije nego što proizvod krene uživo.

Upravljanje rizikom - s naglaskom na AUT

Shvatimo to bolje na primjeru:

Ako bi testiranje trebalo započeti navedenog datuma, 1. siječnja^svi morao je nastaviti do 14. siječnja^th- kada je testiranje završeno, datum pokretanja proizvoda obično se utvrđuje odmah. Recimo - 15. siječnja^thradi jednostavnosti. U savršenom svijetu stvari bi se odvijale točno onako kako su planirali. Ali svi znamo stvarnost.

U ovom slučaju, pretpostavimo da testiranje iz nekog razloga nije započelo sve do 7. siječnja^th, što znači da smo izgubili pola vremena za testiranje. No, treba nam 14 dana da temeljito testiramo proizvod. Datum pokretanja mogli bismo pomaknuti za 7 dana dalje - međutim; to obično nije opcija. Budući da se proizvod obećava na tržištu određenog datuma, a kašnjenja nisu dobra za posao.

Stoga, obično ispitni timovi moraju apsorbirati kašnjenja, nekako nadoknaditi, raditi s raspoloživim vremenom i osigurati da je proizvod dobro testiran. Težak posao, zar ne?

Tu se ponovno primjenjuje postupak upravljanja rizicima.

• Sad, ako kašnjenja se očekuju prije vremena prije nego što i testiranje započne - postupak se odvija u fazi izrade testa.
• Ako kašnjenja se događaju tijekom Faza izvršavanja testa koji je započeo normalno - postupak se slijedi tijekom faze izvođenja testa.
• Koraci i metoda su isti bez obzira u kojoj se fazi dogodili.

Koji je postupak?

Upravljanje rizikom odvija se kako bi se utvrdilo na koja područja AUT-a (aplikacija koja se testira) trebaju biti maksimalno fokusirani. To su obično funkcionalna područja (moduli ili komponente) koja su presudna za uspjeh konačnog proizvoda i koja su najotpornija na neuspjeh.

koliko košta tost pos

Pročitajte također=> Analiza načina neuspjeha i učinaka (FMEA) tehnika je upravljanja rizikom

Tko to izvodi?

Budući da se tiče AUT-a, znanje o njemu nije samo s QA-om već i sa svim ostalim timovima - Dev, BA, klijentima, timovima za upravljanje projektima itd. Stoga je to kolektivni napor koji pokreće ispitni tim.

Kako se odvija testiranje osnova rizika?

Korak 1) Identifikacija rizika

Identificirajte sva funkcionalna područja AUT. To će jednostavno uključivati ​​izradu popisa.

Korak 2) Procjena rizika

Svi se rizici u ovom koraku kvantificiraju i daju im prioritet. Kvantificiranje je jednostavno dodjeljivanje broja svakom riziku na popisu koji će dati naznaku prioriteta s kojim se treba pozabaviti.

Odlučuju se vjerojatnost svakog rizika (šansa za nastanak) i utjecaj (iznos gubitka koji bi mogao prouzročiti kada se taj rizik ostvari).

Tipična metoda je dodjeljivanje ocjena. Na primjer, Vjerojatnost može poprimiti vrijednosti 1 do 5. 1 koja je vjerojatnost pojave niska (vjerojatno se uopće neće dogoditi), a 5 velika (to će se sasvim sigurno dogoditi).

Slično tome, Impactu se također može dodijeliti ocjena 1-5. 1 je slab utjecaj (čak i ako se taj rizik ostvari, gubitak je minimalan), a 5 velik utjecaj (ogromni gubici kad se dogode).

Korak # 3)

Napravite format tablice i distribuirajte svim predstavnicima timova - Dev, BA, Client, PM, QA i bilo kome drugom relevantnom.

Korak # 4)

Uputite svaki tim da popuni vrijednosti na temelju njihove ocjene vjerojatnosti i utjecaja.

Budući da su vrijednosti vjerojatnosti i utjecaja numeričke, to će olakšati izračunavanje vrijednosti 'faktora rizika'.

Faktor rizika = Vjerojatnost X Utjecaj. Što je veći faktor rizika, to je ozbiljan problem.

Primjer:

Napominjemo da je u ovom trenutku ovo jednostavno rezultat ocjene jedne momčadi. Za projekt u kojem je uključeno 5 različitih timova, QA tim bi na kraju imao 5 različitih tablica.

Korak # 5)

Uzmite prosjek vrijednosti faktora rizika. Na primjer, ako postoji 5 timova, za svaki modul dodajte sve vrijednosti faktora rizika i podijelite ih s 5. To su konačne vrijednosti s kojima ćemo se nositi. Recimo, ovo su prosječni faktori rizika:

Što je veći faktor rizika, to se taj modul mora više testirati.

Dakle, moduli 5 i 2 najvažniji su za uspjeh poslovanja. Podijelite rezultate sa svim timovima.

Korak # 6)

Plan ublažavanja rizika : Ovo je korak koji se mijenja od projekta do projekta. Utvrdili smo da su moduli 5 i 2 oni na koje se treba koncentrirati.

Primjeriplana može biti:

1. Moduli 5 i 2 temeljito će se testirati osiguravajući da su testirani svi test slučajevi povezani s njima. Ostali moduli bit će testirani na istraživačkoj osnovi.
2. Prvo će se testirati moduli 5 i 2, a zatim će se, ovisno o raspoloživom vremenu, pobrinuti za ostale.

Nakon izrade plana, svi timovi postižu dogovor i slijede ga kako bi testirali proizvod vodeći računa o rizičnom faktoru.

To je to!

Nekoliko važnih napomena:

• Budući da je ovo kolektivna aktivnost koja traje svačije mišljenje u obzir ; veće su šanse da bude točan i učinkovit.
• Ovo je a ne formalna metoda i ne mora biti dio svakog QA projekta.
• Ponekad, čak i ako se tim odluči ne crtati tablice i ne dodjeljivati ​​vrijednosti - a jednostavna ideja o mozganju sa svima prisutnima može QA timu dati dobre upute kako postupati.
• The doprinos razvojnog tima je vrlo važno jer su oni ti koji stvaraju proizvod, pa će znati što bi moglo raditi i što bi moglo trebati dodatnu provjeru. Svakako budite u potrazi za tim.
• Iako postoji više koraka u procesu, ne treba im znatna količina vremena . Pogotovo, ako svi timovi mogu sjediti zajedno i istovremeno raditi.
• Zapamtite ovaj proces i njegov ishod je samo alternativa . Dobivanje toliko vremena koliko je planirano za testiranje najbolji je način za provođenje QA aktivnosti.

Zaključak

Pristup ispitivanju temeljenom na riziku jasno ukazuje na to da fokus ispitivača nije samo na neprestanom istraživanju nedostataka, bez obzira na ozbiljnost i prioritet. Sad su se stvari promijenile i testeri moraju raditi pametno i moraju razumjeti jasnu 'Potrebu kupca i Želje korisnika'.

Moraju temeljito proučiti proizvod i shvatiti koja je najčešće korištena značajka u proizvodnji, što je najkritičniji put za stvaranje prihoda i kako zaštititi i zaštititi kupce od problema s proizvodnjom i poslovnih prijetnji.

Stoga pristup RBT jasno educira 3 testera da samo testiranje svega ili opsežno testiranje ne znači da je testiranje završeno ili da na proizvodu nema nedostataka. Učinkovito testiranje u predviđenom vremenu i osiguravanje poništavanja kritičnih i glavnih poslovnih utjecaja, a to je vrlo važno za ispitivača.

Stoga je testiranje temeljeno na riziku najučinkovitiji alat za QA tim koji vodi dionike projekta na temelju projektnih rizika. RBT pristup pomaže QA timu u kontinuiranoj identifikaciji rizika i njegovom rješavanju koji mogu ugroziti postizanje ukupnih ciljeva i ciljeva projekta te pomaže u postizanju krajnjeg cilja QA Grupe.

p.s. Riječi QA i Testiranje naizmjenično su korištene u cijelom dokumentu.

O autoru: Ovaj su članak napisali više članova STH tima - Gayathri Subrahmanyam i Swati S.

Gayathri je MSP softversko testiranje s više od desetljeća iskustva u testiranju softvera i opsežno je usvojio pristup 'Testiranje temeljeno na riziku' kao dio Test industrijalizacije u nekoliko angažmana te je shvatio korist testiranja optimizacije resursa i ispitivanja kvalitete.

Je li vam testiranje temeljeno na riziku bilo izazovno? Imate li zanimljivih činjenica koje biste mogli dodati u naš vodič? Slobodno iznesite svoje misli u odjeljku za komentare ispod !!

=> Posjetite ovdje za cjelovitu seriju vodiča za plan ispitivanja

Preporučena literatura

• Kontinuirani proces integracije: kako poboljšati kvalitetu softvera i smanjiti rizik
• Analiza načina neuspjeha i efekata (FMEA) - Kako analizirati rizike za bolju kvalitetu softvera i zadovoljne kupce!
• Vrhunski vodič za testiranje na temelju rizika: Upravljanje rizicima u testiranju softvera
• 10 najboljih alata i tehnika za procjenu i upravljanje rizikom
• Vrste rizika u softverskim projektima
• Neka zanimljiva pitanja za ispitivanje softverskog testiranja
• Odabir testiranja softvera za vašu karijeru
• Povratne informacije i kritike o tečaju softverskog testiranja