Vrhunski priročnik za testiranje na podlagi tveganj: obvladovanje tveganj pri testiranju programske opreme

ultimate guide risk based testing

Končni vodnik za testiranje na podlagi tveganj, obvladovanje tveganja in njegov pristop s primeri:

Kaj je testiranje na podlagi tveganja?

Testiranje na podlagi tveganj je izvedba preskusov ali načrtovanje in izvedba scenarijev, tako da se največja poslovna tveganja, ki bodo negativno vplivala na poslovanje, kot jih ugotovi kupec, odkrijejo v njihovem izdelku ali značilnosti v zgodnjem življenjskem ciklu in so z ublažitvijo ukrepov.

=> Kliknite tukaj za celotno serijo vadnic o načrtu preizkusov

Negativni vpliv lahko vključuje vpliv na stroške, nezadovoljno stranko, slabo uporabniško izkušnjo in celo do izgube strank.

Z drugimi besedami, pristop RBT je zagotoviti, da se testiranje opravi tako, da tudi če je uporabnik najde hrošča v proizvodnji mu to ne preprečuje uporabe programske opreme ali ne vpliva resno na poslovanje.

RBT se testira na podlagi tveganj za izdelke. RBT je treba ugotoviti že vnaprej, kaj je tveganje za neuspeh določene funkcije ali funkcionalnosti v proizvodnji in njen vpliv na poslovanje v smislu stroškov in druge škode z uporabo tehnike določanja prednosti za testne primere.

Zato testiranje na podlagi tveganj uporablja načelo dajanje prednosti preskusom funkcij, modulov in funkcionalnosti izdelka ali programske opreme. Prednostno razvrščanje temelji na tveganju verjetnosti okvare te funkcije ali funkcionalnosti v proizvodnji in njenem vplivu na kupce.

Kaj se boste naučili:

• Testiranje na podlagi tveganj in njegova pomembnost za agilne in razvojne programe
  • Pristop preskušanja na podlagi tveganj
    • Kdaj uporabimo pristop RBT?
    • Primer pristopa RBT
  • Načini za izvedbo analize tveganja
  • Postopek analize tveganja
  • Metodologija analize tveganja
    • Korak # 1) Uporaba mreže 3X3
    • 2. korak) Verjetnost in vpliv okvare
    • 3. korak) Testiranje prednostne mreže
    • 4. korak) Podrobnosti testiranja
  • Kako je RBT pomemben za Agile in DevOps?
  • Prednosti pristopa testiranja na podlagi tveganj
• Obvladovanje tveganja med načrtovanjem preskusov
  • Postopek obvladovanja tveganj
    • # 1) Ugotovitev tveganja
    • # 2) Ocena tveganja / analiza vpliva
    • # 3) Zmanjšanje tveganja
  • Zaključek
• Obvladovanje tveganja v fazi izvedbe preizkusa (s primerom)
  • Obvladovanje tveganj - s poudarkom na AUT
  • Kako poteka testiranje podlag tveganja?
  • Zaključek
  • Priporočeno branje

Testiranje na podlagi tveganj in njegova pomembnost za agilne in razvojne programe

Tristo ur, porabljenih za razvoj programske opreme, lahko v samo 30 sekundah postane neuporabnih z eno samo napako, ugotovljeno v proizvodnji.

To pa lahko uniči namen celotnega izdelka brez druge možnosti, temveč samo umik s trga. In to je pomen in potreba po 'preskušanju kakovosti'.

S hitro rastjo tehnologije programska oprema gostuje v oblaku in podpira več operacijskih sistemov, več platform, zapletene IT infrastrukture itd., Končni uporabniki postajajo vse bolj moteči glede funkcij, možnosti in nikoli ne ogrožajo zadovoljstva strank .

Dandanes 'Kakovost' postaja ključni dejavnik pri dobavi programske opreme, kjer se nenehno izboljšujejo, da bi izboljšali kakovost, da bi bili kupci zadovoljni.

Pogosto opazimo, da je pogosta težava skoraj vseh preizkuševalcev, da so pod izrednim pritiskom, da je njihovo okno za preizkušanje stisnjeno in da jim je gradnja v zadnjem trenutku predana v testiranje. Zanje ni dovolj časa in virov za izvajanje vseh testov, ki so jih zasnovali, pokritost avtomatizacije pa ni vedno 100-odstotna in ima svoje izzive.

Časovne dobave ni mogoče zamuditi, hkrati pa tudi kakovosti. Ne glede na načrt B dodajanje dodatnih testnih virov z izvlečenjem iz drugih ekip ne deluje, načrt C, prenehanje izvajanja vseh drugih dejavnosti in preusmeritev truda samo na to, v resnici ne pomaga. Vendar se dodajanje testnih virov na koncu ne obnese.

Ni druge možnosti, kot samo izvajanje omejenih in pomembnih testov v razpoložljivem času in virih.

Kako se torej odločimo, kateri test je v tej fazi pomemben? Karkoli se testerju zdi pomembno, za stranke morda ni resnično pomembno. Iz čigave perspektive se odloča o pomembnosti funkcije ali funkcionalnosti? Kdo bo odločil, kateri so pomembni testi? Še vedno se poraja veliko drugih vprašanj.

