Meniu

Procesul de gestionare a defectelor: Cum să gestionați eficient un defect

  • Principal
  • Alte
  • Procesul de gestionare a defectelor: Cum să gestionați eficient un defect

defect management process

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Introducere în procesul de gestionare a defectelor:

Procesul și testarea mai concentrate vor permite software-ul mai puțin buggy pe piață.

Prevenirea defectelor este mult mai eficient și mai eficient în reducerea numărului de defecte și, de asemenea, este foarte rentabil pentru remedierea defectelor constatate în faza incipientă a procesului software. Majoritatea organizațiilor conduc Descoperirea defectelor , Eliminarea defectelor și apoi Îmbunătățirea procesului care este cunoscută în mod colectiv ca a Procesul de gestionare a defectelor .

Procesul de gestionare a defectelor

lista de adiacență a graficului c ++

Ce veți învăța:

Obiectivele procesului de gestionare a defectelor (DMP)

Mai jos sunt prezentate diferitele obiective ale acestui proces:

  • Preveniți defectul
  • Detectare timpurie
  • Minimizați impactul
  • Rezolvarea defectului
  • Îmbunătățirea procesului

Înainte de a explora procesul de gestionare a defectelor, să ne înțelegem mai întâi ce este de fapt un defect sau o eroare?

Ciclul de viață al gestionării defectelor

Atunci când un sistem oferă un rezultat diferit de cerința reală a activității, adică atunci când există o abatere de la cerința reală sau originală a activității, atunci putem spune că există un defect în sistem / software.

Când echipa de testare execută cazurile de testare, se confruntă cu o situație în care rezultatul real al testului este diferit de rezultatul așteptat. Această variație este denumită a Defect .

Practic, un defect software este o condiție care nu îndeplinește cerința software. Defectul este o eroare sau un defect care produce un comportament neașteptat sau incorect în sistem.

Pentru a gestiona proiectele în mod adecvat, trebuie să știți cum să faceți față dezvoltării și lansării, dar împreună cu aceasta trebuie să știți cum să gestionați defectele.

Imaginați-vă, ce se va întâmpla dacă echipa de testare raportează defectele verbal și echipa de dezvoltare actualizează și starea defectului verbal? Procesul va fi mai complicat, deoarece aceste defecte includ toate defectele, cum ar fi efectiv remediate și funcționează așa cum era de așteptat, remediate, dar încă nu funcționează, respinse, amânate și procesul continuă.

În cazul de mai sus, pe măsură ce numărul defectelor crește și comunicarea se realizează verbal, situația va fi în curând foarte gravă. Pentru a controla și gestiona defectul în mod eficient, aveți nevoie de un ciclu de viață corect al defectelor.

Ciclul de viață al defectelor asigură uniformizarea și standardizarea procesului. Un defect atinge diferite stări în ciclul de viață. După ce a fost găsit un defect, acesta trece prin diferite etape pe parcursul vieții sale și este cunoscut sub numele de Ciclul de viață al defectelor .

În general, ciclul de viață al defectului începe de la etapa în care defectul este găsit sau ridicat de echipa de testare și se termină atunci când un defect este închis fie asigurându-se că nu este reproductibil, fie respins de o echipă de dezvoltare. Numărul de stări prin care trece un defect variază de la proiect la proiect.

Lecturi suplimentare:

Ce este ciclul de viață al defectelor / erorilor în testarea software-ului? Tutorial privind ciclul de viață al defectelor

Notă: Ciclul de mai jos diferă ușor de la organizație la organizație.

Ciclul de viață al defectului de mai jos acoperă toate stările posibile:

