Procesul de management al defectelor în testarea software-ului
Thomas Hamilton
⚡ Rezumat inteligent
Procesul de gestionare a defectelor în testarea software este un cadru structurat pentru identificarea, clasificarea, rezolvarea, verificarea, închiderea și raportarea erorilor. Acesta permite o comunicare previzibilă între testeri și dezvoltatori, îmbunătățește calitatea lansărilor și reduce erorile la nivel de producție pe parcursul ciclului de viață al proiectului.
Ce este procesul de management al defectelor?
Procesul de management al defectelor este o abordare sistematică utilizată în testarea software pentru a identifica, clasifica, remedia și verifica erorile înainte de lansarea software-ului. Ciclul de viață include șase etape principale: 1) Descoperirea defectului, 2) Clasificare, 3) Rezolvare de către dezvoltatori, 4) Verificare de către testeri, 5) Închidere și 6) Raportarea defectelor la sfârșitul proiectului.
Acest articol explică modul de aplicare a Procesului de Gestionare a Defectelor utilizând GuruExemplu de site web 99 Bank, astfel încât testerii începători și intermediari să poată înțelege fiecare pas într-un context real al unui proiect.
De ce aveți nevoie de un proces de management al defectelor?
Imaginează-ți că echipa ta a găsit mai multe erori în timpul testării... GuruProiectul 99 Banking. Fără un proces structurat, comunicarea dintre testeri și dezvoltatori se face verbal sau prin mesaje dispersate.
O săptămână mai târziu, dezvoltatorul răspunde cu o altă înțelegere a problemei.
Săptămâna următoare, testerul răspunde din nou, creând și mai multă confuzie.
Când comunicarea defectelor este gestionată verbal sau informal, lucrurile se complică foarte repede. Pentru a controla și gestiona eficient erorile, aveți nevoie de un ciclu de viață definit al defectelor care să standardizeze modul în care echipele raportează, track și probleme apropiate.
Pasul 1) Descoperire
În Descoperire În faza următoare, echipa de proiect trebuie să identifice cât mai multe defecte posibil înainte ca clientul final să le întâlnească. Un defect este considerat „descoperit” odată ce este recunoscut și acceptat de echipa de dezvoltare, moment în care statutul său se schimbă în Admis.
În scenariul exemplu, testerii au descoperit 84 de defecte pe GuruSite-ul web al 99 Bank.
Totuși, testerii și dezvoltatorii nu sunt întotdeauna de acord. Uitați-vă la următorul caz, în care echipa de testare identifică probleme pe GuruSite-ul 99 Bank și le raportează, dar echipa de dezvoltare contestă dacă sunt defecte:
Într-un astfel de caz, în calitate de Manager de Testare, ce ar trebui să faci?
A) Fiți de acord cu echipa de testare că este un defect.
B) Asumați rolul de judecător și decideți dacă problema este un defect sau nu.
C) Fiți de acord cu echipa de dezvoltare că nu este un defect.
Abordarea corectă este opțiunea B. Ar trebui aplicat un proces de rezoluție pentru a rezolva conflictul, iar Managerul de Testare ar trebui să evalueze problema imparțial înainte de a decide dacă aceasta se califică drept defect.
Pasul 2) Categorizare
Clasificarea defectelor îi ajută pe dezvoltatori să își prioritizeze munca, astfel încât problemele cele mai critice pentru afacere să fie remediate primele. Clasificarea este de obicei efectuată de către Managerul de Testare și se bazează pe gravitate și impactul asupra afacerii.
Defectele sunt de obicei grupate în patru niveluri de prioritate: Critic, Ridicat, Mediu și ScăzutÎncercați să atribuiți prioritatea corectă fiecăruia dintre următoarele defecte:
- Performanța site-ului web este prea lentă.
- Funcția de autentificare a site-ului web nu funcționează corect.
- Interfața grafică a site-ului web nu se afișează corect pe mobil dispozitive.
- Site-ul web nu își poate aminti sesiunea de conectare a utilizatorului.
- Unele linkuri nu funcționează.
Iată răspunsurile recomandate:
| Nu. | Descriere | Prioritate | Explicație |
|---|---|---|---|
| 1 | Performanța site-ului este prea lentă | Înalt | Problemele de performanță cauzează inconveniente majore utilizatorilor finali. |
| 2 | Funcția de autentificare nu funcționează corect | Critic | Conectarea este o funcție de bază a unui site web bancar. Dacă eșuează, întreaga experiență a utilizatorului este blocată. |
| 3 | Interfața grafică nu se afișează corect pe dispozitivele mobile | Mediu | Defectul afectează utilizatorii care vizualizează site-ul web pe smartphone-uri. |
| 4 | Site-ul web nu își poate aminti sesiunea de conectare a utilizatorului | Înalt | Utilizatorii se pot conecta, dar nu pot efectua alte tranzacții. |
| 5 | Unele linkuri nu funcționează | Scăzut | O soluție ușoară pentru dezvoltatori, iar utilizatorii pot accesa în continuare restul site-ului. |
Pasul 3) Rezolvarea defectelor
Rezolvarea defectelor În testarea software, remedierea defectelor este un proces pas cu pas. Procesul de rezolvare începe cu atribuirea defectelor dezvoltatorilor, care apoi programează remedierile în funcție de prioritate, implementează corecțiile și, în final, trimit un raport de rezolvare către Managerul de Testare. Această secvență face ca defectele să fie corectate pas cu pas. tracrege transparent și responsabil.
Puteți urma acești pași pentru a remedia un defect:
- Misiune: Defectul este atribuit unui dezvoltator sau tehnician, iar starea sa se schimbă în Răspunsul.
- Fixarea programului: Echipa de dezvoltare preia controlul și creează un program de remediere bazat pe prioritatea defectelor.
- Remediați defectul: În timp ce dezvoltatorii remediază defectele, Managerul de Testare tracprogresul ks față de programul planificat.
- Raportați rezoluția: Dezvoltatorii trimit un raport care confirmă ce defecte au fost remediate și cum au fost remediate.
Pasul 4) Verificare
După ce echipa de dezvoltare a fixată și raportate defectele, echipa de testare verifică că problemele au fost rezolvate.
De exemplu, când echipa de dezvoltare raportează că 61 de defecte au fost remediate, echipa de testare le testează din nou pe fiecare în parte pentru a confirma dacă remedierile funcționează corect în aceleași condiții care au cauzat eroarea inițială.
Pasul 5) Închidere
Odată ce un defect a fost remediat și verificat, starea sa se schimbă în Operații ÎnchiseDacă defectul nu este remediat corect în timpul verificării, trebuie să trimiteți o notificare echipei de dezvoltare pentru a-l investiga din nou. Închiderea indică faptul că defectul nu mai este activ în sistem.
Pasul 6) Raportarea defecțiunilor
Raportarea defecțiunilor În testarea software, raportarea defectelor este procesul prin care managerii de testare pregătesc și partajează starea defectelor cu echipa de management. Echipa de management analizează raportul și oferă feedback sau asistență suplimentară, dacă este necesar. Raportarea defectelor îmbunătățește comunicarea, tracrege și vizibilitate în jurul defectelor.
Conducerea are dreptul să înțeleagă starea defectelor pentru a sprijini proiectul eficient. Prin urmare, trebuie să raportați periodic situația actuală a defectelor, astfel încât să poată oferi îndrumări și resurse.
Valori importante ale defectelor
Revenind la scenariul inițial, echipele de dezvoltatori și de testare analizează defectele împreună. Rezultatele combinate sunt prezentate mai jos.
Cum poți măsura și evalua calitatea execuției testelor?
Aceasta este o întrebare critică în fiecare Manager de testare vrea să răspundă. De obicei, se folosesc doi parametri cheie:
În scenariul de mai sus, Raportul de respingere a defectelor (DRR) se calculează ca 20/84 = 0.238 (23.8%).
Ca un alt exemplu, să presupunem că GuruSite-ul web al 99 Bank are un total de 64 defecte, dar echipa de testare detectează doar 44 — sens 20 defectele au fost trecute cu vederea. Raportul de scurgere a defectelor (DLR) se calculează ca 20/64 = 0.312 (31.2%).
În concluzie, calitatea execuției testelor este evaluată folosind următorii doi parametri:
Cu cât valorile DRR și DLR sunt mai mici, cu atât calitatea execuției testelor este mai bună. Intervalul acceptabil este, în general, definit de obiectivele proiectului sau comparat cu proiecte similare. În acest exemplu, intervalul acceptabil recomandat este 5% la 10%Execuția actuală se încadrează în acest interval, ceea ce semnalează că ar trebui îmbunătățită calitatea testelor prin următoarele măsuri:
- Îmbunătăți abilitățile de testare ale membrilor echipei.
- Petrece mai mult timp la execuția testelor, în special la revizuirea rezultatelor execuției.
Cele mai bune practici pentru gestionarea eficientă a defectelor
Respectarea celor mai bune practici structurate este ceea ce diferențiază un proces matur de gestionare a defectelor de unul haotic. Scopul nu este doar de a remedia erorile, ci de a crea un sistem care să prevină pătrunderea acestora în producție și să minimizeze întreruperile de comunicare dintre testeri și dezvoltatori.
Iată cele mai bune practici pe care testerii începători și intermediari ar trebui să le adopte imediat:
- Standardizați șablonul defectului: Utilizați un șablon de raport de defecte corectate care conține câmpuri precum ID defect, Description, Pași de reproducere, Severitate, Prioritate, Mediu și Atașamente. Consecvența reduce schimburile de replici dintre testeri și dezvoltatori.
- Prioritizează înainte de a atribui: Clasificați întotdeauna defectele în funcție de gravitate și prioritate înainte de a le trimite dezvoltatorilor. Acest lucru asigură că problemele critice nu rămân blocate în spatele celor cosmetice.
- Reproduceți înainte de raportare: Reproduceți defectul de cel puțin două ori într-un mediu curat înainte de a-l detecta. Defectele reproductibile se închid mai repede și reduc rata de respingere.
- Adoptă un defect tracinstrumentul regelui: Utilizați instrumente precum JIRA, Bugzilla, Mantis a centraliza tracrege, istorie și reportaj.
- Desfășurarea întâlnirilor de triaj: Organizați întâlniri scurte și specifice de triere a defectelor pentru a alinia prioritățile dintre echipele de asigurare a calității, dezvoltare și produs.
- Măsurarea scurgerilor și a respingerii: Track DLR și DRR la fiecare sprint sau ciclu. O rată de scurgere în creștere este un avertisment timpuriu că acoperirea testului este incompletă.
- Efectuați analiza cauzelor principale: Pentru defecte recurente sau de severitate ridicată, rulați o analiză a cauzei principale, astfel încât aceeași clasă de eroare să nu revină în versiunile viitoare.
- Închideți bucla cu raportarea: Partajați tablouri de bord săptămânale pentru defecte cu părțile interesate, astfel încât problemele să rămână vizibile și să poată fi acționate.
Aplicate consecvent, aceste practici stabilizează ciclul de viață al defectelor și ridică calitatea generală a fiecărei versiuni.
Resurse:
Descărcați un exemplu de șablon de raportare a defecțiunilor