Da bi odgovorili na vsa ta vprašanja in učinkovito rešili zgornjo situacijo, je bil potreben preskusni pristop „Testiranje na podlagi tveganj“ , v kratkem poklicano 'RBT' , kjer je ekipa jasno načrtovala in opredelila testne scenarije na podlagi meril „Project Risk“.

Čeprav ima ekipa QA jasno sliko pomembnih testov, je RBT preizkušena metoda za ugotavljanje ključnih in pomembnih testov s stališča kupcev in podjetij s pomočjo „Analiza tveganja“ postopek .

Torej, v primerjavi s tradicionalnim načinom preprostega prepoznavanja napak v programski opremi, se je pristop in cilj QA s časom spremenil zaradi spremembe tehnologije, povečanja konkurence na trgu za izdajo kakovostne programske opreme, uvedbe 'Automate Everything' in v celoti uvedba Agile in DevOps prakse dobave programske opreme v nekaj urah.

Zato sedanji trend „načela testiranja“ ni zgolj „prepoznavanje napak“, temveč tudi

# 1) Osredotočite se na področje izdelka, kjer ima velik vpliv na poslovanje zaradi neuspeha ali velike verjetnosti okvare v proizvodnji.

#two) Osredotočanje na prepoznavanje napak zgodaj in dovoli ekipi, da jo popravi čim prej in s tem omogoči programsko opremo / izdelek ali funkcijo ‘Fail Fast’.

# 3) Najpomembnejši vidik storitve ekipe QA je osredotočanje na kupca pri doseganju vrednosti za kupca s povečanjem osredotočenosti na „Izkušnja od konca do konca“.

Pristop preskušanja na podlagi tveganj

Vedno je tako, kot da bi se pripravili na izpit, saj ne moremo trditi, da je testiranje dovolj in da programska oprema nima več napak, tudi če načrtujejo in izvedejo veliko število testov.

Obstaja točka, pri kateri samo s povečanjem števila testnih primerov stabilnosti programske opreme ne bo mogoče zagotoviti dvojno. V tem trenutku se ne osredotočamo le na število testov, temveč na to, kaj stranka dejansko pričakuje od izdaje.

Zato je bistvenega pomena najti ravnovesje pri optimizaciji testiranja, da bi z razumnim naporom testiranja dosegli največjo korist. In to je bolj pomembno, če so časovni roki testiranja zelo tesni in ni na voljo dovolj virov za izvedbo zadostnega testiranja.

Tako ima v tem primeru pristop RBT ključno vlogo pri optimizaciji prizadevanj za zagotavljanje kakovosti in maksimiranju koristi testiranja z minimalnim poslovnim tveganjem.

Torej, če se osredotočimo na zgornji vidik, bo delo preverjanja kakovosti zelo olajšano. Konec tedna jim ni treba kuriti v pisarni, nenehno preizkušajo programsko opremo in se zaskrbijo zaradi vseh napak S4 (resnost 4) in P4 (prednost 4), ki izhajajo iz testiranja.

No, 4 se šteje za najnižjo prioriteto in resnost napak pri testiranju. Svoj čas lahko bolje vlagajo v druge koristne vidike projekta.

Če povzamemo ključne dejavnike pristopa „testiranja na podlagi tveganj“:

• Omogočiti testiranje 'kaj si stranke želijo' s poslovnega vidika.
• Da izpolnimo časovni razpored s pričakovano kakovostjo.
• Za optimizacijo prizadevanj za zagotavljanje kakovosti.

Kdaj uporabimo pristop RBT?

To se uporablja v spodnjih scenarijih:

• Pristop RBT je mogoče uporabiti, kadar obstajajo omejitve ali omejitve glede časa, stroškov in virov projekta, in kadar koli je treba optimizirati vire.
• Pristop RBT se uporablja, kadar je program bolj zapleten in prilagaja novo tehnologijo, zato vključuje veliko izzivov.
• Kadar je program raziskovalno-razvojni projekt in je prvovrstne narave in v projektu obstaja vrsta neznank in tveganj.

Primer pristopa RBT

V industriji IT se za premagovanje tveganj, s katerimi se sooča proizvodnja in njeni vplivi, uporablja več pristopov analize na podlagi tveganj.

Spodaj je naveden en tak pristop:

Ta pristop RBT vključuje prepoznavanje „vitalnih funkcij ali ključnih značilnosti“ izdelka in oceno tveganj, ki jim je vsaka od teh funkcionalnosti izpostavljena v proizvodnji, ter izvajanje ustreznih ukrepov za zmanjšanje tveganja za zmanjšanje ali zmanjšanje tveganja.

Zato pristop RBT vključuje preizkušanje funkcij, ki imajo verjetnost okvare in imajo največji vpliv na poslovanje. Vrste napak so lahko operativne ali poslovne, tehnične, zunanje itd.

Načini za izvedbo analize tveganja

Za izvajanje analize tveganja pri preizkušanju programske opreme za vsako značilnost izdelka ni opredeljen noben standardni postopek ali predloga. Različne organizacije uporabljajo svoj pristop k metodam analize tveganja.

Analizo tveganja je mogoče izvesti na različnih projektnih postavkah, da bi ugotovili tveganja in uporabili pristop RBT za analizo. Ti predmeti vključujejo,

• Lastnosti
• Funkcionalnosti
• Zgodbe uporabnikov
• Zahteve
• Uporabite zadeve
• Testni primeri