Diagrama de flux a ciclului de viață cu defecte

  • Ori de câte ori echipa de testare găsește un defect în aplicație, ridică defectul cu starea „ NOU ”.
  • Când un nou defect este revizuit de un client QA și dacă defectul este valid, atunci starea defectului ar fi „ Deschis ”Și este gata să fie repartizat echipei de dezvoltare.
  • Când un client QA atribuie defectul dezvoltatorului corespunzător, starea defectului ar fi marcată ca „ Desemnat ”. Un dezvoltator ar trebui să înceapă să analizeze și să remedieze defectul în această etapă.
  • Când dezvoltatorul consideră că defectul nu este autentic sau valid, atunci dezvoltatorul respinge defectul. Starea defectului este marcată ca „ Respins ”Și repartizat echipei de testare.
  • Dacă defectul înregistrat se repetă de două ori sau ambele defecte raportate au rezultate și pași similari de reprodus, atunci starea unui defect se schimbă în „ Duplicat ”.
  • Dacă există unele probleme sau obstacole în versiunea curentă pentru remedierea unui anumit defect, atunci defectul va fi luat în versiunile viitoare în loc de versiunea curentă și apoi este marcat ca „ Amânat ”Sau„ Amânat ”.
  • Atunci când un dezvoltator nu poate reproduce defectul prin pașii menționați în „Pașii de reproducere” de către echipa de testare, atunci dezvoltatorul poate marca defectul ca „ Nu este reproductibil ” . În această etapă, echipa de testare ar trebui să furnizeze dezvoltatorilor pași detaliați de reproducere.
  • Dacă dezvoltatorul nu este clar cu privire la pașii de reproducere furnizați de un QA pentru a reproduce defectul, atunci el / ea îl poate marca ca „ Ai nevoie de mai multe informații ”. În acest caz, echipa de testare trebuie să furnizeze detaliile necesare echipei de dezvoltare.
  • Dacă un defect este deja cunoscut și este prezent în prezent în mediul de producție, atunci defectul este marcat ca „ Defect cunoscut ”.
  • Când un dezvoltator face modificările necesare, atunci defectul este marcat ca „ Fix ”.
  • Dezvoltatorul transmite acum defectul echipei de testare pentru verificare, astfel încât dezvoltatorul schimbă starea ca „ Gata pentru retestare ”.
  • Dacă defectul nu are alte probleme și este verificat corespunzător, testerul marchează defectul ca „ Închis ”.
  • În timp ce re-testați defectul dacă testerul a constatat că, defectul este încă reproductibil sau parțial remediat, atunci defectul ar fi marcat ca „ Redeschis ”. Acum dezvoltatorul trebuie să se uite din nou la acest defect.

Un ciclu de viață al defectelor bine planificat și controlat oferă numărul total de defecte găsite într-o versiune sau în toate versiunile. Acest proces standardizat oferă o imagine clară a modului în care a fost scris codul, cât de corect a fost efectuată testarea, cum a fost eliberat defectul sau software-ul etc. Acest lucru va reduce numărul de defecte în producție prin găsirea defectelor în testare fază în sine.

Procesul de gestionare a defectelor

Procesul de gestionare a defectelor

Procesul de gestionare a defectelor este explicat mai jos în detaliu.

# 1) Prevenirea defectelor:

Prevenirea defectelor este cea mai bună metodă de eliminare a defectelor în stadiul incipient al testării, în loc de găsirea defectelor în etapa ulterioară și apoi remedierea acestuia. Această metodă este, de asemenea, rentabilă, deoarece costul necesar pentru remedierea defectelor constatate în primele etape ale testării este foarte mic.

Cu toate acestea, nu este posibil să eliminați toate defectele, dar cel puțin puteți minimiza impactul defectului și costul pentru a remedia aceleași defecte.

Pașii majori implicați în prevenirea defectelor sunt următorii:

  • Identificați riscul critic : Identificați riscurile critice din sistem care vor avea un impact mai mare dacă au apărut în timpul testării sau în etapa ulterioară.
  • Estimarea impactului așteptat : Pentru fiecare risc critic, calculați cât de mare ar fi impactul financiar dacă riscul ar întâlni efectiv.
  • Minimizați impactul așteptat : Odată ce identificați toate riscurile critice, asumați-vă cele mai importante riscuri care pot fi dăunătoare sistemului dacă sunt întâlnite și încercați să minimalizați sau să eliminați riscul. Pentru riscurile care nu pot fi eliminate, reduce probabilitatea de apariție și impactul său financiar.

# 2) Linie de bază livrabilă:

Atunci când un livrabil (sistem, produs sau document) atinge obiectivul prestabilit, atunci puteți spune că un livrabil este o linie de bază. În acest proces, produsul sau livrabilul se mută de la o etapă la alta și pe măsură ce livrabilul se mută de la o etapă la alta, defectele existente în sistem sunt, de asemenea, reportate la următoarea etapă sau etapă.

De exemplu, ia în considerare un scenariu de codificare, testare unitară și apoi testare a sistemului. Dacă un dezvoltator efectuează codarea și testarea unității, testarea sistemului este efectuată de echipa de testare. Aici codarea și testarea unităților reprezintă o etapă importantă, iar testarea sistemului este o altă etapă importantă.

Deci, în timpul testării unitare, dacă dezvoltatorul găsește unele probleme, atunci nu este apelat ca un defect, deoarece aceste probleme sunt identificate înainte de respectarea termenului limită. După finalizarea codificării și testării unitare, dezvoltatorul predă codul pentru testarea sistemului și apoi puteți spune că codul este „Bazat” și gata pentru următoarea etapă, aici, în acest caz, este „testarea sistemului”.

Acum, dacă problemele sunt identificate în timpul testării, atunci se numește defect, deoarece este identificat după finalizarea etapei anterioare, adică codificare și testare unitară.

