defect severity priority testing with examples
În acest tutorial, veți afla ce este severitatea și prioritatea defectelor în testare, cum să setați nivelurile de prioritate și severitate a defectelor, cu exemple pentru a înțelege clar conceptul.
De asemenea, vom acoperi în detaliu modul de clasificare a defectelor sub diferite găleți și relevanța lor în ciclul de viață a defectelor. De asemenea, vom acoperi rolul crucial al clasificării cu un set live de exemple.
Depunerea defectelor este foarte integrantă parte a ciclului de viață al testării software-ului . Există mai multe bune practici definite pentru raportarea efectivă a defectelor pe internet sau în organizații.
Ce veți învăța:
- Prezentare generală a urmăririi defectelor
Prezentare generală a urmăririi defectelor
Unul dintre aspectele importante ale ciclului de viață al defectelor la nivel generic include urmărirea defectelor. Acest lucru este important, deoarece echipele de testare deschid mai multe defecte atunci când testează o bucată de software care se înmulțește numai dacă sistemul particular testat este complex. Într-un astfel de scenariu, gestionarea acestor defecte și analizarea acestor defecte pentru a determina închiderea poate fi o sarcină descurajantă.
În conformitate cu procesele de întreținere a defectelor, atunci când orice tester depune un defect - în afară de metodă / descriere pentru a reproduce problema văzută, el trebuie să furnizeze și câteva informații categorice care ar ajuta la clasificarea inexactă a defectului. Acest lucru, la rândul său, ar contribui la procesele eficiente de urmărire / întreținere a defectelor și ar constitui, de asemenea, baza pentru o perioadă mai scurtă de timp de răspuns.
Cei doi parametri principali care stau la baza unei urmăriri și rezolvări efective a defectelor sunt:
- Prioritatea defectelor în testare
- Severitatea defectului în testare
Acestea sunt adesea un concept confuz și sunt aproape utilizate interschimbabil nu numai între echipele de testare, ci și echipele de dezvoltare. Există o linie fină între cele două și este important să înțelegem că există într-adevăr diferențe între cele două.
Să înțelegem pe scurt definițiile teoretice ale celor doi parametri din secțiunea următoare.
Ce este severitatea și prioritatea defectelor?
Prioritatea prin definiția engleză este utilizată în compararea a două lucruri sau condiții, în care unuia trebuie să i se acorde mai multă importanță decât celălalt (ele) și trebuie abordat / rezolvat mai întâi înainte de a trece la următorul (ele). Prin urmare, în contextul defectelor, prioritatea unui defect ar indica urgența cu care ar trebui să fie remediată.
Severitatea prin definiția engleză este utilizată pentru a descrie gravitatea unui eveniment nedorit. Prin urmare, când vine vorba de erori, severitatea unei erori ar indica efectul pe care îl are asupra sistemului în ceea ce privește impactul său.
Cine le definește?
QA clasifică defectul în funcție de severitatea corespunzătoare pe baza complexității și criticității defectelor.
Orice părți interesate din afaceri, inclusiv managerii de proiect, analiștii de afaceri, proprietarul produsului, definesc prioritatea defectelor.
Figura de mai jos descrie rolul care deține și clasifică criticitatea și severitatea defectelor.
Cum să alegeți aceste niveluri?
După cum am discutat deja, parametrul de severitate este evaluat de tester, în timp ce parametrul de prioritate este evaluat în principal de către Managerul de produs sau, în principiu, de echipa de triaj. Chiar dacă acesta este cazul, severitatea unui defect este cu siguranță unul dintre factorii de guvernare și influență pentru stabilirea priorității defectului. Prin urmare, este important ca tester să selectați severitatea potrivită pentru a evita confuzia cu echipele de dezvoltare.
Diferența dintre severitate și prioritate
Prioritatea este asociată cu programarea, iar „severitatea” este asociată cu standardele.
„Prioritate” înseamnă că se acordă ceva sau merită o atenție prealabilă; prioritate stabilită prin ordin de importanță (sau urgență).
„Severitatea” este starea sau calitatea de a fi sever; severă implică aderarea la standarde riguroase sau principii înalte și sugerează adesea duritate; sever este marcat de sau necesită respectarea strictă a standardelor riguroase sau a principiilor înalte, De exemplu, un cod sever de comportament.
Cuvintele prioritate și severitate apar în urmărirea erorilor.
Este disponibilă o varietate de instrumente software comerciale de urmărire / gestionare a problemelor. Aceste instrumente, cu intrarea detaliată a inginerilor de testare a software-ului, oferă echipei informații complete, astfel încât dezvoltatorii să poată înțelege eroarea, să-și facă o idee despre „Severitatea” sa, să o reproducă și să o remedieze.
Remediile se bazează pe proiectul „Priorități” și „Severitatea” erorilor.
„Severitatea” unei probleme este definită în conformitate cu evaluarea riscurilor clientului și înregistrată în instrumentul de urmărire selectat.
Software-ul buggy poate afecta „grav” programele, care, la rândul lor, pot duce la o reevaluare și renegociere a „priorităților”.
Ce este prioritatea?
Prioritatea, așa cum sugerează și numele, este despre prioritizarea unui defect pe baza nevoilor de afaceri și a severității defectului. Prioritatea înseamnă importanța sau urgența remedierii unui defect.
În timp ce deschide un defect, testerul atribuie, în general, prioritatea inițial pe măsură ce vizualizează produsul din perspectiva utilizatorului final. În conformitate cu acestea, există diferite niveluri:
În linii mari, Prioritatea defectelor poate fi clasificată după cum urmează:
Prioritatea nr. 1) Imediat / critic (P1)
Acest lucru trebuie remediat imediat în 24 de ore. Acest lucru se întâmplă în general în cazurile în care o funcționalitate întreagă este blocată și nu poate fi efectuată nicio testare ca urmare a acestui fapt. Sau, în anumite alte cazuri, dacă există scurgeri semnificative de memorie, atunci în general defectul este clasificat ca prioritate -1, ceea ce înseamnă că programul / caracteristica este inutilizabil în starea curentă.
Orice defect care necesită atenție imediată care afectează procesul de testare va fi clasificat în categoria imediată
Toate Severitate critică defectele se încadrează în această categorie (cu excepția cazului în care acestea sunt prioritizate de către companii / părțile interesate)
Prioritatea 2) ridicat (P2)
Odată ce defectele critice au fost remediate, un defect care are această prioritate este următorul candidat care trebuie remediat pentru ca orice activitate de testare să corespundă criteriilor de „ieșire”. În mod normal, atunci când o caracteristică nu este utilizabilă așa cum ar trebui să fie, din cauza unui defect al programului, sau a codului nou care trebuie scris sau uneori chiar și pentru că o problemă de mediu trebuie tratată prin cod, un defect se poate califica pentru o prioritate 2 .
Acesta este defectul sau problema care ar trebui rezolvată înainte de lansarea versiunii. Aceste defecte ar trebui rezolvate odată cu rezolvarea problemelor critice.
Toate Major severitate defectele se încadrează în această categorie.
companii implicate în internetul lucrurilor
Prioritatea nr. 3) Mediu (P3)
Un defect cu această prioritate trebuie să fie rezolvat pentru a fi remediat deoarece ar putea rezolva și probleme de funcționalitate care nu sunt conform așteptărilor. Uneori, chiar și erorile cosmetice, cum ar fi așteptarea unui mesaj de eroare corect în timpul eșecului, ar putea fi un defect de prioritate 3.
Acest defect ar trebui rezolvat după ce toate erorile grave sunt remediate.
Odată ce bugurile critice și cele cu prioritate ridicată sunt terminate, putem alege bug-urile cu prioritate medie.
Toate Minor severitate defectele se încadrează în această categorie.
Prioritatea # 4) Scăzută (P4)
Un defect cu prioritate redusă indică faptul că există cu siguranță o problemă, dar nu trebuie să fie remediată pentru a corespunde criteriilor de „ieșire”. Cu toate acestea, acest lucru trebuie remediat înainte ca AG să se termine. De obicei, unele erori de tastare sau chiar erori cosmetice, așa cum am discutat anterior, ar putea fi clasificate aici.
Uneori, defectele cu prioritate scăzută sunt, de asemenea, deschise pentru a sugera unele îmbunătățiri în designul existent sau o cerere de a implementa o caracteristică mică pentru a îmbunătăți experiența utilizatorului.
Acest defect poate fi rezolvat în viitor și nu are nevoie de nici o atenție imediată și Severitate scăzută defectele se încadrează în această categorie.
După cum sa discutat deja, prioritatea determină cât de rapid trebuie să fie timpul de răspuns la defecte. Dacă există mai multe defecte, prioritatea decide ce defect trebuie reparat și verificat imediat, comparativ cu defectul care poate fi remediat puțin mai târziu.
Ce este severitatea?
Severitatea definește măsura în care un anumit defect ar putea avea un impact asupra aplicației sau sistemului.
Severitatea este un parametru pentru a indica implicația defectului asupra sistemului - cât de critic este defectul și care este impactul defectului asupra funcționalității întregului sistem? Severitatea este un parametru stabilit de tester în timp ce acesta deschide un defect și controlează în principal testerul. Din nou, diferite organizații au instrumente diferite de utilizat pentru defecte, dar la nivel generic acestea sunt următoarele niveluri de severitate:
De exemplu, Luați în considerare următoarele scenarii
- Dacă utilizatorul încearcă să facă cumpărături online și aplicația nu se încarcă sau apare mesajul serverului indisponibil.
- Utilizatorul efectuează adăugarea unui articol în coș, numărul de cantități adăugate este incorect / produsul greșit se adaugă.
- Utilizatorul efectuează plata și, după efectuarea plății, comanda rămâne în coș, așa cum este confirmat în schimb.
- Sistemul acceptă comanda, dar în cele din urmă anulează comanda după o jumătate de oră din cauza oricăror probleme.
- Sistemul acceptă „Adăugați în coș” doar cu dublu clic, în loc de un singur clic.
- Butonul Adaugă în coș este scris ca Adăugare în coș.
Care ar fi experiența utilizatorului, dacă s-ar putea întâmpla oricare dintre scenariile de mai sus?
În general, defectele pot fi clasificate după cum urmează:
# 1) Critic (S1)
Un defect care împiedică sau blochează complet testarea produsului / caracteristicii este un defect critic. Un exemplu ar fi în cazul testării UI în care, după ce treceți printr-un vrăjitor, UI se blochează într-un singur panou sau nu merge mai departe pentru a declanșa funcția. Sau, în alte cazuri, când caracteristica dezvoltată însăși lipsește din compilare.
Din orice motiv, dacă aplicația se blochează sau devine inutilizabilă / nu mai poate continua, defectul ar putea fi clasificat la severitate critică.
Orice defecțiuni catastrofale ale sistemului ar putea duce utilizatorul la neutilizarea aplicațiilor ar putea fi clasificate în severitatea critică
De exemplu, În furnizorul de servicii de e-mail, cum ar fi Yahoo sau Gmail, după ce ați introdus numele de utilizator și parola corecte, în loc să vă conectați, sistemul se blochează sau aruncă mesajul de eroare, acest defect este clasificat ca fiind critic deoarece acest defect face ca întreaga aplicație să fie inutilizabilă.
Scenariul de la punctul 1 discutat mai sus ar putea fi clasificat ca Defect critic, deoarece aplicația online devine complet inutilizabilă.
# 2) Major (S2)
Orice caracteristică majoră implementată care nu își îndeplinește cerințele / cazurile de utilizare și se comportă diferit decât se aștepta, poate fi clasificată în severitate majoră.
Un defect major apare atunci când funcționalitatea funcționează brusc departe de așteptări sau nu face ceea ce ar trebui să facă. Un exemplu ar putea fi: Spuneți că un VLAN trebuie să fie implementat pe comutator și că utilizați un șablon UI care declanșează această funcție. Când acest șablon pentru configurarea VLAN eșuează pe comutator, acesta este clasificat ca un dezavantaj sever al funcționalității.
De exemplu, În furnizorul de servicii de e-mail, cum ar fi Yahoo sau Gmail, când nu aveți voie să adăugați mai mulți destinatari în secțiunea CC, acest defect este clasificat ca defect major, deoarece funcționalitatea majoră a aplicației nu funcționează corect.
Ceea ce este de așteptat comportamentul secțiunii CC în e-mail, ar trebui să permită utilizatorului să adauge mai mulți utilizatori. Deci, atunci când funcționalitatea majoră a aplicației nu funcționează corect sau când se comportă diferit decât se aștepta, este un defect major.
Scenariile de la punctele 2 și 3 discutate mai sus ar putea fi clasificate ca Defecte majore, deoarece ordinea se așteaptă să treacă lin la următoarea fază a ciclului de viață al ordinii, dar în realitate, comportamentul variază.
Orice defect care ar putea duce la persistența incorectă a datelor, probleme de date sau comportamente greșite ale aplicației ar putea fi clasificate în general în severitatea majoră.
# 3) Minor / moderat (S3)
Orice caracteristică implementată care nu își îndeplinește cerințele / cazurile de utilizare și se comportă diferit decât se aștepta, dar impactul este neglijabil într-o oarecare măsură sau nu are un impact major asupra aplicației, poate fi clasificat în severitate minoră.
Un defect moderat apare atunci când produsul sau aplicația nu îndeplinește anumite criterii sau prezintă încă un comportament nenatural, cu toate acestea, funcționalitatea în ansamblu nu este afectată. De exemplu, în șablonul VLAN implementat mai sus, un defect moderat sau normal ar apărea atunci când șablonul este implementat cu succes pe comutator, cu toate acestea, nu există nicio indicație trimisă utilizatorului.
De exemplu, În furnizorul de servicii de e-mail, cum ar fi Yahoo sau Gmail, există opțiunea numită „Termeni și condiții” și în acea opțiune, vor exista mai multe linkuri cu privire la termenii și condițiile site-ului web, când unul dintre linkurile multiple nu funcționează bine, este numit severitate minoră, deoarece afectează doar funcționalitatea minoră a aplicației și nu are un impact mare asupra utilizabilității aplicației.
Scenariul de la punctul 5 discutat mai sus ar putea fi clasificat ca Minor Defect, deoarece nu există pierderi sau eșecuri de date în ordinea fluxului sistemului, ci un ușor inconvenient când vine vorba de experiența utilizatorului.
Aceste tipuri de defecte duc la pierderea minimă a funcționalității sau a experienței utilizatorului.
# 4) Scăzut (S4)
Orice defecte cosmetice, inclusiv greșeli de ortografie sau probleme de aliniere sau carcasa fontului, pot fi clasificate la Severitate scăzută.
O eroare minoră de severitate scăzută apare atunci când nu există aproape niciun impact asupra funcționalității, dar este totuși un defect valid care ar trebui corectat. Exemple în acest sens ar putea include greșeli de ortografie în mesajele de eroare tipărite utilizatorilor sau defecte pentru a îmbunătăți aspectul unei caracteristici.
De exemplu, În furnizorul de servicii de e-mail, cum ar fi Yahoo sau Gmail, ați fi observat „pagina de licență”, dacă există greșeli de ortografie sau nealiniere în pagină, acest defect este clasificat ca scăzut.
Scenariul de la punctul 6 discutat mai sus ar putea fi clasificat ca Defect scăzut, deoarece butonul Adăugare este afișat într-o carcasă greșită. Acest tip de defect nu va avea niciun impact asupra comportamentului sistemului sau prezentării datelor sau pierderii datelor sau fluxului de date sau chiar experienței utilizatorului, dar va fi foarte cosmetic.
Pentru a rezuma, următoarea figură descrie clasificarea generală a defectelor bazată pe severitate și prioritate:
Exemple
După cum sa menționat deja, întrucât diferite organizații folosesc diferite tipuri de instrumente pentru urmărirea defectelor și procesele aferente - devine un sistem de urmărire comun între diferitele niveluri de management și personalul tehnic.
Deoarece severitatea defectului se află mai mult în domeniul funcționalității, inginerul de testare stabilește severitatea defectului. Uneori, dezvoltatorii iau parte la influențarea severității defectului, dar în cea mai mare parte depinde de tester, deoarece evaluează cât de mult o anumită caracteristică poate afecta funcționarea generală.
Pe de altă parte, când vine vorba de stabilirea priorității defectului, deși inițial, inițiatorul defectului stabilește prioritatea, acesta este de fapt definit de managerul de produs, deoarece are o imagine de ansamblu asupra produsului și cât de repede trebuie să fie abordat un anumit defect. . Un tester nu este o persoană ideală pentru a seta prioritatea defectului.
Oricât de șocant ar părea acest lucru, există două exemple distincte de ce:
Exemplul nr. 1) Luați în considerare faptul că există o situație în care utilizatorul găsește o greșeală în denumirea produsului în sine sau o problemă cu documentația UI. Un tester ar deschide în mod normal un defect minor / cosmetic și poate fi foarte simplu de remediat, dar când vine vorba de aspectul și simțul produsului / experiența utilizatorului, ar putea provoca un impact grav.
Exemplul nr. 2) Ar putea exista anumite condiții în care apare un anumit defect, care poate fi o posibilitate extrem de rară sau nicio posibilitate de a afecta în mediul clientului. Chiar dacă din punct de vedere funcțional, acest lucru poate părea un defect cu prioritate ridicată pentru un tester, având în vedere raritatea sa de apariție și costul ridicat de remediere - acesta ar fi clasificat ca defect cu prioritate redusă.
Prin urmare, efectiv, prioritatea defectului este stabilită, în general, de managerul de produs într-o întâlnire cu „defect triage”.
Nivele diferite
Prioritatea și severitatea au unele clasificări între ele care ajută la determinarea modului în care trebuie tratat defectul. O mulțime de organizații diferite au diferite instrumente de înregistrare a defectelor , astfel încât nivelurile pot varia.
Să aruncăm o privire la diferitele niveluri atât pentru Prioritate, cât și pentru Severitate.
- Prioritate mare, severitate mare
- Prioritate mare, severitate scăzută
- Severitate mare, prioritate scăzută
- Severitate scăzută, prioritate scăzută
Următoarea figură descrie clasificarea categoriilor într-un singur fragment.
# 1) Severitate ridicată și prioritate ridicată
Orice eșec critic sau major al cazurilor de afaceri este promovat automat la această categorie.
Orice defecte din cauza cărora testarea nu poate continua cu orice preț sau cauzează o defecțiune gravă a sistemului în această categorie. De exemplu, făcând clic pe un anumit buton nu se încarcă caracteristica în sine. Sau efectuarea unei anumite funcții reduce serverul în mod consecvent și provoacă pierderi de date. Liniile roșii din figura de mai sus indică aceste tipuri de defecte.
De exemplu,
Sistemul se blochează după ce ați efectuat plata sau când nu puteți adăuga articolele în coș, acest defect este marcat ca defect de severitate ridicată și prioritate ridicată.
Alt exemplu ar fi o caracteristică a monedei de vending ATM în care după introducerea numelui de utilizator și a parolei corecte, aparatul nu distribuie bani, ci deduce transferul din contul dvs.
# 2) Prioritate ridicată și severitate scăzută
Orice defecte minore de gravitate care ar putea avea un impact direct asupra experienței utilizatorului sunt promovate automat în această categorie.
Defectele care trebuie remediate dar care nu afectează aplicația intră în această categorie.
De exemplu, se așteaptă ca funcția să afișeze o anumită eroare utilizatorului în ceea ce privește codul său de returnare. În acest caz, funcțional, codul va genera o eroare, dar mesajul va trebui să fie mai relevant pentru codul de returnare generat. Liniile albastre din figură indică aceste tipuri de defecte.
De exemplu,
Sigla companiei din prima pagină este greșită, se consideră că este Prioritate ridicată și severitate redusă defect .
Exemplul 1) În site-ul de cumpărături online, când sigla FrontPage este scris greșit, de exemplu, în loc de Flipkart, este scris ca Flipkart.
Exemplul 2) În sigla băncii, în loc de ICICI, este scrisă ca ICCCI.
În ceea ce privește funcționalitatea, nu afectează nimic, așa că putem marca drept Severitate scăzută, dar are un impact asupra experienței utilizatorului. Acest tip de defect trebuie rezolvat cu prioritate ridicată, chiar dacă au un impact foarte mic asupra aplicației.
# 3) Severitate ridicată și prioritate redusă
Orice defect care nu îndeplinește funcțional cerințele sau care are implicații funcționale asupra sistemului, dar care este respins de banii din spate de către părțile interesate atunci când vine vorba de criticitatea afacerii, este promovat automat la această categorie.
Defecte care trebuie remediate, dar nu imediat. Acest lucru poate apărea în mod specific în timpul testării ad-hoc. Înseamnă că funcționalitatea este afectată într-o mare măsură, dar este observată numai atunci când se utilizează anumiți parametri de intrare neobișnuiți.
De exemplu, o anumită funcționalitate poate fi utilizată numai pe o versiune ulterioară a firmware-ului, deci pentru a verifica acest lucru - testerul își degradează de fapt sistemul și efectuează testul și observă o problemă serioasă de funcționalitate care este validă. Într-un astfel de caz, defectele vor fi clasificate în această categorie notate cu linii roz, deoarece, în mod normal, utilizatorii finali vor avea o versiune superioară a firmware-ului.
De exemplu,
Într-un site de rețele sociale, dacă o versiune beta a unei noi caracteristici este lansată, cu foarte mulți utilizatori activi care folosesc această facilitate începând de astăzi. Orice defect constatat pe această caracteristică poate fi clasificat ca o prioritate scăzută, deoarece caracteristica ocupă locul din spate din cauza clasificării companiei ca neimportantă.
Deși această caracteristică are un defect funcțional, deoarece nu are un impact direct asupra clienților finali, un partener interesat poate clasifica defectul sub prioritate redusă, deși are un impact funcțional sever asupra aplicației.
Aceasta este o eroare de severitate ridicată, dar poate fi prioritizată la prioritate scăzută, deoarece poate fi remediată cu următoarea versiune ca cerere de modificare. De asemenea, părțile interesate din afaceri acordă prioritate acestei caracteristici ca fiind o caracteristică utilizată rar și nu au impact asupra altor caracteristici care au un impact direct asupra experienței utilizatorului. Acest tip de defect poate fi clasificat la Severitate mare, dar prioritate redusă categorie.
# 4) Severitate scăzută și prioritate scăzută
Orice greșeli de ortografie / carcasa fontului / nealiniere în paragraful 3rdsau 4apagina aplicației și nu în pagina principală sau în prima pagină / titlu.
Aceste defecte sunt clasificate în liniile verzi, așa cum se arată în figură și apar atunci când nu există un impact funcțional, dar încă nu îndeplinesc standardele într-o măsură mică. În general, erorile cosmetice sau dimensiunile unei celule dintr-un tabel din interfața de utilizare sunt clasificate aici.
Servicii web întrebări de interviu .net
De exemplu,
Dacă politica de confidențialitate a site-ului web are o greșeală de ortografie, acest defect este setat ca Severitate scăzută și prioritate scăzută.
Instrucțiuni
Mai jos sunt anumite linii directoare pe care fiecare tester trebuie să încerce să le respecte:
- În primul rând, înțelegeți bine conceptele de prioritate și severitate. Evitați să le confundați una cu cealaltă și să le utilizați în mod interschimbabil. În conformitate cu aceasta, urmați instrucțiunile de severitate publicate de organizația / echipa dvs., astfel încât toată lumea să fie pe aceeași pagină.
- Alegeți întotdeauna nivelul de severitate pe baza tipului de problemă, deoarece acest lucru va afecta prioritatea acestuia. Câteva exemple sunt:
- Pentru o problemă esențială, cum ar fi că întregul sistem nu funcționează și nu se poate face nimic - această gravitate nu trebuie utilizată pentru a remedia defectele programului.
- Pentru o problemă majoră, cum ar fi în cazurile în care funcția nu funcționează așa cum era de așteptat - această severitate ar putea fi utilizată pentru a aborda noi funcții sau îmbunătățirea funcționării curente.
Amintiți-vă că alegerea nivelului corect de severitate va da, la rândul său, defectul, este prioritatea cuvenită.
- Ca tester - să înțeleagă modul în care o anumită funcționalitate, mai degrabă să se descurce în continuare - să înțeleagă modul în care un anumit scenariu sau caz de testare ar afecta utilizatorul final. Aceasta implică o mulțime de colaborare și interacțiune cu echipa de dezvoltare, analiști de afaceri, arhitecți, șef de test, șef de dezvoltare. În discuțiile dvs., trebuie să luați în considerare și timpul necesar pentru a remedia defectul pe baza complexității și a timpului pentru a verifica acest defect.
- In cele din urma , întotdeauna proprietarul produsului este cel care deține puterea de veto a eliberării, defectul ar trebui remediat. Cu toate acestea, întrucât sesiunile de triere a defectelor conțin membri variați pentru a-și prezenta perspectiva asupra defectului în funcție de caz, într-un moment în care dezvoltatorii și testerii sunt sincronizați, cu siguranță ajută la influențarea deciziei.
Concluzie
În timp ce defectele de deschidere sunt responsabilitatea testerului de a atribui severitatea corectă defectelor. Gravitatea incorectă și, prin urmare, maparea prioritară pot avea implicații foarte drastice asupra procesului STLC general și al produsului în ansamblu. În mai multe interviuri de angajare - există mai multe întrebări care sunt puse cu privire la prioritate și severitate pentru a vă asigura că, în calitate de tester, aveți aceste concepte impecabil de clare în minte.
De asemenea, am văzut exemple live despre cum să clasificăm defectul sub diferite găleți de severitate / prioritate. Până acum, mi-aș dori să aveți suficiente clarificări cu privire la clasificarea defectelor atât la pistoane de severitate / prioritate.
Sper că acest articol este un ghid complet pentru înțelegerea nivelului de prioritate și severitate a defectelor. Spuneți-ne gândurile / întrebările dvs. în comentariile de mai jos.
Lectură recomandată
- Ce este tehnica de testare bazată pe defecte?
- Ce este ciclul de viață al defectelor / erorilor în testarea software-ului? Tutorial privind ciclul de viață al defectelor
- Procesul de gestionare a defectelor: Cum să gestionați eficient un defect
- Cum să reproduceți un defect non-reproductibil și să vă meritați efortul de testare
- 7 Principiile testării software-ului: Clusterarea defectelor și principiul Pareto
- Metode și tehnici de prevenire a defectelor
- Diferența exactă între verificare și validare cu exemple
- 3 strategii pentru tratarea unui defect de blocare