V tem primeru se osredotočimo le na testne primere, da bomo razumeli izvajanje pristopa testiranja na podlagi tveganj.

Postopek analize tveganja

Analiza tveganja vključuje vključitev ustreznih zainteresiranih strani programa tako iz „ Tehnična in poslovna skupina “ , ki vključuje lastnika izdelka, vodje izdelkov, poslovne analitike, arhitekte, preizkuševalce in predstavnike strank.

Organizirali bi seje možganske nevihte, ki bi vključevale te zainteresirane strani, da bi izvedli razpravo, da bi ugotovili pomembnost vsake značilnosti izdelka in jim dali prednost glede na tveganje za okvaro in njegov vpliv na končne uporabnike v proizvodnji.

Različni „projektni dokumenti“, kot so dokument z zahtevami, dokumenti s tehničnimi specifikacijami, dokumenti o arhitekturi in oblikovanju, dokument o poslovnem procesu, dokument o uporabi itd., Bodo postali prispevek za sejo možganske nevihte.

Znanje zainteresiranih strani o izdelku in obstoječem izdelku na trgu bo prav tako vhodni dejavnik za razpravo.

Nekaj ​​drugih virov vložkov lahko vključuje tudi

• Zbrati vnose o najbolj uporabljeni funkcionalnosti.
• Prispevki iz posvetovanja s strokovnjakom za domeno.
• Podatki iz prejšnje različice izdelka ali podobnega izdelka na trgu.

Med možganska nevihta seji, se ugotovijo tveganja, ki se nanašajo na vsako od teh značilnosti. Vrste tveganj so lahko operativne, tehnične ali poslovne. Preskusi in z njimi povezani scenariji se ponderirajo in vrednosti tveganja ocenijo na podlagi verjetnosti pojava tveganja in vpliva tveganja.

„Verjetnost pojava tveganja“ je lahko posledica:

• Skupina za razvoj izdelkov slabo razume funkcijo.
• Neustrezna arhitektura in oblikovanje.
• Premalo časa za oblikovanje.
• Nesposobnost ekipe.
• Neustrezni viri - ljudje, orodja in tehnologija.

„Vpliv tveganja“ je učinek neuspeha na uporabnike in podjetja, če se zgodi. Vpliv bi lahko bil,

• Vpliv na stroške, ki povzroči izgubo.
• Poslovni vpliv, ki ima za posledico izgubo posla ali izgubo tržnega deleža, sodni postopki, izguba licence.
• Vpliv na kakovost, zaradi česar se podstandardni ali nesposobni izdelek sprosti.
• Slaba uporabniška izkušnja, kar povzroči nezadovoljstvo in izgubo stranke.

Osrednje področje ocene tveganja funkcije ali izdelka je lahko,

• Področje poslovne kritičnosti funkcionalnosti.
• Najbolj uporabljene funkcije in pomembne funkcije.
• Območja, nagnjena k napakam
• Funkcionalnost, ki vpliva na varnost in zaščito.
• Področje kompleksnega oblikovanja in arhitekture.
• Spremembe iz prejšnjih različic.

Metodologija analize tveganja

Naj zdaj podrobno razumemo „metodologijo testiranja na podlagi tveganj“.

Pristop testiranja na podlagi tveganj uporablja RISK kot merilo v vseh preskusnih fazah preskusnega cikla, tj. načrtovanje preskusov , zasnova testa, izvedba testa, izvedba testa in poročanje o preskusih. V idealnem primeru lahko oblikujemo številne možne kombinacije testnih scenarijev.

Zato pristop RBT vključuje razvrstitev testov na podlagi resnosti tveganj, da bi ugotovili najbolj pomanjkljivo ali tvegano območje okvare, kar povzroči velik vpliv na poslovanje.

Glavni cilj analize tveganja je ločiti med 'Visoka vrednost' predmeti, kot so lastnosti izdelka, funkcionalnosti, zahteve, uporabniške zgodbe , in testne primere ter „ Nizka vrednost “ in se kasneje bolj osredotočajo na testne primere z visoko vrednostjo, tako da se manj osredotočajo na testne primere z nizko vrednostjo. To je začetni korak analize tveganja pred začetkom testiranja na podlagi tveganj.

Glavna naloga kategorizacije ali združevanja testnih primerov v visoko in nizko vrednost in dodeljevanje prednostne vrednosti vsakemu od teh testnih primerov vključuje naslednje korake:

Korak # 1) Uporaba mreže 3X3

Analiza tveganja se izvede z uporabo mreže 3X3, kjer skupina zainteresiranih strani oceni vsako funkcionalnost, nefunkcionalnost in z njo povezane preskusne primere glede na „Verjetnostodpovedi “in„ Vpliv odpovedi “.

Verjetnost okvare posamezne funkcije v proizvodnji na splošno dostopa skupina 'tehničnih strokovnjakov', ki so po vertikalni osi omrežja kategorizirani kot 'verjetnost okvare, zelo verjetno in malo verjetno'.

kako začeti projekt v mrku

Podobno 'vpliv okvare' teh lastnosti in funkcionalnosti v proizvodnji doživi končni kupec, če ni preizkušen, oceni skupina ' Poslovni strokovnjaki 'in so razvrščeni v kategorije' Manjše, vidne in prekinitve 'vzdolž vodoravne osi mreže.

