Completarea câmpurilor rapoarte de erori

Ciclul de viață bug

Înainte de a începe descrierea ciclului de viață bug elementar să ia în considerare următoarea diagramă bloc care prezintă principalele stările posibile și trecerile de la statutul la statutul în cursul existenței sale:

Acum ne întoarcem la o descriere a schemei.

Să presupunem că ați găsit un bug, și înregistrate în sistemul de urmărire a erorilor. Potrivit organigrame noastre, el va primi statutul de „nou“. Testerul este responsabil pentru validarea noilor rapoarte de erori, sau coordonatorul de proiect (în funcție de distribuția rolurilor în echipa ta), se poate transforma într-una din următoarele stări:

„Respins“, în cazul în care bug-ul este invalid sau repetate, sau pur și simplu nu a putut reproduce

„Amânați“, în cazul în care bug-ul nu este necesar să se corecteze în această iterație

„Deschide“ dacă aveți nevoie pentru a repara un bug

Să luăm acum în considerare ordinea fiecărei opțiuni.

Respins. În acest caz, puteți fie pariu pe soarta rapoarte de bug-uri, a schimba starea în „redescopere“ sau închide - starea „Închis“

Întârziat. raport de eroare în starea de „amâna“ poate fi tradus la statutul de „Open“, atunci când doriți să stabilească sau la statutul de „închis“, în cazul în care nu mai este necesar.

Deschis. Este în această stare, dezvoltatorul primește un raport de eroare pentru corecție. El poate respinge (a se vedea măsuri suplimentare în paragraful 1), sau să stabilească un bug. Starea raport de eroare „fix“ este transferat într-un tester pentru testare. Dacă problema este încă joacă, a seta starea de „redescoperit“ și raportul de eroare este trimis înapoi pentru revizuire la dezvoltator. Dacă fix a fost de succes, raportul de eroare este tradus în starea „Închis“.

Ne-ar dori să se constate că acest sistem a fost mult simplificată. Pentru o mai mare claritate și, probabil, gradul de utilizare pe proiect, puteți adăuga stări și tranziții suplimentare, mai ales din moment ce sistem modern de urmărire Bug vă permit să facă acest lucru. Este adevărat, în mod inutil să rețineți că sistemul complicat de tranziții și starea inutilă poate complica foarte mult viața.

Nota 1: În unele sisteme, de urmărire raport de erori bug imediat creat devine statutul de „Open“ fără o validare

Nota 2. Multe sisteme de urmărire a erorilor poate redeschide bug-uri închise, dar eu personal sunt împotriva unei astfel de practici, și, prin urmare, nu a descris o astfel de tranziție în reprezentarea de mai sus a ciclului de viață

Nota 3: Ciclul de viață de mai sus se bazează pe faptul că echipa are pe cineva care este responsabil pentru numirea rapoarte de erori. În cazul în care un astfel de rol în proiect, nu bug-uri sunt numiți de către dezvoltatorii înșiși și apoi, în scopul de a evita putannitsa, este logic să se introducă un alt statut intermediar „în dezvoltare“ (în curs), care arată că raportul de eroare a fost deja numit și se află în proces corecție. Un exemplu de implementare a unui astfel de ciclu de viață bazat pe JIRA se poate observa în figura de mai jos: