Meniu

Urmărirea bug-urilor proiectului în direct, valorile de testare și deconectarea testului - Ziua de antrenament QA gratuit 6

  • Principal
  • Urmărirea Defectelor
  • Urmărirea bug-urilor proiectului în direct, valorile de testare și deconectarea testului - Ziua de antrenament QA gratuit 6

live project bug tracking

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Aceasta este partea finală a Instruire pentru testarea software-ului pe un proiect live ' serie.

Va fi vorba despre defecte și, de asemenea, câteva subiecte rămase care vor marca finalizarea fazei de Execuție a Testului STLC.

În articolul anterior , în timp ce Execuția Testului se desfășura, am întâlnit o situație în care rezultatul scontat al cazului de testare nu a fost îndeplinit. De asemenea, am identificat un comportament neașteptat în timpul testării exploratorii.

Urmărirea bug-urilor proiectului în direct, valorile de testare și deconectarea testului

Ce se întâmplă când întâlnim aceste abateri?

Evident, trebuie să le înregistrăm și să le urmărim pentru a ne asigura că aceste abateri sunt gestionate și, în cele din urmă, fixate pe AUT.

# 1) Aceste abateri sunt denumite Defecte / erori / probleme / incidente / erori / defecte.

#Două) Toate cazurile următoare pot fi înregistrate ca defecte

  • Cerințe lipsă
  • Cerințe de lucru incorecte
  • Cerințe suplimentare
  • Inconsistențe ale documentului de referință
  • Probleme legate de mediu
  • Sugestii de îmbunătățire

# 3) Înregistrarea defectelor se face în cea mai mare parte în foi Excel sau prin utilizarea unui software / instrument de gestionare a defectelor. Pentru informații despre cum să gestionați defectele prin intermediul instrumentelor, încercați să utilizați următoarele link-uri:

Ce veți învăța:

Cum să înregistrați efectiv defectele

Vom încerca acum să vedem cum să înregistrăm defectele pe care le-am întâlnit în articolul anterior într-o foaie Excel. Ca întotdeauna, este important să alegeți un format sau șablon standard.

implementați arborele de căutare binară în java

De obicei, următoarele coloane fac parte din Raportul de defecte:

  • ID defect: Pentru identificare unică.
  • Descrierea defectului: Acesta este ca un titlu pentru a descrie pe scurt problema.
  • Modulul / secțiunea AUT: Acest lucru este opțional, doar pentru a adăuga mai multă claritate în ceea ce privește indicarea zonei AUT în care a fost întâlnită problema.
  • Pasi pentru reproducere: Care este secvența exactă a operațiunilor care trebuie efectuate pe AUT pentru a recrea eroarea trebuie listate aici. De asemenea, dacă datele de intrare sunt specifice problemei, trebuie introduse și informațiile.
  • Severitate: Pentru a indica intensitatea problemei și, în cele din urmă, impactul pe care acesta l-ar putea avea asupra funcționării AUT. Liniile directoare despre cum să atribuiți și ce valori să atribuiți în acest câmp pot fi găsite în documentul planului de testare. Deci, vă rugăm să consultați Documentul Planului de testare din articolul 3 .
  • Stare: Va fi discutat în continuare în articol.
  • Captură de ecran: Un instantaneu al aplicației pentru a afișa eroarea când s-a întâmplat.

Acestea sunt câteva dintre câmpurile „obligatorii”. Acest șablon poate fi extins (de exemplu, pentru a include numele testerului care a raportat problema) sau contractat ( De exemplu, numele modulului eliminat) după cum este necesar.

Urmând liniile directoare de mai sus și folosind șablonul de mai sus, un exemplu de jurnal / raport de defecte ar putea arăta astfel:

Exemplu de raport de defecte pentru proiectul OrangeHRM Live:

Raport de defecte OrangeHRM

=> Faceți clic aici pentru a descărca Raportul defectelor proiectului live

Mai jos este un exemplu de raport de defecte creat în instrumentul qTest Management Management: (Faceți clic pe imagine pentru a mări)

Exemplu de raport de defecte

Defectele nu sunt bune atunci când le înregistrăm și le păstrăm pentru noi. Va trebui să le atribuim în ordinea corectă pentru ca echipele în cauză să acționeze asupra lor. Procesul - cui să atribuiți sau ce ordine să urmați poate fi găsit și în documentul planului de testare. Este în mare parte similar cu (Faceți clic pe imagine pentru a mări)

