defect severity priority testing with examples
V tej vadnici boste izvedeli, kaj sta resnost in prioriteta pomanjkljivosti pri testiranju, kako nastaviti primere napak in stopnjo resnosti s primeri, da boste jasno razumeli koncept.
Podrobno bomo obravnavali tudi razvrstitev napak v različne skupine in njihov pomen v življenjskem ciklu napak. Ključno vlogo razvrstitve bomo pokrili tudi z nabori primerov v živo.
Napake pri vlaganju so zelo pomembne del življenjskega cikla testiranja programske opreme . Za program je opredeljenih več najboljših praks učinkovito poročanje o napakah prek interneta ali v organizacijah.
Kaj se boste naučili:
- Pregled sledenja napak
Pregled sledenja napak
Eden od pomembnih vidikov življenjskega cikla okvar na splošni ravni vključuje sledenje napakam. To je pomembno, ker preskusne skupine pri preizkušanju dela programske opreme, ki se pomnoži le, če je določen preskušani sistem zapleten, odkrijejo več napak. V takem scenariju je upravljanje s temi napakami in njihova analiza z namenom zapiranja zastrašujoča naloga.
V skladu s postopki vzdrževanja napak mora kateri koli preskuševalec poleg metode / opisa, da bi reproduciral opaženo težavo, navesti tudi nekatere kategorične informacije, ki bi pomagale pri netočni razvrstitvi napake. To pa bi pomagalo pri učinkovitem postopku sledenja / vzdrževanja napak in bi bilo tudi osnova za hitrejši čas odprave napak.
Dva glavna parametra, ki sta osnova za učinkovito sledenje in odpravljanje napak, sta:
- Prednostna napaka pri testiranju
- Resnost pomanjkljivosti pri testiranju
Ti koncepti so pogosto zmedeni in se med seboj uporabljajo ne le med testnimi skupinami, temveč tudi med razvojnimi skupinami. Med obema je tanka črta in pomembno je razumeti, da med njima res obstajajo razlike.
Na kratko razumemo teoretične definicije obeh parametrov v naslednjem poglavju.
Kaj je resnost in prednost pomanjkljivosti?
Prednost po angleški definiciji se uporablja pri primerjavi dveh stvari ali pogojev, pri čemer je treba enemu dati večji pomen kot drugim in ga je treba najprej obravnavati / razrešiti, preden nadaljujemo z naslednjim. V kontekstu napak bi torej prednost napake nakazovala nujnost, s katero bi jo bilo treba odpraviti.
Resnost po angleški definiciji se uporablja za opis resnosti neželenega pojava. Torej, ko gre za napake, bi resnost napake pokazala učinek, ki ga ima na sistem glede na njegov vpliv.
Kdo jih opredeljuje?
QA razvrsti napako pod ustrezno težo glede na zapletenost in kritičnost napak.
Vse zainteresirane strani v podjetjih, vključno z vodji projektov, poslovnimi analitiki in lastnikom izdelkov, opredelijo prednost napak.
Spodnja slika prikazuje vlogo, ki je lastnik in razvršča kritičnost in resnost napak.
Kako izbrati te ravni?
Kot smo že govorili, parameter resnosti oceni preizkuševalec, medtem ko prednostni parameter v glavnem oceni vodja izdelka ali v bistvu triažna skupina. Čeprav je temu tako, je resnost napake vsekakor eden vodilnih in vplivnih dejavnikov za določanje prednosti napake. Zato je pomembno, da kot preizkuševalec izberete pravo resnost, da ne pride do zamenjave z razvojnimi skupinami.
Razlika med resnostjo in prednostjo
Prednost je povezana z razporejanjem, 'resnost' pa s standardi.
»Prednost« pomeni, da je nekaj namenjeno ali si zasluži predhodno pozornost; prednost, določena po pomembnosti (ali nujnosti).
'Resnost' je stanje ali kakovost resnosti; hudo pomeni spoštovanje strogih standardov ali visokih načel in pogosto predlaga ostrost; hudo je zaznamovano ali zahteva strogo spoštovanje strogih standardov ali visokih načel, Na primer, hud kodeks vedenja.
Besedi prednost in resnost se pojavita pri sledenju napakam.
Na voljo so različna komercialna programska orodja za sledenje / upravljanje težav. Ta orodja s podrobnim vnosom inženirjev za preizkušanje programske opreme dajo skupini popolne informacije, tako da lahko razvijalci razumejo napako, dobijo idejo o njeni 'resnosti', jo reproducirajo in popravijo.
Popravki temeljijo na projektu 'Prednostne naloge' in 'Resnost' napak.
„Resnost“ težave je opredeljena v skladu z oceno tveganja stranke in zabeležena v izbranem orodju za sledenje.
Buggy programska oprema lahko 'močno' vpliva na urnike, kar pa lahko privede do ponovne ocene in ponovnega pogajanja o 'prioritetah'.
Kaj je prednostna naloga?
Kot že ime pove, ima prednost prednostno razvrščanje napake glede na poslovne potrebe in resnost napake. Prednost označuje pomembnost ali nujnost odprave napake.
Med odpiranjem napake preskuševalec najprej najprej dodeli prednost, ko izdelek gleda z vidika končnega uporabnika. V skladu s tem obstajajo različne ravni:
Na splošno lahko prednostne okvare razvrstimo na naslednji način:
Prednost # 1) Takojšnja / kritična (P1)
To je treba popraviti takoj v 24 urah. To se običajno zgodi v primerih, ko je celotna funkcionalnost blokirana in zaradi tega nobeno testiranje ne more nadaljevati. Ali v nekaterih drugih primerih, če pride do znatnega puščanja pomnilnika, je okvara na splošno razvrščena kot prednostna -1, kar pomeni, da je program / funkcija v trenutnem stanju neuporabna.
Vsaka napaka, ki zahteva takojšnjo pozornost, ki vpliva na postopek testiranja, bo razvrščena v takojšnjo kategorijo
Vse Kritična resnost napake spadajo v to kategorijo (razen če podjetja / zainteresirane strani znova določijo prednostne naloge)
Prednost # 2) Visoka (P2)
Ko so kritične napake odpravljene, je napaka, ki ima to prednost, naslednji kandidat, ki ga je treba odpraviti za katero koli preskusno dejavnost, da ustreza kriterijem 'izstopa'. Običajno kadar funkcija ni uporabna, kot bi morala biti, zaradi programske napake ali ker je treba napisati novo kodo ali včasih celo zato, ker je s kodo treba obravnavati kakšen okoljski problem, je napaka lahko upravičena do prioritete 2 .
To je napaka ali težava, ki jo je treba odpraviti pred izdajo. Te napake je treba odpraviti, ko se rešijo kritična vprašanja.
Vse Major resnost napake spadajo v to kategorijo.
Prednost # 3) Srednja (P3)
Napaka s to prednostno nalogo mora biti sporna, da jo je mogoče odpraviti, saj bi lahko obravnavala tudi težave s funkcionalnostjo, ki niso v skladu s pričakovanji. Včasih bi lahko bile tudi kozmetične napake, kot je pričakovanje pravega sporočila o napaki med okvaro, prednostna napaka 3.
To napako je treba odpraviti po odpravi vseh resnih napak.
Ko so kritične in visoko prioritetne napake opravljene, se lahko odločimo za napake srednje prioritete.
Vse Minor resnost napake spadajo v to kategorijo.
Prednost # 4) Nizka (P4)
Napaka z nizko prioriteto kaže, da težava vsekakor obstaja, vendar je ni treba odpraviti, da bi ustrezala merilom 'izstopa'. Vendar je to treba popraviti, preden je opravljen GA. Tu lahko običajno razvrstimo nekatere tipkarske napake ali celo kozmetične napake, o katerih smo že govorili.
Včasih se odprejo tudi napake s prednostno nizko stopnjo, da se predlagajo nekatere izboljšave v obstoječi zasnovi ali zahteva za izvedbo majhne funkcije za izboljšanje uporabniške izkušnje.
kateri je najboljši e-poštni račun
To napako je mogoče odpraviti v prihodnosti in ne potrebuje takojšnje pozornosti Nizka resnost napake spadajo v to kategorijo.
Kot že omenjeno, prednost določa, kako hitro mora biti čas odprave napak. Če je več napak, se prednost odloči, katero napako je treba odpraviti in takoj preveriti, v primerjavi s katero napako je mogoče odpraviti nekoliko kasneje.
Kaj je resnost?
Resnost določa, v kolikšni meri lahko določena napaka vpliva na aplikacijo ali sistem.
Resnost je parameter, ki označuje posledice napake na sistem - kako kritična je napaka in kakšen vpliv ima napaka na funkcionalnost celotnega sistema? Resnost je parameter, ki ga nastavi tester, medtem ko odpira napako in v glavnem nadzoruje testerja. Spet različne organizacije uporabljajo različna orodja za napake, vendar so na splošni ravni te stopnje resnosti:
Na primer, Upoštevajte naslednje scenarije
- Če uporabnik poskuša opraviti spletno nakupovanje in se aplikacija ne naloži ali se prikaže sporočilo o nedostopnosti strežnika.
- Uporabnik izvede dodajanje artikla v košarico, število dodanih količin je napačno / doda se napačen izdelek.
- Uporabnik opravi plačilo in po plačilu ostane naročilo v košarici kot rezervirano, namesto tega potrjeno.
- Sistem sprejme naročilo, vendar končno prekine naročilo po pol ure zaradi morebitnih težav.
- Sistem sprejme 'Dodaj v košarico' samo z dvojnim klikom namesto z enim samim klikom.
- Gumb Dodaj v košarico se piše kot Dodaj v košarico.
Kakšna bi bila uporabniška izkušnja, če bi se zgodil kateri od zgornjih scenarijev?
Na splošno lahko napake razvrstimo na naslednji način:
# 1) Kritično (S1)
Napaka, ki popolnoma ovira ali blokira preskušanje izdelka / lastnosti, je kritična napaka. Primer bi bil primer preizkušanja uporabniškega vmesnika, kjer uporabniški vmesnik po prehodu s čarovnikom preprosto visi v enem podoknu ali pa ne gre naprej, da sproži funkcijo. Ali v nekaterih drugih primerih, ko razvita funkcija manjka v gradnji.
Iz kakršnega koli razloga, če se aplikacija sesuje ali postane neuporabna / ne more nadaljevati, lahko napako razvrstimo pod kritično resnost.
Kakršne koli katastrofalne okvare sistema bi lahko uporabnika privedle do neuporabe aplikacij, ki bi se lahko uvrstile pod kritično resnost
Na primer, Pri ponudniku e-poštnih storitev, kot sta Yahoo ali Gmail, po vnosu pravilnega uporabniškega imena in gesla sistem, namesto da se prijavi, zruši ali vrže sporočilo o napaki, je ta napaka opredeljena kot kritična, saj zaradi te napake celotna aplikacija postane neuporabna.
Zgoraj obravnavani scenarij iz točke 1 bi lahko uvrstili med kritične napake, saj spletna aplikacija postane popolnoma neuporabna.
# 2) Major (S2)
Vsaka glavna funkcija, ki ne izpolnjuje svojih zahtev / primerov uporabe in se obnaša drugače, kot je bilo pričakovano, jo je mogoče uvrstiti med glavne resnosti.
Večja napaka se pojavi, ko funkcionalnost deluje močno stran od pričakovanj ali če ne počne tega, kar bi morala. Primer je lahko: Recimo, da je treba na stikalu razporediti VLAN in uporabljate predlogo uporabniškega vmesnika, ki sproži to funkcijo. Ko ta predloga za konfiguracijo VLAN-a na stikalu ne uspe, postane klasificirana kot resna pomanjkljivost funkcionalnosti.
Na primer, Če pri ponudniku e-poštnih storitev, kot sta Yahoo ali Gmail, v odseku CC ne smete dodati več kot enega prejemnika, je ta napaka razvrščena kot glavna napaka, saj glavna funkcionalnost aplikacije ne deluje pravilno.
Pričakovano vedenje odseka CC v pošti mora uporabniku omogočiti dodajanje več uporabnikov. Torej, kadar glavna funkcionalnost aplikacije ne deluje pravilno ali če se obnaša drugače, kot je bilo pričakovano, je to velika napaka.
Zgoraj obravnavane scenarije na 2. in 3. točki bi lahko uvrstili med večje napake, saj naj bi se vrstni red gladko premaknil v naslednjo fazo življenjskega cikla naročila, v resnici pa se vedenje razlikuje.
Kakršno koli napako, ki bi lahko povzročila napačno obstojnost podatkov, težave s podatki ali napačno vedenje aplikacij, bi lahko na splošno uvrstili med glavne resnosti.
# 3) Manjša / zmerna (S3)
Katero koli izvedeno funkcijo, ki ne izpolnjuje svojih zahtev / primerov uporabe in se obnaša drugače, kot je bilo pričakovano, vendar je vpliv do neke mere zanemarljiv ali nima večjega vpliva na aplikacijo, lahko uvrstimo v kategorijo Manjša resnost.
Zmerna napaka se pojavi, če izdelek ali aplikacija ne izpolnjuje določenih meril ali ima še vedno nenaravno vedenje, vendar funkcionalnost kot celota ne vpliva. Na primer v zgornji razmestitvi predloge VLAN bi se pri uspešno nameščeni predlogi na stikalu pojavila zmerna ali običajna napaka, vendar uporabniku ni poslana nobena indikacija.
Na primer, V ponudniku e-poštnih storitev, kot sta Yahoo ali Gmail, obstaja možnost, imenovana 'Pogoji in določila', v njej pa bo več povezav glede pogojev in stanja spletnega mesta. Ko ena izmed več povezav ne deluje v redu, imenuje se manjša resnost, saj vpliva le na manjše funkcionalnosti aplikacije in nima velikega vpliva na uporabnost aplikacije.
Zgoraj obravnavani scenarij iz točke 5 bi lahko uvrstili med manjše napake, saj v vrstnem redu pretoka sistema ne pride do izgube ali okvare podatkov, ampak pri uporabniški izkušnji z rahlimi nevšečnostmi.
Te vrste napak povzročijo minimalno izgubo funkcionalnosti ali uporabniške izkušnje.
# 4) Nizka (S4)
Vse kozmetične napake, vključno s črkovalnimi napakami, težavami s poravnavo ali ohišjem pisave, lahko uvrstimo v kategorijo Nizka resnost.
Manjša napaka majhne resnosti se pojavi, ko skoraj nima vpliva na funkcionalnost, vendar je še vedno veljavna napaka, ki jo je treba odpraviti. Primeri tega lahko vključujejo napake pri črkovanju v sporočilih o napakah, natisnjenih uporabnikom, ali napake za izboljšanje videza in občutka funkcije.
Na primer, Pri ponudniku e-poštnih storitev, kot sta Yahoo ali Gmail, bi opazili »Stran z licenco«. Če je na strani napaka pri črkovanju ali neusklajenost, je ta napaka razvrščena kot Nizka.
Zgoraj obravnavani scenarij iz točke 6 bi lahko uvrstili med nizke napake, saj je gumb Dodaj prikazan v napačnem ohišju. Tovrstne napake ne bodo vplivale na vedenje sistema ali predstavitev podatkov ali izgubo podatkov ali pretok podatkov ali celo na uporabniško izkušnjo, vendar bodo zelo kozmetične.
Če povzamemo, naslednja slika prikazuje široko razvrstitev napak glede na resnost in prednost:
Primeri
Kot smo že omenili, ker različne organizacije uporabljajo različne vrste orodij za sledenje napakam in z njimi povezanimi procesi - postane skupni sistem sledenja med različnimi ravnmi vodstva in tehničnim osebjem.
Ker je resnost okvar bolj v pristojnosti te funkcije, testni inženir določi resnost napake. Razvijalci včasih sodelujejo pri vplivanju na resnost napake, večinoma pa je to odvisno od preizkuševalca, saj oceni, koliko lahko določena funkcija vpliva na splošno delovanje.
Po drugi strani pa, ko gre za določanje prioritete napake, čeprav prvotno avtor napak določi prednost, ga dejansko določi vodja izdelka, saj ima splošen pogled na izdelek in kako hitro je treba določeno napako odpraviti . Preizkuševalec ni idealna oseba, ki bi določila prioriteto napake.
Kakor se zdi to šokantno, obstajata dva različna primera, zakaj:
Primer # 1) Upoštevajte, da uporabnik najde napako pri poimenovanju samega izdelka ali težavo z dokumentacijo uporabniškega vmesnika. Tester bi običajno odprl manjšo / kozmetično napako in ga je mogoče zelo enostavno odpraviti, toda ko gre za videz in občutek izdelka / uporabniško izkušnjo, bi lahko povzročil resen vpliv.
2. primer) Obstajajo lahko določeni pogoji, pod katerimi pride do določene napake, ki je lahko izjemno redka ali v kupčevem okolju ni možnosti za zadetek. Čeprav se to preizkuševalcu glede na funkcionalnost zdi to prednostna napaka, glede na redkost pojavljanja in visoke stroške odprave - bi bila to razvrščena kot napaka nizke prioritete.
Zato v bistvu prednost napak običajno določi upravitelj izdelka na sestanku »triaža napak«.
Različne ravni
Prednost in resnost imata med njimi nekatere klasifikacije, ki pomagajo določiti, kako je treba odpraviti napako. Veliko različnih organizacij je različna orodja za beleženje napak , zato se lahko ravni razlikujejo.
Oglejmo si različne ravni tako za prednost kot za resnost.
- Visoka prednost, visoka resnost
- Visoka prednost, nizka resnost
- Visoka resnost, nizka prednost
- Nizka resnost, nizka prednost
Naslednja slika prikazuje razvrstitev kategorij v enem delčku.
# 1) Visoka resnost in visoka prednost
Vsaka kritična / večja napaka poslovnega primera se samodejno poviša v to kategorijo.
Morebitne napake, zaradi katerih se preskušanje ne more nadaljevati za vsako ceno ali povzroči resno okvaro sistema, spadajo v to kategorijo. Na primer, s klikom na določen gumb se funkcija ne naloži sama. Ali izvajanje določene funkcije dosledno ruši strežnik in povzroča izgubo podatkov. Rdeče črte na zgornji sliki označujejo tovrstne napake.
Na primer,
Sistem se zruši, ko ste izvedli plačilo ali ko izdelkov ne morete dodati v košarico, je ta napaka označena kot napaka visoke resnosti in visoke prioritete.
Še en primer bi bila funkcija valut za prodajo na bankomatih, pri kateri po vnosu pravilnega uporabniškega imena in gesla naprava ne izda denarja, ampak odšteje preneseni z vašega računa.
# 2) Visoka prednost in nizka resnost
Vse manjše resne napake, ki bi lahko neposredno vplivale na uporabniško izkušnjo, se samodejno povišajo v to kategorijo.
V to kategorijo spadajo napake, ki jih je treba odpraviti, vendar ne vplivajo na vlogo.
Na primer, funkcija naj bi uporabniku prikazala določeno napako v zvezi s svojo povratno kodo. V tem primeru bo funkcionalno koda povzročila napako, sporočilo pa mora biti bolj pomembno za ustvarjeno povratno kodo. Modre črte na sliki označujejo tovrstne napake.
Na primer,
Logotip podjetja na prvi strani je napačen, šteje se, da je Visoka prednost in nizka resnost napaka .
Primer 1) Na spletnem mestu za spletno nakupovanje, če je logotip FrontPage napačno napisan, na primer namesto Flipkart, se piše kot Flipkart.
Primer 2) V logotipu banke je namesto ICICI zapisano kot ICCCI.
Kar zadeva funkcionalnost, ne vpliva na nič, zato ga lahko označimo kot nizko resnost, vendar vpliva na uporabniško izkušnjo. Tovrstne napake je treba odpraviti z visoko prioriteto, čeprav imajo zelo manjši vpliv na aplikacijsko stran.
# 3) Visoka resnost in nizka prednost
Kakršna koli napaka, ki funkcionalno ne izpolnjuje zahtev ali ima kakršne koli funkcionalne posledice za sistem, vendar jo zainteresirane strani ob strani kritično spremenijo, samodejno preide v to kategorijo.
Napake, ki jih je treba odpraviti, vendar ne takoj. To se lahko posebej zgodi med priložnostnim testiranjem. To pomeni, da je funkcionalnost v veliki meri prizadeta, vendar jo opazimo le, kadar uporabimo nekatere neobičajne vhodne parametre.
Na primer, določeno funkcionalnost je mogoče uporabiti le v poznejši različici vdelane programske opreme, zato da bi to preveril - preizkuševalec dejansko zniža svoj sistem in izvede preizkus ter opazi resno težavo s funkcionalnostjo, ki je veljavna. V tem primeru bodo napake razvrščene v to kategorijo, označeno z rožnatimi črtami, saj se običajno pričakuje, da bodo končni uporabniki imeli višjo različico vdelane programske opreme.
Na primer,
Če je na spletnem mestu za družabna omrežja izdana beta različica nove funkcije, ki jo od danes ne uporablja veliko aktivnih uporabnikov. Vsako napako na tej funkciji lahko označimo kot nizko prioritetno, saj se zaradi poslovne razvrstitve kot nepomembne funkcija vrne v prejšnje stanje.
Čeprav ima ta funkcija funkcionalno napako, saj ne vpliva neposredno na končne kupce, lahko poslovni deležnik napako razvrsti pod nizko prioriteto, čeprav ima hud funkcionalni vpliv na aplikacijo.
To je napaka visoke resnosti, vendar jo je mogoče dati prednost nizki prioriteti, saj jo je mogoče popraviti z naslednjo izdajo kot zahtevo za spremembo. Interesne skupine v podjetjih prav tako dajo to funkcijo prednost redko uporabljeni funkciji in ne vplivajo na druge funkcije, ki neposredno vplivajo na uporabniško izkušnjo. Tovrstne napake lahko razvrstimo pod Visoka resnost, vendar nizka prednost kategoriji.
# 4) Nizka resnost in nizka prednost
Vse napake pri črkovanju / ohišje pisave / neusklajenost v odstavku 3rdali 4thstrani aplikacije in ne na glavni ali prvi strani / naslovu.
Te napake so razvrščene v zelene črte, kot je prikazano na sliki, in se pojavijo, kadar ni vpliva na funkcionalnost, vendar kljub temu v majhni meri ne ustrezajo standardom. Na splošno so tukaj razvrščene kozmetične napake ali recimo dimenzije celice v tabeli na uporabniškem vmesniku.
Na primer,
Če je v pravilniku o zasebnosti spletnega mesta črkovalna napaka, je ta napaka nastavljena kot Nizka resnost in nizka prednost.
Smernice
Spodaj so določene smernice, ki jih mora poskusiti upoštevati vsak preizkuševalec:
- Prvič, dobro razumite pojma prednost in resnost. Izogibajte se zamenjavi enega z drugim in njihove izmenjave. V skladu s tem upoštevajte smernice glede resnosti, ki jih je objavila vaša organizacija / ekipa, tako da so vsi na isti strani.
- Vedno izberite stopnjo resnosti glede na vrsto izdaje, saj bo to vplivalo na njeno prednost. Nekaj primerov je:
- Za težavo, ki je kritična, na primer celoten sistem pade in ni mogoče storiti ničesar - te resnosti ne bi smeli uporabljati za odpravljanje napak v programu.
- Za glavno težavo, na primer v primerih, ko funkcija ne deluje po pričakovanjih, bi lahko to resnost uporabili za obravnavo novih funkcij ali izboljšanje trenutnega delovanja.
Ne pozabite, da bo izbira prave stopnje resnosti povzročila napako, saj je to prednostna naloga.
- Kot tester - razumeti, kako določena funkcionalnost, namesto da bi podrobneje analizirala, - razumeti, kako bi določen scenarij ali testni primer vplival na končnega uporabnika. To vključuje veliko sodelovanja in interakcije z razvojno skupino, poslovnimi analitiki, arhitekti, vodjo preskusov in vodjo za razvoj. V razpravah morate upoštevati tudi, koliko časa bi potrebovali za odpravo napake glede na njeno zapletenost in čas, da to napako preverite.
- Končno , lastnik izdelka je vedno tisti, ki ima moč veta na sprostitev, zato je treba napako odpraviti. Ker pa triažne seje napak vsebujejo različne člane, ki predstavijo svoj pogled na napako na podlagi primera, v takem času, če so razvijalci in preizkuševalci sinhronizirani, to zagotovo pomaga pri vplivanju na odločitev.
Zaključek
Med odkrivanjem napak je preskuševalec odgovoren, da napakam dodeli pravo resnost. Nepravilna resnost in s tem preslikava prioritet ima lahko zelo drastične posledice na celoten postopek STLC in na izdelek kot celoto. Na več zaposlitvenih razgovorih je postavljenih več vprašanj o prednostnih nalogah in resnosti, da bi zagotovili, da imate kot preizkuševalec te koncepte v mislih brezhibno jasne.
Prav tako smo v živo videli primere, kako napako razvrstiti med različna področja resnosti / prioritete. Do zdaj bi si želel, da bi imeli dovolj pojasnil glede razvrstitve napak tako na področjih resnosti / prioritete.
Upam, da je ta članek popoln vodnik za razumevanje stopnje prioritete in stopnje resnosti. V spodnjih komentarjih nam sporočite svoje misli / vprašanja.
Priporočeno branje
- Kaj je tehnika preskušanja na podlagi pomanjkljivosti?
- Kaj je življenjski cikel napak / napak pri testiranju programske opreme? Vadnica za življenjski cikel napak
- Proces upravljanja z napakami: Kako učinkovito obvladovati napake
- Kako razmnožiti neobnovljivo napako in si prizadevati za preizkušanje
- 7 načel preizkušanja programske opreme: grozdenje napak in princip Pareto
- Metode in tehnike preprečevanja napak
- Natančna razlika med preverjanjem in potrjevanjem s primeri
- 3 strategije za obvladovanje pomanjkljivosti blokatorja