defect severity priority testing with examples
U ovom ćete tutorijalu naučiti što su ozbiljnost i prioritet nedostataka u testiranju, kako postaviti prioritete i razinu ozbiljnosti nedostataka s primjerima da biste jasno razumjeli koncept.
Također ćemo detaljno pokriti kako klasificirati nedostatke u različite skupine i njihovu važnost u životnom ciklusu kvarova. Također ćemo pokriti presudnu ulogu klasifikacije živim nizom primjera.
Defekti u arhiviranju vrlo su sastavni dijelovi dio životnog ciklusa testiranja softvera . Postoji nekoliko najboljih praksi definiranih za učinkovito izvještavanje o nedostacima putem interneta ili u organizacijama.
Što ćete naučiti:
- Pregled praćenja kvarova
Pregled praćenja kvarova
Jedan od važnih aspekata životnog ciklusa kvarova na generičkoj razini uključuje praćenje nedostataka. To je važno jer ispitni timovi kod testiranja dijela softvera koji se množi samo ako je određeni sustav koji se testira složen otkrivaju nekoliko nedostataka. U takvom scenariju upravljanje tim nedostacima i njihova analiza s ciljem zatvaranja može biti zastrašujući zadatak.
U skladu s postupcima održavanja kvara, kada bilo koji ispitivač prijavi kvar - osim metode / opisa kako bi reproducirao uočeni problem, on mora dostaviti i neke kategorične podatke koji bi pomogli netočnoj klasifikaciji kvara. To bi, pak, pomoglo u učinkovitom procesu praćenja / održavanja kvara i također bi predstavljalo osnovu za brže vrijeme otklanjanja kvara.
Dva glavna parametra koja čine osnovu za učinkovito praćenje i rješavanje nedostataka su:
- Prioritet nedostataka u ispitivanju
- Težina oštećenja u ispitivanju
To su često zbunjujući koncept i gotovo se međusobno koriste ne samo među testnim timovima već i među razvojnim timovima. Tanka je linija između njih dvoje i važno je shvatiti da doista postoje razlike između njih dvoje.
Razumijemo ukratko teorijske definicije dva parametra u sljedećem odjeljku.
Što je ozbiljnost i prioritet nedostataka?
Prioritet prema engleskoj definiciji koristi se u usporedbi dviju stvari ili uvjeta, pri čemu se jednom mora dati veća važnost od drugog (ih) i prvo se mora riješiti / riješiti prije nego što se prijeđe na sljedeći (e). Stoga bi u kontekstu nedostataka prioritet kvara ukazivao na hitnost kojom bi ga trebalo popraviti.
Ozbiljnost se prema engleskoj definiciji koristi za opisivanje težine nepoželjne pojave. Dakle, kada je riječ o programskim pogreškama, ozbiljnost programske pogreške ukazuje na učinak koji ima na sustav u smislu utjecaja.
Tko ih definira?
QA klasificira defekt pod odgovarajuću težinu na temelju složenosti i kritičnosti nedostataka.
Svi dionici u tvrtki, uključujući voditelje projekata, poslovne analitičare, vlasnike proizvoda definiraju prioritet nedostataka.
Sljedeća slika prikazuje ulogu tko je vlasnik i klasificira kritičnost i težinu nedostataka.
Kako odabrati ove razine?
Kao što smo već razgovarali, ispitivač procjenjuje parametar ozbiljnosti, dok parametar prioriteta uglavnom procjenjuje voditelj proizvoda ili u osnovi trijažni tim. Iako je to slučaj, težina nedostatka definitivno je jedan od vodećih i utjecajnih čimbenika za određivanje prioriteta nedostatka. Stoga je važno kao testera odabrati pravu ozbiljnost kako bi se izbjegla zabuna s razvojnim timovima.
Razlika između težine i prioriteta
Prioritet je povezan s raspoređivanjem, a 'ozbiljnost' je povezana sa standardima.
'Prioritet' znači da se nešto daje ili zaslužuje prethodnu pozornost; prednost utvrđena prema važnosti (ili hitnosti).
'Ozbiljnost' je stanje ili kvaliteta ozbiljnosti; ozbiljan podrazumijeva poštivanje rigoroznih standarda ili visokih načela i često sugerira grubost; ozbiljna je obilježena ili zahtijeva strogo poštivanje rigoroznih standarda ili visokih načela, Na primjer, ozbiljan kodeks ponašanja.
Riječi prioritet i ozbiljnost pojavljuju se u praćenju bugova.
Dostupni su razni komercijalni softverski alati za praćenje i upravljanje problemima. Ovi alati, uz detaljan unos inženjera za testiranje softvera, daju timu potpune informacije kako bi programeri mogli razumjeti grešku, steći ideju o njenoj 'ozbiljnosti', reproducirati je i popraviti.
Ispravci se temelje na projektu 'Prioriteti' i 'Ozbiljnost' bugova.
'Težina' problema definira se u skladu s procjenom rizika kupca i bilježi u odabranom alatu za praćenje.
Buggy softver može ‘ozbiljno’ utjecati na rasporede, što zauzvrat može dovesti do ponovne procjene i ponovnog pregovaranja o ‘prioritetima’.
Što je prioritet?
Prioritet je, kao što i samo ime govori, prioritet određivanju kvara na temelju poslovnih potreba i težine kvara. Prioritet označava važnost ili hitnost popravljanja nedostatka.
Dok otvara kvar, ispitivač općenito u početku dodjeljuje prioritet dok proizvod gleda s perspektive krajnjeg korisnika. U skladu s tim, postoje različite razine:
Općenito, prioritet oštećenja može se klasificirati na sljedeći način:
Prioritet br. 1) Neposredan / kritičan (P1)
To se mora popraviti odmah u roku od 24 sata. To se obično događa u slučajevima kada je cijela funkcionalnost blokirana i kao rezultat toga ne može se nastaviti testiranje. Ili u nekim drugim slučajevima ako postoji značajno curenje memorije, tada se kvar klasificira kao prioritet -1 što znači da je program / značajka neupotrebljiva u trenutnom stanju.
Bilo koji nedostatak kojem je potrebna neposredna pažnja koji utječe na postupak ispitivanja klasificirat će se u neposrednu kategoriju
Svi Kritična težina nedostaci spadaju u ovu kategoriju (osim ako ih poslovni subjekti ne odrede po prioritetu)
Prioritet # 2) Visok (P2)
Nakon što se utvrde kritični nedostaci, nedostatak s ovim prioritetom sljedeći je kandidat koji se mora popraviti za bilo koju testnu aktivnost kako bi odgovarao kriterijima „izlaza“. Obično kada značajka nije upotrebljiva onakva kakva bi trebala biti zbog programske neispravnosti ili zbog toga što se novi kôd mora napisati ili ponekad čak i zbog toga što se kroz kôd mora riješiti neki okolišni problem, kvar se može kvalificirati za prioritet 2 .
Ovo je kvar ili problem koji bi se trebao riješiti prije izdavanja. Te bi nedostatke trebalo riješiti nakon što se riješe kritična pitanja.
Svi Majore ozbiljnost nedostaci spadaju u ovu kategoriju.
Prioritet br. 3) Srednji (P3)
Neispravnost s ovim prioritetom mora biti sporna da bi se otklonila, jer bi se mogla baviti i problemima s funkcionalnošću koji nisu prema očekivanjima. Ponekad se čak i kozmetičke pogreške, poput očekivanja prave poruke o pogrešci tijekom kvara, mogu kvalificirati kao prioritetna 3 pogreška.
Ovaj bi kvar trebao biti riješen nakon što se otklone sve ozbiljne programske pogreške.
Jednom kada se izvrše kritične i visokoprioritetne pogreške, možemo se odlučiti za srednje buke.
Svi Maloljetnik ozbiljnost nedostaci spadaju u ovu kategoriju.
Prioritet # 4) Nizak (P4)
Neispravnost s niskim prioritetom ukazuje na to da definitivno postoji problem, ali ne mora se popraviti kako bi odgovarao kriterijima 'izlaska'. Međutim, to se mora popraviti prije nego što se izvrši GA. Ovdje se obično mogu kategorizirati neke tipkarske pogreške ili čak kozmetičke pogreške o kojima je ranije bilo riječi.
Ponekad se otvaraju i nedostaci s niskim prioritetom kako bi se predložila neka poboljšanja u postojećem dizajnu ili zahtjev za implementacijom male značajke za poboljšanje korisničkog iskustva.
Ovaj se kvar može riješiti u budućnosti i ne treba mu neposredna pažnja Niska ozbiljnost nedostaci spadaju u ovu kategoriju.
Kao što je već spomenuto, prioritet određuje koliko brzo mora biti vrijeme obrade kvara. Ako postoji više nedostataka, prioritet odlučuje koji se nedostatak mora popraviti i odmah provjeriti naspram toga koji se nedostatak može popraviti nešto kasnije.
Što je ozbiljnost?
Ozbiljnost definira u kojoj mjeri bi određeni nedostatak mogao stvoriti utjecaj na aplikaciju ili sustav.
Ozbiljnost je parametar koji označava implikaciju kvara na sustav - koliko je kvar kritičan i kakav je utjecaj kvara na funkcionalnost cijelog sustava? Ozbiljnost je parametar koji postavlja ispitivač dok otvara kvar i uglavnom kontrolira ispitivača. Opet različite organizacije imaju različite alate za upotrebu kod nedostataka, ali na generičkoj razini to su sljedeće razine ozbiljnosti:
Na primjer, Razmotrite sljedeće scenarije
- Ako korisnik pokuša obaviti internetsku kupnju, a aplikacija se ne učita ili će se pojaviti poruka nedostupna na poslužitelju.
- Korisnik izvršava dodavanje predmeta u košaricu, dodani broj je netočan / dodaje se pogrešan proizvod.
- Korisnik vrši uplatu, a nakon uplate narudžba ostaje u košarici onako kako je rezervirana, a potvrđena.
- Sustav prihvaća narudžbu, ali konačno otkazuje narudžbu nakon pola sata zbog bilo kakvih problema.
- Sustav prihvaća 'Dodaj u košaricu' samo dvostrukim klikom, umjesto jednim klikom.
- Gumb Dodaj u košaricu piše se kao Dodaj u košaricu.
Kakvo bi bilo korisničko iskustvo ako bi se mogao dogoditi bilo koji od gore navedenih scenarija?
Široko se nedostaci mogu klasificirati na sljedeći način:
# 1) Kritično (S1)
Kvar koji u potpunosti otežava ili blokira testiranje proizvoda / značajke kritični je nedostatak. Primjer bi mogao biti u slučaju testiranja korisničkog sučelja kada korisničko sučelje nakon prolaska kroz čarobnjak jednostavno visi u jednom oknu ili ne ide dalje da bi pokrenulo funkciju. Ili u nekim drugim slučajevima, kada značajka koja je sama razvijena nedostaje u izradi.
Iz bilo kojeg razloga, ako se aplikacija sruši ili postane neupotrebljiva / ne može nastaviti dalje, kvar se može klasificirati pod kritičnom težinom.
Bilo koji katastrofalni kvar na sustavu mogao bi dovesti korisnika do neupotrebljivosti aplikacija i mogao bi se klasificirati pod kritičnu težinu
Na primjer, U davatelju usluga e-pošte poput Yahooa ili Gmaila, nakon upisivanja ispravnog korisničkog imena i lozinke, umjesto prijave sustav se ruši ili baca poruku o pogrešci, ovaj je kvar klasificiran kao kritičan jer ovaj kvar čini cijelu aplikaciju neupotrebljivom.
Gore spomenuti scenarij iz točke 1 mogao bi se klasificirati kao kritični nedostatak jer mrežna aplikacija postaje potpuno neupotrebljiva.
# 2) Glavni (S2)
Bilo koja glavna značajka koja je implementirana koja ne udovoljava njezinim zahtjevima / slučajevima korištenja i ponaša se drugačije od očekivanog, može se klasificirati pod ozbiljnost glavne.
Glavni nedostatak javlja se kada funkcionalnost funkcionira daleko od očekivanja ili ne radi ono što bi trebala raditi. Primjer bi mogao biti: Recimo da na prekidaču treba postaviti VLAN, a vi koristite predložak korisničkog sučelja koji pokreće ovu funkciju. Kada ovaj predložak za konfiguriranje VLAN-a ne uspije na prekidaču, klasificira se kao ozbiljan nedostatak funkcionalnosti.
Na primjer, Kada davatelj usluga e-pošte poput Yahooa ili Gmaila ne smije dodati više primatelja u odjeljak CC, ovaj je kvar klasificiran kao Glavni kvar jer glavna funkcionalnost aplikacije ne radi ispravno.
Što se očekuje od odjeljka CC u pošti, to bi trebalo omogućiti korisniku da doda više korisnika. Dakle, kada glavna funkcionalnost aplikacije ne radi ispravno ili se ponaša drugačije od očekivanog, to je glavni nedostatak.
Gore spomenuti scenariji u točkama 2 i 3 mogli bi se klasificirati kao glavni nedostaci, jer se očekuje da će se red glatko premjestiti u sljedeću fazu životnog ciklusa narudžbe, ali u stvarnosti se razlikuje u ponašanju.
Bilo koji nedostatak koji bi mogao dovesti do netočne trajnosti podataka, problema s podacima ili pogrešnog ponašanja aplikacije mogao bi se široko klasificirati pod glavnom težinom.
# 3) Malo / umjereno (S3)
Bilo koja implementirana značajka koja ne udovoljava svojim zahtjevima / slučajevima korištenja i ponaša se drugačije od očekivanog, ali utjecaj je donekle zanemariv ili nema veći utjecaj na aplikaciju, može se klasificirati u kategoriju Mala težina.
Umjereni nedostatak javlja se kada proizvod ili aplikacija ne ispunjava određene kriterije ili još uvijek pokazuje neprirodno ponašanje, međutim, to ne utječe na funkcionalnost u cjelini. Na primjer, u gornjoj implementaciji predloška VLAN-a, pojavit će se umjerena ili normalna greška kada se predložak uspješno postavi na prekidač, međutim, nema indikacije da se šalje korisniku.
Na primjer, U davatelju usluga e-pošte poput Yahooa ili Gmaila postoji opcija koja se naziva 'Uvjeti i odredbe' i u toj će opciji biti više veza u vezi s uvjetima i odredbama web stranice. Kada jedna od više veza ne radi u redu, naziva se manjom ozbiljnošću, jer utječe samo na manju funkcionalnost aplikacije i nema velik utjecaj na uporabljivost aplikacije.
Gore spomenuti scenarij iz točke 5. mogao bi se klasificirati kao Manji nedostatak, jer nema gubitka ili neuspjeha podataka u redoslijedu toka sustava, ali male neugodnosti kada je u pitanju korisničko iskustvo.
Ove vrste kvarova rezultiraju minimalnim gubitkom funkcionalnosti ili korisničkog iskustva.
# 4) Nisko (S4)
Bilo koji kozmetički nedostaci, uključujući pravopisne pogreške ili probleme s poravnavanjem ili kućište fonta, mogu se svrstati u kategoriju Niska ozbiljnost.
Manji bug male ozbiljnosti pojavljuje se kada gotovo nema utjecaja na funkcionalnost, ali svejedno je to valjani kvar koji treba ispraviti. Primjeri toga mogu uključivati pravopisne pogreške u porukama pogrešaka ispisane korisnicima ili nedostatke radi poboljšanja izgleda i izgleda značajke.
Na primjer, U davatelju usluga e-pošte poput Yahooa ili Gmaila primijetili biste 'stranicu s licencom', ako na stranici postoje pravopisne pogreške ili neusklađenost, ovaj je kvar klasificiran kao nizak.
Gore spomenuti scenarij iz točke 6 mogao bi se klasificirati kao Niski nedostatak jer je gumb Dodaj prikazan u pogrešnom kućištu. Ova vrsta kvara neće imati utjecaja na ponašanje sustava ili prezentaciju podataka, gubitak podataka ili protok podataka, pa čak ni na korisničko iskustvo, ali bit će vrlo kozmetička.
Da rezimiramo, sljedeća slika prikazuje široku klasifikaciju defekata koja se temelji na težini i prioritetu:
Primjeri
Kao što je već spomenuto, budući da različite organizacije koriste različite vrste alata za praćenje kvarova i s njima povezane procese, to postaje uobičajeni sustav praćenja između različitih razina menadžmenta i tehničkog osoblja.
Budući da je ozbiljnost nedostataka više u djelokrugu funkcionalnosti, inženjer za ispitivanje postavlja ozbiljnost nedostatka. Ponekad programeri sudjeluju u utjecaju na ozbiljnost kvara, ali uglavnom to ovisi o ispitivaču jer procjenjuje koliko određena značajka može utjecati na cjelokupno funkcioniranje.
S druge strane, što se tiče postavljanja prioriteta kvara, iako u početku začetnik kvara postavlja prioritet, to zapravo definira voditelj proizvoda jer ima cjelokupni prikaz proizvoda i koliko brzo se određeni kvar mora otkloniti . Ispitivač nije idealna osoba za postavljanje prioriteta kvara.
Koliko god ovo izgleda šokantno, postoje dva različita primjera zašto:
Primjer # 1) Uzmite u obzir da postoji situacija kada korisnik pronađe pogrešku u imenovanju samog proizvoda ili neki problem s UI dokumentacijom. Ispitivač bi obično otkrio manju / kozmetičku manu i mogao bi biti vrlo jednostavan za otklanjanje, ali što se tiče izgleda i osjećaja proizvoda / korisničkog iskustva, to bi moglo izazvati ozbiljan utjecaj.
Primjer # 2) Mogu postojati određeni uvjeti pod kojima se događa određena neispravnost koja može biti iznimno rijetka ili nema mogućnosti za napad u okruženju kupca. Iako se s aspekta funkcionalnosti ovo ispitniku može činiti kao visokoprioritetna, s obzirom na rijetkost pojavljivanja i visoku cijenu za otklanjanje - to bi bilo klasificirano kao kvar niskog prioriteta.
Stoga u stvari prioritet kvara obično postavlja upravitelj proizvoda na sastanku 'trijaže kvara'.
Različite razine
Prioritet i težina među njima imaju neke klasifikacije koje pomažu u određivanju načina na koji se mora riješiti nedostatak. Puno različitih organizacija ima različiti alati za bilježenje nedostataka , tako da se razine mogu razlikovati.
Pogledajmo različite razine i za prioritet i za ozbiljnost.
- Visoki prioritet, velika ozbiljnost
- Visoki prioritet, niska ozbiljnost
- Visoka ozbiljnost, nizak prioritet
- Niska ozbiljnost, nizak prioritet
Sljedeća slika prikazuje klasifikaciju kategorija u jednom isječku.
top mp3 glazbeni downloader za android
# 1) Visoka težina i visoki prioritet
Bilo koji kritični / veliki poslovni slučaj automatski se promovira u ovu kategoriju.
U ovu kategoriju spadaju svi nedostaci zbog kojih se ispitivanje ne može nastaviti po svaku cijenu ili uzrokuje ozbiljne kvarove sustava. Na primjer, klik na određeni gumb ne učitava samu značajku. Ili izvođenje određene funkcije dosljedno ruši poslužitelj i uzrokuje gubitak podataka. Crvene linije na gornjoj slici označavaju ove vrste nedostataka.
Na primjer,
Sustav se sruši nakon što izvršite uplatu ili kada ne možete dodati stavke u košaricu, ovaj je kvar označen kao kvar visoke ozbiljnosti i visokog prioriteta.
Još jedan primjer bila bi značajka valute za prodaju na bankomatu u kojoj nakon unosa ispravnog korisničkog imena i lozinke uređaj ne dijeli novac već oduzima preneseni s vašeg računa.
# 2) Visoki prioritet i niska ozbiljnost
Sve manje ozbiljne greške koje bi mogle izravno utjecati na korisničko iskustvo automatski se promoviraju u ovu kategoriju.
U ovu kategoriju spadaju nedostaci koji se moraju otkloniti, ali ne utječu na prijavu.
Na primjer, očekuje se da će značajka korisniku prikazati određenu pogrešku u vezi s povratnim kodom. U ovom slučaju, funkcionalno će kôd izbaciti pogrešku, ali poruka će morati biti relevantnija za generirani povratni kôd. Plave crte na slici označavaju ove vrste nedostataka.
Na primjer,
Logotip tvrtke na naslovnoj stranici pogrešan je, smatra se Visoki prioritet i niska ozbiljnost mana .
Primjer 1) Na web mjestu za internetsku kupnju kada je pogrešno napisan logotip FrontPage, na primjer umjesto Flipkart, piše se kao Flipkart.
Primjer 2) U logotipu banke umjesto ICICI zapisano je kao ICCCI.
Što se tiče funkcionalnosti, to ne utječe ni na što pa ga možemo označiti kao Nisku ozbiljnost, ali utječe na korisničko iskustvo. Ovu vrstu kvara treba popraviti s visokim prioritetom iako imaju vrlo manji utjecaj na strani aplikacije.
# 3) Visoka ozbiljnost i nizak prioritet
Bilo koji nedostatak koji funkcionalno ne udovoljava zahtjevima ili ima bilo kakvih funkcionalnih implikacija na sustav, ali dionici ga poništavaju kada se radi o poslovnoj kritičnosti, automatski se promovira u ovu kategoriju.
Kvarovi koji se moraju otkloniti, ali ne odmah. To se posebno može dogoditi tijekom ad-hoc testiranja. To znači da je funkcionalnost pogođena u velikoj mjeri, ali se promatra samo kada se koriste određeni neuobičajeni ulazni parametri.
Na primjer, određena funkcionalnost može se koristiti samo na kasnijoj verziji firmware-a, pa da bi to provjerio - ispitivač zapravo smanjuje svoj sustav i izvodi test te uočava ozbiljan problem s funkcionalnošću koji je valjan. U tom će se slučaju nedostaci klasificirati u ovu kategoriju označenu ružičastim crtama, jer se obično očekuje da krajnji korisnici imaju višu verziju firmvera.
Na primjer,
Na web mjestu za društvene mreže, ako se izda beta verzija nove značajke s malo aktivnih korisnika koji koriste tu mogućnost od danas. Bilo koji nedostatak koji se pronađe na ovoj značajci može se klasificirati kao nizak prioritet jer se značajka vraća natrag zbog poslovne klasifikacije kao nevažne.
Iako ova značajka ima funkcionalni nedostatak, jer ne utječe izravno na krajnje kupce, dionički subjekt može klasificirati nedostatak pod nizak prioritet, iako ima ozbiljan funkcionalni utjecaj na aplikaciju.
Ovo je greška velike ozbiljnosti, ali se može dati prioritet niskom prioritetu, jer se sa sljedećim izdanjem može popraviti kao zahtjev za promjenom. Poslovni dionici također daju ovu značajku prioritetu kao rijetko korištenu značajku i ne utječu na bilo koje druge značajke koje imaju izravan utjecaj na korisničko iskustvo. Ova vrsta oštećenja može se klasificirati pod Visoka ozbiljnost, ali nizak prioritet kategorija.
# 4) Niska ozbiljnost i nizak prioritet
Bilo kakve pravopisne pogreške / slovo fonta / neusklađenost u stavku 3rdili 4thstranici prijave, a ne na glavnoj ili naslovnoj stranici / naslovu.
Ovi se kvarovi klasificiraju u zelene crte kao što je prikazano na slici i javljaju se kada nema utjecaja na funkcionalnost, ali još uvijek ne ispunjavaju standarde u maloj mjeri. Općenito su ovdje klasificirane kozmetičke pogreške ili recimo dimenzije stanice u tablici na korisničkom sučelju.
Na primjer,
Ako pravila o privatnosti web mjesta sadrže pravopisnu pogrešku, taj se kvar postavlja kao Niska ozbiljnost i nizak prioritet.
Smjernice
Ispod su određene smjernice koje svaki tester mora pokušati slijediti:
- Prvo, dobro razumite koncepte prioriteta i ozbiljnosti. Izbjegavajte brkati jedno s drugim i upotrebljavati ih naizmjenično. U skladu s tim, slijedite smjernice ozbiljnosti koje je objavila vaša organizacija / tim tako da svi budu na istoj stranici.
- Uvijek odaberite razinu ozbiljnosti na temelju vrste problema, jer će to utjecati na prioritet. Neki primjeri su:
- Za problem koji je kritičan, kao što je pad cijelog sustava i ništa se ne može učiniti - ova težina ne smije se koristiti za rješavanje programskih nedostataka.
- Za glavni problem, na primjer u slučajevima kada funkcija ne radi kako se očekivalo - ova težina bi se mogla koristiti za rješavanje novih funkcija ili poboljšanje u trenutnom radu.
Imajte na umu da će odabir prave razine ozbiljnosti zauzvrat dati nedostatak, to je dužni prioritet.
- Kao tester - razumjeti kako određena funkcionalnost, radije detaljno analizirajući - razumjeti kako će određeni scenarij ili testni slučaj utjecati na krajnjeg korisnika. To uključuje puno suradnje i interakcije s razvojnim timom, poslovnim analitičarima, arhitektima, voditeljem ispitivanja, vodstvom za razvoj. U svojim raspravama također trebate uzeti u obzir koliko bi vremena bilo potrebno za otklanjanje kvara na temelju njegove složenosti i vremena da biste ga utvrdili.
- Konačno , uvijek je vlasnik proizvoda onaj koji ima pravo veta na otpuštanje, a nedostatak bi trebao biti otklonjen. Međutim, budući da sesije trijaže defekata sadrže različite članove koji na temelju slučaja iznose svoje stajalište o nedostatku, u takvom trenutku ako su programeri i testeri sinkronizirani, to sigurno pomaže u utjecaju na odluku.
Zaključak
Dok otvara nedostatke, ispitivač je odgovoran dodijeliti ispravnu težinu nedostacima. Neispravna ozbiljnost, a time i mapiranje prioriteta mogu imati vrlo drastične posljedice na cjelokupni STLC postupak i na proizvod u cjelini. Na nekoliko razgovora za posao - postavlja se nekoliko pitanja o prioritetu i ozbiljnosti kako biste osigurali da vam kao testeru ovi pojmovi budu besprijekorno jasni.
Također, uživo smo vidjeli primjere kako klasificirati kvar pod razna područja ozbiljnosti / prioriteta. Do sada bih volio da imate dovoljno razjašnjenja o klasifikaciji grešaka i u segmentima ozbiljnosti / prioriteta.
Nadam se da je ovaj članak cjelovit vodič za razumijevanje prioriteta i razine oštećenja. Javite nam svoje misli / pitanja u komentarima ispod.
Preporučena literatura
- Što je tehnika ispitivanja na temelju nedostataka?
- Što je životni ciklus oštećenja / grešaka u testiranju softvera? Vodič za životni ciklus oštećenja
- Proces upravljanja nedostacima: Kako učinkovito upravljati nedostacima
- Kako reproducirati neproduktivni nedostatak i uložiti trud u testiranje
- 7 principa testiranja softvera: klasteriranje nedostataka i Pareto princip
- Metode i tehnike sprečavanja nedostataka
- Točna razlika između provjere i provjere valjanosti s primjerima
- 3 strategije za suočavanje s nedostatkom blokera