2. korak) Verjetnost in vpliv okvare

Vsi testni primeri so postavljeni v kvadrante mreže 3 X 3 na podlagi ugotovljenih vrednosti verjetnosti okvare in vpliva okvare, ki so na spodnji sliki prikazane kot pike.

Očitno je velika verjetnost okvare in velik vpliv okvare (prekinitve) združena v zgornjem desnem kotu mreže, kar je zelo pomembno, zato je ugotovljeno, da so preskusi 'visoke vrednosti' in preskusi 'nizke vrednosti' združeni v spodnji levi kot, ki je za kupca najmanj pomemben ali pa nima nobenega pomena, pri čemer je tem funkcijam ali testnim primerom treba nameniti manjši poudarek.

3. korak) Testiranje prednostne mreže

Na podlagi zgornjega pozicioniranja testnih primerov v mreži so preskusi prednostno razvrščeni in označeni s prednostnimi nalogami 1,2,3,4 in 5 ter označeni z vsakim od njih. Najpomembnejši preskusi so postavljeni v 1^stomrežja, ki jim je dodeljena prednost 1, podobno manj pomembne pa so razvrščene kot 2, 3, 4 in 5.

Na koncu so vsi testni primeri razvrščeni glede na prednostne številke in pobrani za izvedbo po prednostnem vrstnem redu. Tiste z visoko prioriteto se najprej izberejo za izvedbo, tiste z nizko prioriteto pa se pozneje izvršijo ali razveljavijo.

4. korak) Podrobnosti testiranja

Naslednji korak je odločitev o stopnji podrobnosti testiranja za opredeljeni obseg testiranja. Globino obsega preskušanja lahko določimo na podlagi zgornje razvrstitve glede na spodnjo mrežo.

Preskusi z visoko stopnjo prioritete z uvrstitvijo 1 so preizkušeni „Temeljiteje“, zato so napoteni strokovnjaki, ki preizkušajo te funkcije visoke kritičnosti in z njimi povezane primere preskusov. Podobno lahko preizkusimo primere s prednostjo 2, 3 in 4. Odločitev o izključitvi funkcij in testov prioritete 5 lahko sprejmemo na podlagi razpoložljivega časa in virov.

Zato pristop stopnje podrobnosti preizkušanja pri določanju prednosti funkcij in njegovih testnih primerov ne pomaga le preizkuševalcem, da prepoznajo „teste visoke vrednosti“, temveč jih vodi tudi pri odločanju o njihovi „podrobnosti preizkušanja“ na podlagi teh prednostnih razvrstitev in jim pomaga pri boljšem testiranju in z optimizacijskim postopkom zmanjša stroške testiranja.

Kako je RBT pomemben za Agile in DevOps?

Po razumevanju pristopa testiranja na podlagi tveganj pri izvajanju preskusov, ki temeljijo na določanju prednosti preskusov glede na „tveganje neuspeha“ določene funkcije in njen „učinek na kupca“ v živo, bi se očitno postavilo vprašanje pomembnost pristopa testiranja na podlagi tveganj v agilnih praksah in praksi DevOps.

'Automate Everything', 'Test Everything', 'Test Continuous', 'Test Repeatedly' so ključni koncepti teh praks.

Vsakič, ko pride do spremembe kode ali izdaje, se vsi načrtovani preskusi zaženejo prek avtomatike Neprekinjena integracija (CI) / Neprekinjena dostava (CD) hitro in večkrat, ne glede na njihovo prednostno razvrstitev.

Kakšna je potem povezava med RBT in DevOps? Kam bi se RBT prilegal in postal aktualen v Agile in DevOps ???

# 1) Da, kot sem že povedal, ni nujno, da ima vsaka industrija in vsak izdelek 100-odstotno pokritost avtomatizacije za svoje testne izvedbe. Torej, če mora ekipa sploh izbrati prednostno razvrstitev za izvedbo preizkusa od izbire ročnih testnih primerov in bi rada prihranila energijo in trud testnih virov za druge dejavnosti, potem je RBT najboljša izbira.

Pristop, ki temelji na tveganju, je tudi boljša stava za izvajanje avtomatiziranih testov z visoko prioritetnimi testi in čim prej.

#two) Skupina QA lahko med analizo zahtev učinkoviteje sprejme pristop RBT pri analizi zahtev in pripravi predhodno poročilo o verjetnih tveganjih izdelkov in lastnosti, tako da lahko programska skupina proaktivno sprejme ustrezne ukrepe za njegovo ublažitev.

# 3) Pristop RBT se lahko učinkovito uporablja pri oblikovanju testnih primerov in scenarijev, ki temeljijo na visokem tveganju, tako da se lahko več pozornosti nameni visoko tveganim značilnostim in funkcionalnostim.

# 4) Opredelitev področij „z visokim tveganjem“ ekipi QA omogoča, da svoje napore preizkušanja osredotoči na tista področja, ki jih je treba temeljiteje preizkusiti z uporabo „visoko usposobljenih preizkuševalcev“.

# 5) 'Fail Fast', kot vsi dobro vemo, je koncept 'Agile' in 'DevOps', pri katerih pristop RBT pomaga prepoznati področja 'visokega tveganja' v programski opremi, zgodaj prepoznati napake in jim omogočiti, da hitro in neuspešno odpovedo najprej pustite ekipi, da to popravi.

