what is defect bug life cycle software testing
Introducere în ciclul de viață al defectelor
În acest tutorial, voi vorbi despre ciclul de viață al unui defect pentru a vă face conștient de diferitele etape ale unui defect cu care un tester trebuie să facă față în timp ce lucrează într-un mediu de testare.
Am adăugat, de asemenea, cele mai frecvente întrebări ale interviului pe ciclul de viață al defectelor. Acest lucru este important de știut despre diferitele stări ale unui defect pentru înțelegerea ciclului de viață al unui defect. Principala intenție de a efectua o activitate de testare este de a verifica dacă produsul are probleme / erori.
În ceea ce privește scenariile reale, erorile / greșelile / defecțiunile sunt denumite toate bug-uri / defecte și, prin urmare, putem spune că obiectivul principal al efectuării testelor este să se asigure că produsul este mai puțin predispus la defecte (fără defecte este o situație nerealistă ).
Acum, se pune întrebarea ce este un Defect?
Ce veți învăța:
- Ce este un defect?
- Defectează ciclul de viață în detaliu
- Informații suplimentare despre defect sau eroare
- Concluzie
Ce este un defect?
Un defect, în termeni simpli, este un defect sau o eroare într-o aplicație care restricționează fluxul normal al unei aplicații prin nepotrivirea comportamentului așteptat al unei aplicații cu cel real.
Defectul apare atunci când orice greșeală este făcută de un dezvoltator în timpul proiectării sau construirii unei aplicații și când acest defect este găsit de un tester, este denumit defect.
Este responsabilitatea unui tester să facă testarea amănunțită a unei aplicații pentru a găsi cât mai multe defecte posibil pentru a se asigura că un produs de calitate va ajunge la client.
Este important să înțelegeți despre ciclul de viață al defectului înainte de a trece la fluxul de lucru și diferitele stări ale defectului.
Prin urmare, să aflăm mai multe despre ciclul de viață al defectelor.
Până în prezent, am discutat despre semnificația defectului și relația acestuia în context cu activitatea de testare. Acum, să trecem la ciclul de viață al defectului și să înțelegem fluxul de lucru al unui defect și diferitele stări ale unui defect.
Defectează ciclul de viață în detaliu
Un ciclu de viață al defectului, cunoscut și sub numele de ciclu de viață al insectei, este un ciclu al unui defect din care trece prin acoperirea diferitelor stări din întreaga sa viață. Acest lucru începe imediat ce un nou defect este găsit de un tester și se termină atunci când un tester închide defectul, asigurându-se că nu va fi reprodus din nou.
Flux de lucru cu defecte
Este timpul să înțelegem fluxul de lucru real al unui ciclu de viață cu defecte, cu ajutorul unei diagrame simple, așa cum se arată mai jos.
Defectează statele
# 1) Nou :Aceasta este prima stare a unui defect din ciclul de viață al defectelor. Când se constată un defect nou, acesta se încadrează într-o stare „Nouă”, iar validările și testările sunt efectuate pentru acest defect în etapele ulterioare ale ciclului de viață al defectelor.
# 2) Atribuit: În această etapă, un defect nou creat este atribuit echipei de dezvoltare pentru lucrul la defect. Aceasta este atribuită unui dezvoltator de către conducătorul proiectului sau de către managerul echipei de testare.
# 3) Deschis: Aici, dezvoltatorul începe procesul de analiză a defectului și lucrează la remedierea acestuia, dacă este necesar. Dacă dezvoltatorul consideră că defectul nu este adecvat, atunci acesta poate fi transferat în oricare dintre cele patru stări de mai jos, și anume Duplicat, amânat, respins sau nu o eroare - pe baza motivului specific.
Voi discuta aceste patru stări într-un timp.
# 4) S-a remediat: Când dezvoltatorul termină sarcina de a remedia un defect prin efectuarea modificărilor necesare, atunci acesta poate marca starea defectului ca „Remediat”.
# 5) În așteptarea retestării: După remedierea defectului, dezvoltatorul atribuie defectul testerului pentru testarea din nou a defectului la sfârșitul lor și, până când testerul lucrează la retestarea defectului, starea defectului rămâne în „Retestare în așteptare”.
# 6) Reîncercare: În acest moment, testerul începe sarcina de a lucra la re-testarea defectului pentru a verifica dacă defectul este remediat cu precizie de către dezvoltator conform cerințelor sau nu.
# 7) Redeschideți: Dacă orice problemă persistă în defect, aceasta va fi atribuită din nou dezvoltatorului pentru testare, iar starea defectului va fi schimbată în „Redeschide”.
# 8) Verificat: Dacă testerul nu găsește nicio problemă în defect după ce a fost atribuit dezvoltatorului pentru retestare și consideră că dacă defectul a fost remediat cu exactitate, atunci starea defectului este atribuită „Verificat”.
# 9) Închis: Când defectul nu mai există, testerul schimbă starea defectului în „Închis”.
pl sql întrebări și răspunsuri la interviuri pentru pdf cu experiență
Puțin mai multe:
- Respins: Dacă defectul nu este considerat ca un defect autentic de către dezvoltator, atunci acesta este marcat ca „Respins” de către dezvoltator.
- Duplicat: Dacă dezvoltatorul găsește defectul la fel ca orice alt defect sau dacă conceptul defectului se potrivește cu orice alt defect, starea defectului este modificată în „Duplicat” de către dezvoltator.
- Amânat: Dacă dezvoltatorul consideră că defectul nu are o prioritate foarte importantă și poate fi remediat în următoarele versiuni sau cam așa într-un astfel de caz, el poate schimba starea defectului ca „Amânat”.
- Nu este un bug: Dacă defectul nu are impact asupra funcționalității aplicației, atunci starea defectului se schimbă în „Nu este o eroare”.
câmpuri obligatorii când un tester înregistrează orice eroare nouă sunt versiunea Build, Submit On, Product, Module, Severity, Synopsis și Description to Reproduce
În lista de mai sus, puteți adăuga câteva câmpuri opționale dacă utilizați un șablon manual de trimitere a erorilor. Aceste câmpuri opționale includ numele clientului, browserul, sistemul de operare, fișierele atașate sau capturile de ecran.
Următoarele câmpuri rămân fie specificate, fie necompletate:
Dacă aveți autoritatea de a adăuga câmpurile Stare eroare, Prioritate și „Atribuit la” atunci puteți specifica aceste câmpuri. În caz contrar, Managerul de testare va seta starea, prioritatea bug-ului și va atribui bug-ul proprietarului modulului respectiv.
Uită-te la următorul ciclu Defect
Imaginea de mai sus este destul de detaliată și când luați în considerare pașii semnificativi din ciclul de viață al bug-ului, veți avea o idee rapidă despre aceasta.
La înregistrarea cu succes, eroarea este revizuită de managerul de dezvoltare sau test. Managerul de testare poate seta starea erorii ca Deschis, poate atribui eroarea dezvoltatorului sau eroarea poate fi amânată până la următoarea versiune.
Când un bug este atribuit unui dezvoltator și el / ea poate începe să lucreze la el. Dezvoltatorul poate seta starea de eroare ca nu se va remedia, Nu s-a putut reproduce, Necesită mai multe informații sau „S-a remediat”.
Dacă starea de eroare setată de dezvoltator este fie „Aveți nevoie de mai multe informații”, fie este remediată, QA răspunde cu o acțiune specifică. Dacă bug-ul este rezolvat, QA verifică bug-ul și poate seta starea bug-ului ca fiind verificată închisă sau redeschisă.
Liniile directoare pentru implementarea ciclului de viață al defectelor
Unele linii directoare importante pot fi adoptate înainte de a începe să lucreze cu ciclul de viață al defectelor.
Acestea sunt după cum urmează:
- Este foarte important ca înainte de a începe să lucreze la ciclul de viață al defectelor, întreaga echipă să înțeleagă în mod clar diferitele stări ale unui defect (discutat mai sus).
- Ciclul de viață al defectelor ar trebui să fie documentat corespunzător pentru a evita orice confuzie în viitor.
- Asigurați-vă că fiecare persoană căreia i s-a atribuit orice sarcină legată de ciclul de viață al defectelor ar trebui să-și înțeleagă responsabilitatea foarte clar pentru rezultate mai bune.
- Fiecare persoană care schimbă starea unui defect ar trebui să fie conștientă în mod corespunzător de acest statut și ar trebui să ofere suficiente detalii despre starea și motivul pentru care a pus acel statut, astfel încât toți cei care lucrează la acel defect să poată înțelege motivul unui astfel de statut. a unui defect foarte ușor.
- Instrumentul de urmărire a defectelor trebuie manipulat cu grijă pentru a menține coerența dintre defecte și astfel, în fluxul de lucru al ciclului de viață al defectelor.
În continuare, să discutăm întrebările interviului pe baza ciclului de viață al defectelor.
Întrebări frecvente importante sau întrebări de interviu privind ciclul de viață al erorilor
Q # 1) Ce este un defect în perspectiva testării software-ului?
Răspuns: Un defect este orice fel de eroare sau eroare în aplicație care restricționează fluxul normal al unei aplicații prin nepotrivirea comportamentului așteptat al unei aplicații cu cel real.
Q # 2) Care este diferența majoră între Eroare, Defect și Eșec?
Răspuns: Eroare: Dacă dezvoltatorii constată că există o nepotrivire în comportamentul real și așteptat al unei aplicații în faza de dezvoltare, atunci ei o numesc Eroare.
Defect: Dacă testerii găsesc o nepotrivire în comportamentul real și așteptat al unei aplicații în faza de testare, atunci îl numesc ca Defect.
Eșec: Dacă clienții sau utilizatorii finali găsesc o nepotrivire în comportamentul real și așteptat al unei aplicații în faza de producție, atunci ei o numesc Eșec.
Q # 3) Care este starea unui defect atunci când este găsit inițial?
Răspuns: Când se găsește un nou defect, acesta se află în starea „Nou”. Aceasta este starea inițială a unui defect nou găsit.
Q # 4) Care sunt diferitele stări ale unui defect în ciclul de viață al defectului atunci când un defect este aprobat și remediat de un dezvoltator?
Răspuns: Diferite stări ale unui defect, în acest caz, sunt noi, atribuite, deschise, corecte, în așteptarea retestării, retestării, verificate și închise.
Q # 5) Ce se întâmplă dacă un tester găsește în continuare o problemă în defect care este remediată de un dezvoltator?
Răspuns: Testerul poate marca starea defectului ca „Redeschideți” dacă găsește încă o problemă în defectul remediat și defectul este atribuit unui dezvoltator pentru retestare.
Q # 6) Ce este un defect producibil?
Răspuns: Un defect care apare în mod repetat în fiecare execuție și ale cărui etape pot fi capturate în fiecare execuție, atunci un astfel de defect se numește defect „producibil”.
Q # 7) Ce tip de defect este un defect care nu poate fi reprodus?
Răspuns: Un defect care nu apare în mod repetat în fiecare execuție și se produce doar în anumite cazuri și ai cărui pași ca dovadă trebuie să fie capturați cu ajutorul capturilor de ecran, atunci un astfel de defect este numit un defect „nerodabil”.
Q # 8) Ce este un raport de defecte?
Răspuns: Un raport de defecte este un document care include raportarea informațiilor despre defectul sau defectul din aplicație care cauzează fluxul normal al unei aplicații deviat de la comportamentul său așteptat.
Q # 9) Ce detalii sunt incluse într-un raport de defecte?
Răspuns: Un raport de defecte constă din următoarele detalii:
ID defect, Descrierea defectului, Numele caracteristicii, Numele cazului de testare, Defectul reproductibil sau nu, Starea unui defect, Severitatea și prioritatea unui defect, Numele testerului, Data testării defectului, Versiunea de construcție în care a fost găsit defectul .
Și dezvoltatorul căruia i-a fost atribuit defectul, numele persoanei care a remediat defectul, capturile de ecran ale unui defect care descrie fluxul pașilor, fixarea datei unui defect și persoana care a aprobat defectul.
Q # 10) Când se modifică un defect într-o stare „amânată” în ciclul de viață al defectului?
Răspuns: Când un defect găsit nu are o importanță foarte mare și cel care poate fi remediat în versiunile ulterioare este mutat într-o stare „amânată” în ciclul de viață al defectelor.
Informații suplimentare despre defect sau eroare
- Un defect poate fi introdus în orice moment al ciclului de viață al dezvoltării software-ului.
- Mai devreme este detectat și eliminat defectul, costul general al calității va fi mai mic.
- Costul calității este minimizat atunci când defectul este eliminat în aceeași fază în care a fost introdus.
- Testarea statică constată defectul, nu un eșec. Costul este minimizat deoarece depanarea nu este implicată.
- În testarea dinamică, prezența unui defect este dezvăluită atunci când provoacă o defecțiune.
Stări de defect
S.Nr. | Stare initiala | Statul returnat | Statul de confirmare |
---|---|---|---|
unu | Adunați informații pentru persoana responsabilă de reproducerea Defectului | Defectul este respins sau i se solicită mai multe informații | Defectul este remediat și trebuie testat și închis |
Două | Statele sunt deschise sau noi | Statele sunt respinse sau clarificate. | Statele sunt rezolvate și verificarea. |
Raport de defecte nevalid și duplicat
- Uneori apare un defect, nu din cauza codului, ci din cauza mediului de testare sau a neînțelegerii, un astfel de raport ar trebui închis ca defect nevalid.
- În cazul raportului duplicat, unul este păstrat și unul este închis ca duplicat. Un raport nevalid este acceptat de manager.
- Managerul de testare deține managementul și procesul general al defectelor, iar echipa multifuncțională a instrumentului de gestionare a defectelor este în general responsabilă de gestionarea rapoartelor.
- Printre participanți se numără Managerul de teste, Dezvoltatorii, PM, Managerul de producție și alți actori interesați.
- Comitetul de gestionare a defectelor ar trebui să stabilească valabilitatea fiecărui defect și să stabilească când să fie remediat sau amânat. Pentru a determina acest lucru, luați în considerare costul, riscurile și avantajul de a nu remedia niciun defect.
- Dacă defectul trebuie remediat, trebuie stabilită prioritatea acestuia.
Defect Data
- Numele persoanei.
- Tipul de testare
- Rezumatul problemei
- Descrierea detaliată a defectului.
- Pasi pentru reproducere
- Faza ciclului de viață
- Produs de lucru unde a fost introdus Defect.
- Severitate și prioritate
- Subsistem sau component în care este introdus defectul.
- Activitatea proiectului care apare atunci când Defectul este introdus.
- Metoda de identificare
- Tipul Defectului
- Proiect și produs în care există problema
- Proprietar actual
- Starea actuală a raportului
- Produs de lucru unde a apărut defectul.
- Impactul asupra proiectului
- Risc, pierdere, oportunitate și beneficii asociate cu remedierea sau nerezolvarea defectului.
- Date când apar diferite faze ale ciclului de viață ale defectelor.
- Descrierea modului în care a fost rezolvat defectul și recomandări pentru testare.
- Referințe
Capacitatea procesului
- Informații privind introducerea, detectarea și eliminarea -> Îmbunătățiți detectarea defectelor și costul calității.
- Introducere -> Analiza pretorului a procesului în care este introdus cel mai mare număr de defecte pentru a reduce numărul total de defecte.
- Informații despre rădăcina defectelor -> găsiți motive subliniate pentru defectul de a reduce numărul total de defecte.
- Informații despre componentele defecte -> Efectuați analiza clusterului de defecte.
Concluzie
Totul este despre ciclul de viață și managementul defectelor.
Sper că trebuie să fi dobândit cunoștințe imense despre ciclul de viață al unui defect. La rândul său, acest tutorial vă va ajuta în timp ce lucrați cu defectele în viitor într-un mod ușor.
Lectură recomandată
- Ce este tehnica de testare bazată pe defecte?
- Ce este ciclul de viață al testelor software (STLC)?
- Tutorial Bugzilla: Tutorial practic pentru instrumentul de gestionare a defectelor
- Fire Java cu metode și ciclu de viață
- Testarea software-ului se referă la idei (și cum să le generăm)
- Tutoriale detaliate pentru eclipsă pentru începători
- Procesul de gestionare a defectelor: Cum să gestionați eficient un defect
- Exemple de rapoarte de erori pentru aplicații web și produse