Procesul de management al defectelor în testarea software-ului

Ce este procesul de management al defectelor?

Managementul defectelor este un proces sistematic de identificare și remediere a erorilor. Un ciclu de gestionare a defectelor conține următoarele etape: 1) Descoperirea defectelor, 2) Categorizarea defectelor 3) Remedierea defectelor de către dezvoltatori 4) Verificarea de către testeri, 5) Închiderea defectelor 6) Rapoartele defectelor la sfârșitul proiectului

Acest subiect vă va ghida despre cum să aplicați procesul de gestionare a defectelor pe site-ul web al proiectului Guru99 Bank. Puteți urma pașii de mai jos pentru a gestiona defectele.

Procesul de management al defectelor

Pasul 1) Descoperire

În faza de descoperire, echipele de proiect trebuie să descopere ca multe defecte ca posibil, înainte ca clientul final să-l poată descoperi. Se spune că un defect este descoperit și se schimbă în stare admis atunci când este recunoscut și acceptat de dezvoltatori

În scenariul de mai sus, testerii au descoperit 84 de defecte pe site-ul Guru99.

Descoperire

Să aruncăm o privire la următorul scenariu; echipa dvs. de testare a descoperit unele probleme pe site-ul web Guru99 Bank. Ei le consideră defecte și raportate echipei de dezvoltare, dar există un conflict -

În acest caz, în calitate de Test Manager, ce vei face?

A) De acord cu echipa de testare că este un defect

B) Managerul de testare își asumă rolul de judecător pentru a decide dacă problema este defectă sau nu

C) De acord cu echipa de dezvoltare care nu este un defect

Corect
Incorect

În acest caz, ar trebui aplicat un proces de soluționare pentru a rezolva conflictul, tu asumi rolul de judecător pentru a decide dacă problema site-ului este un defect sau nu.

Pasul 2) Categorizare

Categorizarea defectelor ajută dezvoltatorii de software să-și prioritizeze sarcinile. Asta înseamnă că acest tip de prioritate ajută dezvoltatorii să remedieze mai întâi acele defecte care sunt extrem de cruciale.

Categorizarea

Defectele sunt de obicei clasificate de managerul de testare -

Să facem un mic exercițiu după cum urmează

Trageți și plasați prioritatea defectelor de mai jos
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 web nu se afișează corect Mobil Dispozitive
4) Site-ul web 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

Bug-ul de performanță poate cauza neplăceri uriașe utilizatorului.

2

Funcția de autentificare 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 web nu se afișează corect pe dispozitivele mobile

Mediu

Defectul afectează utilizatorul care folosește Smartphone pentru a vizualiza site-ul.

4

Site-ul web 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 putea efectua alte tranzacții

5

Unele link-uri nu funcționează

Scăzut

Aceasta este o soluție ușoară pentru cei din dezvoltare, iar utilizatorul poate accesa site-ul fără aceste link-uri

Pasul 3) 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ă ca defectul să fie remediat conform priorității, apoi defectele sunt remediate și, în final, dezvoltatorii trimit un raport de rezoluție managerului de testare. Acest proces ajută la remedierea și urmărirea cu ușurință a defectelor.

Puteți urma următorii pași pentru a remedia defectul.

Rezolvarea defectelor

  • Cesiune: a fost atribuit unui dezvoltator sau altui tehnician pentru a remedia și a schimbat starea în Răspunsul.
  • Fixarea programului: Partea dezvoltatorului preia conducerea în această fază. Ei vor crea un program pentru a remedia aceste defecte, în funcție de prioritatea defectelor.
  • 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.

Pasul 4) Verificare

După echipa de dezvoltare fixată si raportate defectul, echipa de testare verifică că defectele sunt efectiv rezolvate.

De exemplu, în scenariul de mai sus, când echipa de dezvoltare a raportat că a remediat deja 61 de defecte, echipa dvs. ar testa din nou pentru a verifica că aceste defecte au fost de fapt remediate sau nu.

Pasul 5) Închidere

Odată ce un defect a fost rezolvat și verificat, defectul se schimbă ca închis. Dacă nu, ați trimis o notificare către dezvoltare pentru a verifica din nou defectul.

Pasul 6) Raportarea defecțiunilor

Raportarea defecțiunilor în testarea software-ului este un proces în care managerii de testare pregătesc și trimit raportul defectelor echipei de management pentru feedback cu privire la procesul de management al defectelor și starea defectelor. Apoi, echipa de management verifică raportul de defecțiune și trimite feedback sau oferă asistență suplimentară, dacă este necesar. Raportarea defecțiunilor ajută la o mai bună comunicare, urmărire și explicare a defectelor în detaliu.

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 actuală a defectelor pentru a obține feedback de la ei.