# 6) Končni cilj Agile / DevOps je „osredotočenost na kupca“, zato pristop RBT omogoča QA, da se osredotoči na izkušnjo strank kot samo na iskanje napak.

Prednosti pristopa testiranja na podlagi tveganj

Že smo razumeli namen in uporabo pristopa RBT za analizo zahtev, načrtovanje in izvajanje scenarijev testiranja. Prednosti RBT so številne.

Prednosti testiranja na podlagi tveganj lahko združimo in naštejemo kot:

• Pomaga pri učinkovitejši in optimizirani uporabi testnih virov.
• Pomaga pri lajšanju dela za zagotavljanje kakovosti, preskušanje, načrtovanje in razvoj preskusov ter dejavnosti priprave na preskuse z določanjem prednostnih nalog.
• Pomaga pri boljšem upravljanju virov zagotavljanja kakovosti tako, da se ključni viri razporedijo na področja z visokim poudarkom.
• Pomaga pri učinkoviti rabi virov in njihov čas in energijo preusmeri na boljše stvari v projektu.
• Pomaga skupini za zagotavljanje kakovosti pri načrtovanju preizkusnih prizadevanj na podlagi ocene tveganja in prepoznavanja hlapnih in tveganih območij.
• Skupini pomaga optimizirati teste, ki jih je treba izvesti, odvisno od pomembnosti in s tem v dogovoru z zainteresiranimi stranmi razveljaviti teste majhne vrednosti.
• Na splošno pomaga pri zniževanju stroškov z optimiziranimi in zmanjšanimi testnimi dejavnostmi.
• Pristop RBT ekipi QA omogoča, da najprej preizkusi območja z visokim tveganjem, izdelek pa lahko hitro odpove in hitro popravi.
• Pristop RBT prispeva k jasnosti v „ Preizkusna pokritost “ in „Obseg preizkusa“ za celotno skupino zainteresiranih strani.
• Skupina se lahko bolj osredotoči na območja z visokim tveganjem in se manj osredotoča na območja z majhnim tveganjem.
• RBT skupini omogoča, da se že vnaprej odloči o izvajanju najučinkovitejšega načina ublažitve tveganj za izdelke.
• RBT pomaga pri preprečevanju učinkov neustreznega izvajanja blažilnih ukrepov.
• Testiranje na podlagi tveganj skupini omogoči, da sprejme ustrezne ukrepe za ublažitev ali načrtovanje izrednih razmer ali za rešitev kakršne koli rešitve za premagovanje okvare ali zmanjšanje njenega vpliva, če se tveganje pojavi v živo.
• RBT pomaga zmanjšati preostalo tveganje pri sproščanju.
• Pomaga pri doseganju 'izboljšane kakovosti' zaradi cenejših napak v proizvodnji.
• Na koncu pomaga pri izboljšani izkušnji strank in zadovoljni stranki.

Nato se bomo naučili obvladovanja tveganj v fazah načrtovanja in izvajanja preizkusov življenjskega cikla testiranja programske opreme.

Obvladovanje tveganja med načrtovanjem preskusov

Kako obvladovati tveganja v fazi načrtovanja preskusov:

Življenje je polno tveganj, prav tako projekt programske opreme. Vse lahko kadar koli gre narobe. Vedno se potrudimo, da stvari uredimo - kaj pa skrbeti, da ne bo šlo nič narobe in da takrat, ko bo, točno vemo, kaj storiti? Vstopite v upravljanje tveganj - to je del projekta preizkušanja programske opreme, ki nas pripravi na preprečevanje, razumevanje, iskanje in premagovanje tveganj.

Tveganje je preprosto težava, ki se verjetno pojavi, in ko se bo zgodilo, bo povzročilo izgubo.

Izguba je lahko kar koli - denar, čas, trud ali kompromis v kakovosti. Izguba ni nikoli dobra. Ne glede na to, koliko vrtenja bomo vrteli, to ni pozitivno in nikoli ne bo. Torej Upravljanje s tveganji je sestavni del programskih projektov, s katerimi poskrbimo, da obvladujemo tveganja in preprečimo / zmanjšamo izgube.

Testiranje na podlagi tveganj : Ker smo QA skupnost, ostanimo specifični glede tveganj in postopkov, povezanih z njimi, izključno v našem svetu QA. Tveganja ocenjujemo in obvladujemo približno v dveh fazah naše Življenjski cikel preizkusa programske opreme . STLC lahko razvrstimo v 3 faze - načrtovanje preskusov, načrtovanje preskusov in izvajanje preizkusov.

Postopek upravljanja s tveganji se izvede dvakrat, med:

1. Načrtovanje preskusov
2. Oblikovanje testnega primera (konec) ali včasih v fazi izvedbe preizkusa

V primeru 1 je obvezen, v primeru 2 pa gre bolj za situacijo, ki temelji na potrebi.

Dvodelna serija člankov:

Čeprav je osnovni postopek enak, je vrste tveganj na obeh področjih popolnoma različni. Da bi jim bili posamično pravični, jih bomo obravnavali drugače kot dvodelno serijo.

Ta razdelek bo o 'Obvladovanje tveganja med načrtovanjem preskusov'.