Ciclul defectelor:

Defectează ciclul de viață 1

Din procesul de mai sus, se poate remarca faptul că erorile trec prin oameni diferiți și decizii diferite în procesul de a fi identificate până la remedieri. Pentru a urmări și a stabili transparența cu privire la exact starea la care se află o anumită eroare, în raportul de erori se folosește un câmp „Stare”. Întregul proces este denumit „ciclul de viață al erorilor”. Pentru mai multe informații despre toate stările și semnificațiile acestora, vă rugăm să consultați acest lucru Tutorial Bug Ciclu de viață .

Câțiva indicatori în timp ce urmărirea erorilor

  • Când suntem noi pentru o echipă creativă / proiect / AUT, este întotdeauna cel mai bine să o facem discutați problema pe care am întâlnit-o cu un coleg pentru a ne asigura că înțelegerea noastră despre ceea ce face cu adevărat un defect este corectă sau nu.
  • La furnizați toate informațiile acest lucru este necesar pentru a reproduce problema. Un defect care revine unei echipe de testare cu starea setată ca „Informații insuficiente” nu se reflectă foarte pozitiv asupra noastră. Verificați această postare - Cum să vă rezolvați toate erorile fără eticheta „Eroare nevalidă” .
  • Verificați dacă a fost ridicată o problemă similară înainte de a crea una nouă. Probleme „duplicate” sunt, de asemenea, vești proaste pentru echipa QA.
  • Dacă există o problemă, aceasta apare la întâmplare și nu știm exact pașii / situațiile în care putem recrea problema - ridicați problema la fel. Cu riscul ca problema să fie stabilită la „Informații ireproductibile / insuficiente” - trebuie totuși să ne asigurăm că am tratat toate defecțiunile posibile în cea mai bună măsură posibilă.
  • Practica generală este că echipa QA creează defectele fiecăruia într-o foaie Excel pe parcursul unei zile și o consolidează la sfârșitul zilei.

Ciclul de viață complet al defectelor

Pentru proiectul nostru live, dacă ar urma să urmăm ciclul de viață al defectului pentru defectul 1,

gateway-ul implicit nu este disponibil Windows 10 wifi
  • Când eu (testerul) îl creez, statutul său este 'Nou”. Când îl atribui conducătorului echipei QA, starea este încă „Nouă”, dar proprietarul este acum conducătorul QA.
  • Lead-ul QA va revizui problema și, la stabilirea faptului că este o problemă validă, problema este atribuită lead-ului Dev. În această fază, statutul este 'Desemnat' iar proprietarul este Dev Dev.
  • Conducătorul dezvoltatorului va atribui această problemă unui dezvoltator care va lucra la remedierea acestei probleme. Starea va fi acum 'Lucrare în curs' (sau ceva similar cu acest efect), proprietarul este dezvoltatorul.
  • Pentru defectul 1, dezvoltatorul nu este capabil să reproducă eroarea, așa că îl atribuie înapoi echipei QA și stabilește starea ca 'Nu se poate reproduce”.
  • Alternativ, dacă dezvoltatorul ar putea lucra la aceasta și a remedia o problemă, starea ar fi setată la 'rezolvat' iar problema va fi atribuită înapoi echipei QA.
  • Echipa QA o va prelua, va testa din nou problema și, dacă este rezolvată, va seta starea la 'Închis' . Dacă problema persistă, starea este setată la 'Redeschide' iar procesul continuă.
  • În funcție de celelalte situații, starea poate fi setată ca 'Amânat' , „Informații insuficiente”, 'Duplicat' , 'funcționând conform intenției' , etc de către dezvoltator.
  • Această metodă de înregistrare a defectelor, raportare și atribuire a acestora, gestionarea acestora este una dintre activitățile majore desfășurate de membrii echipei QA în timpul fazei de execuție a testului. Acest lucru se face zilnic până la finalizarea unui anumit ciclu de testare.
  • Odată ce ciclul 1 este finalizat, echipa de dezvoltatori va lua o zi sau două pentru a consolida toate remedierile și a reconstrui codul în următoarea versiune care va fi utilizată pentru următorul ciclu.
  • Același proces continuă din nou și pentru ciclul 2. La sfârșitul ciclului, există șansa ca în aplicație să mai existe unele probleme „Deschise” sau nesoluționate.
  • În această etapă - continuăm în continuare cu ciclul 3? Dacă da, când vom opri testarea?