Practic, livrabilele sunt bazate pe când modificările livrabilelor sunt finalizate și toate defectele posibile sunt identificate și remediate. Apoi, același livrabil trece la următorul grup care va lucra la el.

# 3) Descoperirea defectelor:

Este aproape imposibil să eliminați toate defectele din sistem și să faceți un sistem ca unul fără defecte. Dar puteți identifica defectele devreme înainte de a deveni mai costisitoare pentru proiect. Putem spune că defectul descoperit înseamnă că este adus în mod oficial în atenția echipei de dezvoltare și, după analiza acestuia, echipa de dezvoltare a defectului a acceptat-o ​​și ca defect.

Pașii implicați în descoperirea defectelor sunt după cum urmează:

  • Găsiți un defect : Identificați defectele înainte ca acestea să devină o problemă majoră pentru sistem.
  • Raportează defect : De îndată ce echipa de testare găsește un defect, responsabilitatea lor este de a informa echipa de dezvoltare că există o problemă identificată care trebuie analizată și remediată.
  • Recunoașteți defectul : Odată ce echipa de testare atribuie defectul echipei de dezvoltare, responsabilitatea echipei de dezvoltare este de a recunoaște defectul și de a continua să îl remedieze dacă este un defect valid.

# 4) Rezolvarea defectelor:

În procesul de mai sus, echipa de testare a identificat defectul și a raportat echipei de dezvoltare. Acum, aici echipa de dezvoltare trebuie să procedeze pentru rezolvarea defectului.

Pașii implicați în soluționarea defectelor sunt după cum urmează:

  • Prioritizați riscul : Echipa de dezvoltare analizează defectul și acordă prioritate remedierii defectului. În cazul în care un defect are un impact mai mare asupra sistemului, atunci acesta face ca remedierea defectului să fie cu o prioritate ridicată.
  • Remediați defectul : Pe baza priorității, echipa de dezvoltare remediază defectul, defectele cu prioritate mai mare sunt rezolvate mai întâi și defectele cu prioritate mai mică sunt remediate la sfârșit.
  • Raportați rezoluția : Este responsabilitatea echipei de dezvoltare de a se asigura că echipa de testare este conștientă când defectele sunt soluționate și cum a fost remediat defectul, adică prin schimbarea unuia dintre fișierele de configurare sau efectuarea unor modificări de cod. Acest lucru va fi util pentru ca echipa de testare să înțeleagă cauza defectului.

# 5) Îmbunătățirea procesului:

Deși în procesul de rezolvare a defectelor, defectele sunt prioritare și remediate, din perspectiva procesului, nu înseamnă că defectele cu prioritate mai mică nu sunt importante și nu afectează prea mult sistemul. Din punct de vedere al îmbunătățirii procesului, toate defectele identificate sunt identice cu un defect critic.

Chiar și aceste defecte minore oferă o oportunitate de a învăța cum să îmbunătățească procesul și să prevină apariția oricărui defect care ar putea afecta defecțiunile sistemului în viitor. Identificarea unui defect care are un impact mai mic asupra sistemului poate să nu fie o mare problemă, dar apariția unui astfel de defect în sistem în sine este o mare problemă.

Pentru îmbunătățirea procesului, toată lumea din proiect trebuie să privească înapoi și să verifice de unde a apărut defectul. Pe baza acestora, puteți face modificări în procesul de validare, documentul de bază, procesul de revizuire, care poate detecta defectele la începutul procesului, care sunt mai puțin costisitoare.

cum se deschide fișierul jnlp în Windows 10

Concluzie

Procesul de gestionare a defectelor trebuie urmat în timpul procesului general de dezvoltare a software-ului și nu numai pentru activități specifice de testare sau dezvoltare.

Dacă un defect a fost găsit în faza de testare, atunci se poate ridica o întrebare că, dacă defectul este prins în această fază, atunci ce se întâmplă cu celelalte defecte care sunt în viață în sistem, care pot provoca defecțiuni ale sistemului dacă apar și nu sunt încă descoperite.

Deci, toate procesele, cum ar fi procesul de revizuire, testarea statică, inspecția etc., trebuie consolidate și toată lumea din proiect ar trebui să fie serioasă în ceea ce privește procesul și să contribuie ori de câte ori este necesar. Conducerea superioară din organizație ar trebui să înțeleagă și să susțină procesul de gestionare a defectelor.

Abordările de testare, procesul de revizuire etc., ar trebui să se aleagă pe baza obiectivului proiectului sau a procesului organizațional.

Sper că acest articol informativ despre procesul de gestionare a defectelor vă va fi de un ajutor imens.

Lectură recomandată

^