Postopek obvladovanja tveganj

Splošni postopek za obvladovanje tveganja vključuje tri pomembne faze:

1. Ugotovitev tveganja
2. Analiza vpliva tveganja
3. Zmanjšanje tveganja

Primeri preizkušanja tveganj in ublažitev:

# 1) Ugotovitev tveganja

Kot rečeno, je prvi korak k reševanju problema njegovo prepoznavanje. Ta stopnja vključuje izdelavo seznama vsega, kar bi lahko prišlo do motenj v običajnem toku dogodkov.

Glavni rezultat tega koraka je seznam tveganj.

Ta korak testiranja, ki temelji na tveganju, običajno vodi vodja / vodja / predstavnik za zagotavljanje kakovosti. Vendar samo vodja ne bo mogel priti do celotnega seznama - celoten prispevek ekipe QA ima velik vpliv. Lahko rečemo, da gre za kolektivno dejavnost, ki jo vodi vodja kakovosti.

Tveganja, ki so bila ugotovljena med fazo načrtovanja testov, so bolj usmerjena v usmeritev, kar pomeni, preučili bomo vse, kar bi lahko vplivalo na urnik, napor, proračun, spremembe infrastrukture projekta QA. ne AUT, ampak način nadaljevanja QA faze.

Tveganja med načrtovanjem preskusov: primeri preskušanja na podlagi tveganj

Sledi vzorec seznama tveganj, ki bi jih lahko navedli med fazo načrtovanja preskusov. Upoštevajte, da AUT in njegova funkcionalnost tukaj nista v središču.

1. Časovni razpored testiranja je tesen. Če je začetek preskusa zaradi projektnih nalog zamujen, testa ni mogoče podaljšati po datumu začetka UAT.
2. Ni dovolj virov, viri se vkrcajo prepozno (postopek traja približno 15 dni.)
3. Napake najdemo v pozni fazi cikla ali v poznem ciklu; Napake, odkrite pozno, so verjetno posledica nejasnih specifikacij in so dolgotrajne za odpravljanje.
4. Področje uporabe ni popolnoma določeno
5. Naravne nesreče
6. Nerazpoložljivost Independenta Testno okolje in dostopnost
7. Zapoznelo testiranje zaradi novih številk

V tem trenutku se lahko odločite, da boste temeljiti, kot želite, odvisno od razpoložljivega časa.

Ko so vsa tveganja navedena, preidemo na oceno tveganja / analizo vpliva.

# 2) Ocena tveganja / analiza vpliva

Je vaša analiza tveganja kaj takega? :)

Analiza tveganja pri testiranju programske opreme : V tem koraku so vsa tveganja količinsko opredeljena in prednostno razvrščena. Verjetnost vsakega tveganja (možnost nastanka) in vpliv (znesek izgube, ki bi jo povzročilo, ko se to tveganje uresniči) se določa sistematično.

Visoka - srednje nizka , vrednosti so dodeljene tako verjetnosti kot vplivu posameznega tveganja. Najprej je poskrbljeno za tveganja z »veliko« verjetnostjo in »velikim« vplivom, nato pa sledi vrstni red.

Tabela analize vpliva:

Po teh korakih bi bila tabela analize vpliva za zgoraj navedena tveganja videti nekako takole (vse vrednosti so hipotetične in samo za razumevanje):

# 3) Zmanjšanje tveganja

Zadnji korak v tem postopku testiranja na podlagi tveganj (RBT) je iskanje rešitev za načrtovanje, kako ravnati v vsaki od teh situacij. Ti načrti se lahko razlikujejo od podjetja do podjetja, od projekta do projekta in celo od osebe do osebe.

csqa izpit vprašanja in odgovori pdf

Tehnike za zmanjšanje tveganja:

Tu je primer, v kaj se spremeni tabela tveganj, ko je ta faza končana:

Nekaj ​​točk:

1. Prej ko se obvladovanje tveganj začne v fazi načrtovanja QA, tem bolje.
2. Od vseh 3 korakov, Ugotovitev tveganja je najpomembnejša . Če kar koli ni navedeno in obravnavano za nadaljnje korake, se tveganje ne reši.
3. Poskusite najti idealen časovni okvir za to dejavnost. Ne pozabite, da preveč načrtovanja pušča premalo časa za izvajanje.
4. Tudi po postopku obvladovanja tveganj se lahko, če se pojavi novo stanje, načrt obvladovanja tveganj spremeni ali posodobi, da odraža najnovejše stanje.
5. Zgodovinski podatki je lahko zelo koristen za uspeh tega procesa.

Zaključek

To pripelje do konca upravljanja tveganj v fazi načrtovanja preskusov. Čeprav so osnovni koraki in načela podobni, je postopek obvladovanja tveganja bolj osredotočen na AUT, ko se to zgodi v fazi načrtovanja / izvedbe testa.

V naslednjem poglavju bomo zajeli - Obvladovanje tveganja v fazi izvedbe preizkusov.

Obvladovanje tveganja v fazi izvedbe preizkusa (s primerom)

Na poti do razumevanja postopka obvladovanja tveganja smo govorili o tem, kako poteka izključno v Faza načrtovanja preskusov na podlagi tveganj . Razumeli smo tudi generični postopek, ki vključuje - prepoznavanje tveganja, oceno tveganja in načrt za zmanjšanje tveganja.

