Ce este Bug?
O eroare este consecința / rezultatul unei defecțiuni de codare.
Defect la testarea software-ului
Un defect în testarea software-ului este o variație sau o abatere a aplicației software de la cerințele utilizatorului final sau cerințele originale ale companiei. Un defect de software este o eroare de codificare care cauzează rezultate incorecte sau neașteptate de la un program software care nu îndeplinește cerințele reale. Testerii ar putea întâlni astfel de defecte în timpul executării cazurilor de testare.
Acești doi termeni au o linie foarte subțire de diferență, în industrie ambii sunt erori care trebuie remediate și, astfel, utilizate în mod interschimbabil de către unele dintre echipele de testare.
Când testerii execută cazurile de testare, ar putea întâlni astfel de rezultate ale testelor care sunt contradictorii cu rezultatele așteptate. Această variație a rezultatelor testelor este denumită defect de software. Aceste defecte sau variații sunt menționate prin nume diferite în diferite organizații, cum ar fi probleme, probleme, erori sau incidente.
În acest tutorial, veți învăța-
- Raport de eroare
- Procesul de gestionare a defectelor
- Descoperire
- Categorizare
- Rezoluţie
- Verificare
- Închidere
- Raportarea
- Valori importante privind defectele
Raport de erori în testarea software-ului
Un raport de erori în testarea software-ului este un document detaliat despre erorile găsite în aplicația software. Raportul de eroare conține fiecare detaliu despre erori precum descrierea, data la care a fost găsit eroarea, numele testerului care a găsit-o, numele dezvoltatorului care a remediat-o etc. Raportul de erori ajută la identificarea unor erori similare în viitor, astfel încât să poată fi evitată.
În timp ce raportați eroarea către dezvoltator, Raportul dvs. de erori ar trebui să conțină următoarele informații
- Defect_ID - Număr unic de identificare pentru defect.
- Descrierea defectului - Descrierea detaliată a defectului, inclusiv informații despre modulul în care a fost găsit defectul.
- Versiune - Versiunea aplicației în care a fost găsit defectul.
- Pași - Pași detaliați împreună cu capturi de ecran cu ajutorul cărora dezvoltatorul poate reproduce defectele.
- Data ridicată - Data când defectul este ridicat
- Referință - unde în tine Furnizați referință la documentele cum ar fi. cerințe, design, arhitectură sau poate chiar capturi de ecran ale erorii pentru a ajuta la înțelegerea defectului
- Detectat după - Numele / ID-ul testerului care a ridicat defectul
- Stare - Starea defectului, mai multe despre aceasta mai târziu
- Fixed by - Numele / ID-ul dezvoltatorului care l-a remediat
- Data închisă - Data la care defectul este închis
- Severitate care descrie impactul defectului asupra aplicației
- Prioritate legată de urgența de remediere a defectelor. Prioritatea de gravitate ar putea fi ridicată / medie / scăzută pe baza urgenței de impact la care ar trebui să se remedieze respectivul defect
Faceți clic aici dacă videoclipul nu este accesibil
Resurse
Descărcați un eșantion de șablon de raportare a defectelor
Luați în considerare următoarele ca un Manager de testare
Echipa dvs. a găsit erori în timpul testării proiectului Guru99 Banking.
După o săptămână dezvoltatorul răspunde -
În săptămâna viitoare testerul răspunde
Ca și în cazul de mai sus, dacă comunicarea defectului se face verbal, în curând lucrurile devin foarte complicate. Pentru a controla și a gestiona eficient bug-urile, aveți nevoie de un ciclu de viață defect.
Ce este procesul de gestionare a defectelor?
Gestionarea defectelor este un proces sistematic pentru identificarea și remedierea erorilor. Un ciclu de gestionare a defectelor conține următoarele etape 1) Descoperirea defectelor, 2) Categorizarea defectelor 3) Remediere a defectelor de către dezvoltatori 4) Verificarea de către testeri, 5) Închiderea defectelor 6) Rapoarte de defecte la sfârșitul proiectului
Acest subiect vă va ghida cu privire la modul de aplicare a procesului de gestionare a defectelor pe site-ul web al proiectului Guru99 Bank. Puteți urma pașii de mai jos pentru a gestiona defectele.
Descoperire
În faza de descoperire, echipele de proiect trebuie să descopere cât mai multe defecte posibil, înainte ca clientul final să le poată descoperi. Se spune că un defect este descoperit și schimbarea statutului este acceptată atunci când este recunoscută și acceptată de dezvoltatori
În scenariul de mai sus, testerii au descoperit 84 de defecte pe site-ul web Guru99.
Să aruncăm o privire la următorul scenariu; echipa dvs. de testare a descoperit câteva probleme pe site-ul web Guru99 Bank. Ei îi consideră defecte și au raportat echipei de dezvoltare, dar există un conflict -
În acest caz, în calitate de Manager de teste, ce veți face?
A) De acord cu echipa de testare că este un defect
B) Test Manager ia rolul de judecător pentru a decide dacă problema este sau nu defectă
C) De acord cu echipa de dezvoltare care nu este un defect Corect InCorrect
În acest caz, ar trebui să se aplice un proces de soluționare pentru a rezolva conflictul, vă asumați rolul de judecător pentru a decide dacă problema site-ului web este sau nu un defect.
Categorizare
Clasificarea defectelor îi ajută pe dezvoltatorii de software să-și acorde prioritate sarcinilor. Asta înseamnă că acest tip de prioritate îi ajută pe dezvoltatori să remedieze mai întâi acele defecte care sunt extrem de importante.
Defectele sunt de obicei clasificate de Managerul de teste -
Să facem un mic exercițiu după cum urmează Drag & Drop Prioritatea defectului de mai jos
- Critic
- Înalt
- Mediu
- Scăzut
| 1) Performanța site-ului este prea lentă |
|
| 2) Funcția de conectare a site-ului web nu funcționează corect |
|
| 3) GUI-ul site-ului nu se afișează corect pe dispozitivele mobile |
|
| 4) Site-ul nu și-a putut aminti sesiunea de conectare a utilizatorului |
|
| 5) Unele link-uri nu funcționează |
|
Iată răspunsurile recomandate
| Nu. | Descriere | Prioritate | Explicaţie |
|---|---|---|---|
| 1 | Performanța site-ului este prea lentă | Înalt | Eroarea de performanță poate provoca neplăceri imense utilizatorului. |
| 2 | Funcția de conectare a site-ului web nu funcționează corect | Critic | Conectarea este una dintre funcțiile principale ale site-ului bancar dacă această caracteristică nu funcționează, este vorba de erori grave |
| 3 | GUI-ul site-ului nu se afișează corect pe dispozitivele mobile | Mediu | Defectul afectează utilizatorul care folosește Smartphone pentru a vizualiza site-ul web. |
| 4 | Site-ul nu și-a putut aminti sesiunea de conectare a utilizatorului | Înalt | Aceasta este o problemă serioasă, deoarece utilizatorul se va putea autentifica, dar nu va mai putea efectua alte tranzacții |
| 5 | Unele link-uri nu funcționează | Scăzut | Aceasta este o soluție ușoară pentru băieții de dezvoltare, iar utilizatorul poate accesa site-ul fără aceste linkuri |
Rezolvarea defectelor
Rezolvarea defectelor în testarea software-ului este un proces pas cu pas de remediere a defectelor. Procesul de rezolvare a defectelor începe cu atribuirea defectelor dezvoltatorilor, apoi dezvoltatorii programează defectul pentru a fi remediat conform priorității, apoi defectele sunt remediate și în cele din urmă dezvoltatorii trimit un raport de rezoluție managerului de testare. Acest proces vă ajută să remediați și să urmăriți cu ușurință defectele.
Puteți urma următorii pași pentru a remedia defectul.
- Atribuire : atribuită unui dezvoltator sau altui tehnician pentru a remedia și a schimbat starea în Răspuns .
- Fixarea programului : partea dezvoltatorului se ocupă de această fază. Vor crea un program pentru remedierea acestor defecte, în funcție de prioritatea defectului.
- Remediați defectul : în timp ce echipa de dezvoltare remediază defectele, Managerul de testare urmărește procesul de remediere a defectelor în comparație cu programul de mai sus.
- Raportați rezoluția : obțineți un raport al rezoluției de la dezvoltatori atunci când defectele sunt remediate.
Verificare
După ce echipa de dezvoltare a remediat și raportat defectul, echipa de testare verifică dacă defectele sunt de fapt rezolvate.
De exemplu, în scenariul de mai sus, atunci când echipa de dezvoltare a raportat că a remediat deja 61 de defecte, echipa dvs. va testa din nou pentru a verifica dacă aceste defecte au fost efectiv remediate sau nu.
Închidere
Odată ce un defect a fost rezolvat și verificat, defectul este modificat de stare ca închis . Dacă nu, ați trimis o notificare către dezvoltare pentru a verifica din nou defectul.
Raportarea defectelor
Raportarea defectelor în testarea software-ului este un proces în care managerii de teste pregătesc și trimit raportul defectelor către echipa de management pentru feedback despre procesul de gestionare a defectelor și starea defectelor. Apoi, echipa de management verifică raportul de defecte și trimite feedback sau oferă asistență suplimentară, dacă este necesar. Raportarea defectelor ajută la o mai bună comunicare, urmărire și explicare în detaliu a defectelor.
Consiliul de administrație are dreptul să cunoască starea defectului. Ei trebuie să înțeleagă procesul de gestionare a defectelor pentru a vă sprijini în acest proiect. Prin urmare, trebuie să le raportați situația curentă a defectelor pentru a obține feedback de la ei.
Valori importante privind defectele
Înapoi scenariul de mai sus. Dezvoltatorii și echipele de testare analizează defectele raportate. Iată rezultatul acelei discuții
Cum se măsoară și se evaluează calitatea execuției testului?
Aceasta este o întrebare pe care fiecare manager de testare vrea să o cunoască. Există 2 parametri pe care îi puteți lua în considerare după cum urmează
În scenariul de mai sus, puteți calcula raportul de respingere a defecțiunii (DRR) este de 20/84 = 0,238 (23,8%).
Un alt exemplu, presupus că site-ul web Guru99 Bank are 64 de defecte în total , dar echipa dvs. de testare detectează doar 44 de defecte, adică au ratat 20 de defecte. Prin urmare, puteți calcula raportul de scurgere a defectelor (DLR) este de 20/64 = 0,312 (31,2%).
Concluzie, calitatea execuției testului este evaluată prin urmarea a doi parametri
Cu cât valoarea DRR și DLR este mai mică, cu atât este mai bună calitatea executării testului. Care este intervalul de raport care este acceptabil ? Acest interval ar putea fi definit și acceptat în baza țintei proiectului sau puteți consulta metricele proiectelor similare.
În acest proiect, valoarea recomandată a raportului acceptabil este de 5 ~ 10%. Înseamnă că calitatea execuției testului este scăzută. Ar trebui să găsiți măsuri contrare pentru a reduce aceste rapoarte, cum ar fi
- Îmbunătățiți abilitățile de testare ale membrilor.
- Petreceți mai mult timp pentru executarea testării, în special pentru revizuirea rezultatelor executării testului.