Criterii de ieșire pentru testarea proiectului OrangeHRM Live

Aici folosim ceea ce am numi „Criteriile de ieșire”. Acest lucru este predefinit în documentul Planului de testare. Pur și simplu sub forma listei de verificare va stabili dacă încheiem testarea după ciclul 2 sau mergem pentru încă un ciclu. Se pare că, de mai jos, atunci când este completat, luând în considerare câteva răspunsuri ipotetice la următoarele întrebări referitoare la proiectul OrangeHRM:

Criterii de ieșire de testare

Când ne uităm cu atenție la lista de verificare de mai sus, există valori și semne de semnare menționate acolo despre care nu am discutat mai devreme. Să vorbim despre ele acum.

Valori de testare

Am stabilit că în timpul fazei de Execuție a Testului, rapoartele sunt trimise tuturor celorlalți membri ai echipei de proiect pentru a da o idee clară despre ce se întâmplă în faza de executare QA . Aceste informații sunt importante pentru toată lumea, pentru a obține validarea calității generale a produsului final.

Imaginați-vă că raportez că au fost executate 10 cazuri de testare sau au fost executate 100 de cazuri de testare - aceste cifre sunt doar date brute și nu oferă o perspectivă foarte bună despre cum se întâmplă lucrurile.

Valorile joacă un rol vital în completarea acestui gol. Valorile sunt în cuvinte simple, numere inteligente pe care echipa de testare le colectează și le menține . De exemplu, dacă am spus că 90% din cazurile de testare au trecut, are mai mult sens decât să spun că 150 de cazuri de testare au trecut. Nu-i așa?

Există diferite tipuri de valori colectate în timpul fazei de execuție a testului. Ce valori trebuie colectate și întreținute exact pentru ce perioade de timp - aceste informații pot fi găsite în documentul planului de testare.

Următoarele sunt cele mai frecvent colectate valori de testare pentru majoritatea proiectelor:

  • Procentul de promovare a cazurilor de testare
  • Densitatea defectelor
  • Procentul de defecte critice
  • Defecte, număr înțelept de severitate

Verificați Raport de stare atașat acestui articol pentru a vedea cum sunt utilizate aceste valori.

Test Semnare / Raport finalizare

Întrucât trebuie să anunțăm toate părțile interesate că testele au început, este de asemenea datoria echipei QA să anunțe pe toată lumea că testarea a fost finalizată și să împărtășească rezultatele. Deci, în mod obișnuit, un e-mail este trimis de echipa QA (de obicei, conducătorul echipei / Managerul QA), oferind o indicație că echipa QA a semnat produsul care atașează rezultatele testului și lista problemelor deschise / cunoscute.

Test de e-mail de eșantionare:

La: Client, PM, echipa Dev, echipa DB, echipa BA, QA, Echipa de mediu (și oricine altcineva care trebuie inclus)
E-mail: Bună echipă,

Echipa QA semnează software-ul OrangeHRM versiunea 3.0 după finalizarea cu succes a celor 2 cicluri de testare funcțională a site-ului web.

Cazurile de testare și rezultatele executării acestora sunt atașate la e-mail. (Sau menționați locația în care sunt prezenți. Sau, dacă utilizați software de gestionare a testelor, furnizați detalii cu privire la aceștia.)

Lista problemelor cunoscute este atașată și la e-mail. (Din nou, orice alte referințe care au sens pot fi adăugate.)

Mulțumiri,
Conducător de echipă QA.

Atașamente: Raport final de execuție, raport final de emisie / defect, listă de probleme cunoscute

Odată ce e-mailul de semnare a testului a ieșit de la echipa QA, am terminat oficial procesul STLC. Acest lucru nu marchează neapărat finalizarea fazei „Test” a SDLC. Mai avem testele UAT de finalizat pentru ca acest lucru să se întâmple. Găsi mai multe detalii despre testarea UAT aici .

După terminarea UAT, SDLC trece la implementarea fazei în care intră în funcțiune și este disponibil clienților / utilizatorilor săi pentru a fi consumat.

Asta este!

Acesta a fost efortul nostru de a aduce cititorilor noștri experiența cea mai live, precum QA Project. Vă rugăm să ne anunțați comentariile și întrebările dvs. despre această serie de cursuri de testare software QA online gratuite.

Lectură recomandată

^