Kako obvladovati tveganje v fazi načrtovanja ali izvedbe testa:

Obstaja še ena oblika Upravljanje s tveganji (včasih tudi Testiranje na podlagi tveganj ), ki se pojavi med fazo načrtovanja ali izvedbe testa, odvisno od situacije. Zdaj, o kakšni situaciji govorimo? Najprej poskusimo to razumeti.

Vsi vemo, da je naše testno delo reaktivno. Nobene zahteve (ali področje uporabe ni določeno) ne moremo izvesti analize izvedljivosti in napisati testnih scenarijev ali načrtovati preskusnih dejavnosti.

Podobno, ko koda ni pripravljena, nimamo česa preizkusiti, ne glede na to, koliko priprav smo bili pripravljeni v okviru testnih primerov, testnih podatkov itd. Testiranje je edini korak, ki ostane pred izdelkom v živo.

Obvladovanje tveganj - s poudarkom na AUT

Naj to bolje razumemo s primerom:

Če naj bi se testiranje začelo na navedeni datum, 1. januarja^stin je moral nadaljevati do 14. januarja^th- ko je testiranje končano, se datum začetka delovanja izdelka običajno določi takoj. Recimo - 15. januarja^thzaradi poenostavitve. Zdaj bi v popolnem svetu stvari potekale natanko tako, kot je bilo načrtovano. Toda vsi poznamo resničnost.

V tem primeru predpostavimo, da se je testiranje iz nekega razloga začelo šele 7. januarja^th, kar pomeni, da smo izgubili polovico časa testiranja. Vendar pa potrebujemo 14 dni, da izdelek temeljito preizkusimo. Datum začenjanja bi lahko premaknili za 7 dni dlje - vendar; to običajno ni možnost. Ker se izdelek obljublja, da bo na trg prišel na določen datum, in kakršne koli zamude za podjetje niso dobre.

Običajno moramo ekipe za testiranje zamude nadomestiti, nekako nadomestiti, delati s časom, ki je na voljo, in zagotoviti, da je izdelek dobro preizkušen. Težko delo, kajne?

Tu se ponovno uporablja postopek upravljanja tveganj.

• Zdaj, če zamude se pričakujejo pred časom preden se sploh začne testiranje - postopek poteka v fazi načrtovanja testa.
• Če zamude se zgodijo med Faza izvedbe testa ki se je normalno začel - postopek se sledi v fazi izvedbe testa.
• Koraki in metoda so enaki, ne glede na stopnjo.

Kakšen je postopek?

Obvladovanje tveganj poteka tako, da se ugotovi, na katera področja AUT (Application Test Test) je treba posvetiti največ pozornosti. To so običajno funkcionalna področja (moduli ali komponente), ki so ključnega pomena za uspeh končnega izdelka in so najbolj nagnjena k okvaram.

Preberite tudi=> Analiza načina in učinkov napak (FMEA) je tehnika upravljanja tveganj

Kdo jo izvaja?

Ker gre za AUT, znanje o njem ni povezano samo s QA, ampak tudi z vsemi ostalimi skupinami - Dev, BA, Client, Project management ekipe itd. Zato gre za skupni napor, ki ga vodi skupina za testiranje.

Kako poteka testiranje podlag tveganja?

Korak 1) Ugotovitev tveganja

Določite vsa funkcionalna področja AUT. To bo preprosto vključevalo sestavljanje seznama.

2. korak) Ocena tveganja

Vsa tveganja so v tem koraku količinsko opredeljena in prednostno razvrščena. Kvantificiranje je preprosto, tako da se vsakemu tveganju na seznamu dodeli številka, ki bo pokazala prednost, s katero jo je treba obravnavati.

Odločijo se verjetnost vsakega tveganja (možnost nastanka) in vpliv (znesek izgube, ki bi jo povzročilo, ko se to tveganje uresniči).

Tipična metoda je dodelitev ocen. Na primer, Verjetnost ima lahko vrednosti od 1 do 5. 1, ki je verjetnost pojava majhna (verjetno se sploh ne bo zgodilo), 5 pa velika (se bo zagotovo zgodilo).

Podobno lahko tudi Impact dobi oceno 1-5. 1 je majhen učinek (tudi če se to tveganje uresniči, izguba je minimalna) in 5 velik vpliv (velike izgube, kadar se zgodi).

3. korak)

Naredite obliko tabele in jo pošljite vsem predstavnikom ekipe - Dev, BA, Client, PM, QA in vsem drugim.

4. korak)

Vsaki ekipi naročite, naj izpolni vrednosti na podlagi ocene verjetnosti in vpliva.

Ker so vrednosti verjetnosti in vpliva številske, bo izračun vrednosti faktorja tveganja enostaven.

Faktor tveganja = Verjetnost X Vpliv. Višji kot je dejavnik tveganja, večja je težava.

Primer:

Upoštevajte, da je v tem trenutku to preprosto rezultat ocene ene ekipe. Za projekt, v katerem sodeluje 5 različnih skupin, bi ekipa za preverjanje kakovosti dobila 5 različnih tabel.

5. korak)

Vzemite povprečje vrednosti faktorja tveganja. Na primer, če je 5 ekip, za vsak modul dodajte vse vrednosti dejavnikov tveganja in jih razdelite na 5. To so končne vrednosti, s katerimi se bomo ukvarjali. Recimo, to so povprečni dejavniki tveganja:

Več kot je dejavnikov tveganja, bolj je treba ta modul preizkusiti.

Modula 5 in 2 sta torej najpomembnejša za uspeh podjetja. Rezultate delite z vsemi ekipami.

6. korak)

Načrt za zmanjšanje tveganja : Zdaj je to korak, ki se spreminja od projekta do projekta. Ugotovili smo, da sta modula 5 in 2 tista, na katera se je treba osredotočiti najbolj.

Primerinačrta lahko:

1. Modula 5 in 2 bosta temeljito preizkušena tako, da se bodo preizkusili vsi z njimi povezani testni primeri. Drugi moduli bodo preizkušeni na raziskovalni osnovi.
2. Modula 5 in 2 bosta najprej preizkušena, nato pa bo odvisno od razpoložljivega časa poskrbljeno za ostale.

Ko je načrt pripravljen, se vse ekipe dogovorijo in mu sledijo, da preizkusijo izdelek ob upoštevanju dejavnika tveganja.

To je to!

Nekaj ​​pomembnih točk:

• Ker gre za kolektivno dejavnost, ki traja mnenje vseh ; možnosti, da bo natančen in učinkovit, so večje.
• To je ne formalna metoda in ni nujno, da je del vsakega projekta za zagotavljanje kakovosti.
• Včasih, tudi če se ekipa odloči, da ne bo risala tabel in dodelila vrednosti - a preprosta seja možganske nevihte z vsemi navzočimi lahko ekipi QA dajo dobre napotke, kako naprej.
• The prispevek razvojne ekipe je zelo pomembno, ker so oni tisti, ki ustvarjajo izdelek, zato bodo vedeli, kaj bi lahko delovalo in kaj bi bilo treba dodatno preveriti. Bodite pozorni na to.
• Čeprav je v postopku več korakov, za njihovo izvedbo ne traja veliko časa . Še posebej, če lahko vse ekipe sedijo skupaj in delajo hkrati.
• Zapomnite si ta postopek in njegov rezultat je samo alternativa . Pridobitev toliko časa, kot je načrtovano za testiranje, je najboljši način za izvajanje nadzora kakovosti.

Zaključek

Pristop preskušanja na podlagi tveganj jasno kaže, da preizkuševalec ni osredotočen zgolj na nadaljnje raziskovanje napak, ne glede na resnost in prednost. Zdaj so se stvari spremenile in preizkuševalci morajo delati pametno in razumeti jasno 'Potrebe kupca in želje uporabnika'.

Izdelek morajo temeljito preučiti in razumeti, katera značilnost je najpogosteje uporabljena v proizvodnji, kar je najbolj kritična pot za ustvarjanje prihodkov in kako zaščititi in zaščititi kupce pred proizvodnimi težavami in poslovnimi grožnjami.

Zato pristop RBT jasno izobražuje 3 preizkuševalce, da samo testiranje vsega ali obsežno testiranje še ne pomeni, da je testiranje končano ali v izdelku ni napak. Učinkovito testiranje v predpisanem času in zagotavljanje, da se izničijo kritični in glavni poslovni vplivi, kar je za preizkuševalca zelo pomembno.

Testiranje na podlagi tveganj je tako najučinkovitejše orodje za skupino za preverjanje kakovosti za usmerjanje zainteresiranih strani na podlagi projektnih tveganj. Pristop RBT pomaga ekipi za zagotavljanje kakovosti pri nenehnem prepoznavanju tveganj in njihovem reševanju, ki bi lahko ogrozilo doseganje splošnih ciljev in ciljev projekta, ter pomaga pri doseganju končnega cilja skupine QA.

P.S. Besedi QA in Testiranje sta bili v dokumentu zamenljivi.

O avtorju: Ta članek je napisalo več članov ekipe STH - Gayathri Subrahmanyam in Swati S.

Gayathri je MSP s programsko opremo, ki ima več kot desetletja izkušenj s preizkušanjem programske opreme in je v več poskusih v okviru preizkusne industrializacije široko sprejel pristop 'Testiranje na podlagi tveganj' in spoznal prednosti preizkusne optimizacije virov in preskušanja kakovosti.

Je bilo testiranje na podlagi tveganj za vas zahtevno? Ali imate v našo vadnico kakšna zanimiva dejstva? Vas prosimo, da svoje misli izrazite v spodnjem oddelku za komentarje !!

=> Obiščite tukaj za celotno serijo vadnic za načrt preizkusov

Priporočeno branje

• Neprekinjen proces integracije: Kako izboljšati kakovost programske opreme in zmanjšati tveganje
• Analiza napak in učinkov (FMEA) - Kako analizirati tveganja za boljšo kakovost programske opreme in zadovoljne stranke!
• Vrhunski priročnik za testiranje na podlagi tveganj: obvladovanje tveganj pri testiranju programske opreme
• 10 najboljših orodij in tehnik za oceno in upravljanje tveganj
• Vrste tveganj pri programskih projektih
• Nekaj ​​zanimivih vprašanj za preskušanje programske opreme
• Izbira preizkušanja programske opreme kot vaše kariere
• Povratne informacije in pregledi tečaja za preizkušanje programske opreme