De ce aveți nevoie de un proces de management al defectelor?

Echipa ta a găsit erori în timpul testării proiectului Guru99 Banking.

Procesul de management al defectelor

După o săptămână, dezvoltatorul răspunde -

Procesul de management al defectelor

În săptămâna viitoare, testerul răspunde

Procesul de management al defectelor

Ca și în cazul de mai sus, dacă comunicarea defectului se face verbal, în curând lucrurile devin foarte complicate. Pentru a controla și gestiona eficient erorile, aveți nevoie de un ciclu de viață defect.

Valori importante ale defectelor

Înapoi la scenariul de mai sus. Dezvoltatorii și echipele de testare au revizuit defectele raportate. Iată rezultatul acelei discuții

Valori importante ale defectelor

Cum se măsoară și se evaluează calitatea execuției testului?

Aceasta este o întrebare pe care fiecare Manager de testare vrea sa stie. Există 2 parametri pe care îi puteți considera după cum urmează

Valori importante ale defectelor

În scenariul de mai sus, puteți calcula rata de respingere a defecțiunii (DRR) este 20/84 = 0.238 (23.8 %).

Un alt exemplu, se presupune că site-ul web Guru99 Bank are total 64 defecte, dar echipa dvs. de testare doar detectează 44 defecte, adică au ratat 20 defecte. Prin urmare, puteți calcula raportul de scurgere a defectelor (DLR) este 20/64 = 0.312 (31.2%).

Concluzie, calitatea executării testului este evaluată prin următorii doi parametri

Valori importante ale defectelor

Cu cât valoarea DRR și DLR este mai mică, cu atât este mai bună calitatea executării testului. Care este intervalul de raporturi care este acceptabil? Acest interval ar putea fi definit și acceptat de bază în ținta proiectului sau puteți face referire la valorile unor proiecte similare.

În acest proiect, valoarea recomandată a raportului acceptabil este 5 ~ 10%. Înseamnă că calitatea executării testului este scăzută. Ar trebui să găsiți contramăsuri pentru a reduce aceste rapoarte, cum ar fi

  • Îmbunătăți abilitățile de testare ale membrului.
  • Petrece mai mult timp pentru execuția testării, în special pentru revizuirea rezultatelor execuției testelor.

Întrebări frecvente

Un bug este consecința/rezultatul unei erori de codare.

A Defect în testarea software-ului este o variație sau abatere a aplicației software de la cerințele utilizatorului final sau de la cerințele comerciale originale. Un defect software este o eroare de codare care provoacă rezultate incorecte sau neașteptate de la un program software care nu îndeplinește cerințele reale. Testerii pot î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 defecte care trebuie remediate și, astfel, utilizate în mod interschimbabil de unii dintre Testarea echipe.

Când testerii execută cazurile de testare, ei pot întâlni astfel de rezultate ale testelor care sunt în contradicție cu rezultatele așteptate. Această variație a rezultatelor testelor este denumită defect software. Aceste defecte sau variații sunt menționate prin nume diferite în diferite organizații, cum ar fi probleme, probleme, erori sau incidente.

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 l-a găsit, numele dezvoltatorului care l-a remediat etc. Raportul de erori ajută la identificarea erorilor similare în viitor, astfel încât să poată fi evitate.

  • ID_defect – Număr unic de identificare al defectului.
  • Defect Description – 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 care dezvoltatorul poate reproduce defectele.
  • Data ridicării – Data la care se ridică defectul
  • Referinţă- unde în dvs. Furnizați referință la documente precum . cerințe, design, arhitectură sau poate chiar capturi de ecran ale erorii pentru a ajuta la înțelegerea defectului
  • Detectat de – Numele/ID-ul testatorului care a ridicat defectul
  • Stare - Starea defectului, mai multe despre aceasta mai târziu
  • Fixat de – Numele/ID-ul dezvoltatorului care l-a remediat
  • Data închiderii – Data la care defectul este închis
  • Severitate care descrie impactul defectului asupra aplicației
  • Prioritate care este legat de urgenta remedierii defectelor. Prioritatea de severitate ar putea fi ridicată/medie/scăzută în funcție de urgența impactului la care defectul ar trebui remediat, respectiv

Clic aici dacă videoclipul nu este accesibil

Resurse:

Descărcați un exemplu de șablon de raportare a defecțiunilor