Bug Life Cycle

Bug Life Cycle

Bug Life Cycle-ը Bug-ի կարգավիճակների հատուկ հաջորդականություն է, որն անցնում է Bug-ը իր գոյության ընթացքում: Bug Life Cycle-ի նպատակը դեֆեկտի ընթացիկ ստատուսը հեշտ համակարգելն ու հաղորդելն է:
Ստատուսը դեֆեկտի ընթացիկ կարգավիճակն է: Ստատուսի նպատակը դեֆեկտի ընթացիկ վիճակը կամ առաջընթացը ճշգրիտ փոխանցելն է՝ առաջընթացին ավելի լավ հետեւելու եւ հասկանալու համար:
Դեֆեկտի ստատուսների թիվը պրոյեկտից պրոյեկտ փոխվում է: Ներքեւում բերված դիագրամը նկարագրում է դեֆեկտի բոլոր հնարավոր կարգավիճակները:


1.New :Երբ tester-ը գտնում է սխալ, ասում ենք, որ բացվել է bug , որի status = new:
2.Assign:Bug-ը հայտնաբերված է, team lead-ը պետք է հաստատի Bug-ը ուղարկի development team-ին ուղղելու համար՝ status=assign, սակայն մինչեւ ուղարկելը պետք է որոշի Bug-ի առաջնահերթության աստիճանը(priority):
3.Open:Developer-ը սկսում է վերլուծել եւ աշխատել Bug-ն ուղղելու վրա: Սա իր հերթին կարող է լինել Duplicate, այսինքն` tester-ը լավ չի նայել արդեն բացված bug-երը եւ իր բացած bug-ը համընկնում է արդեն հայտնաբերված մեկ այլ bug-ի հետ, այս դեպքում bug-ը փակվում է՝ Closed:
Այն դեպքում, երբ PM-ը վերլուծում է bug-ը եւ ասում, որ դա իրականում bug չի ՝ status = Rejected => Closed: Իսկ եթե bug-ն ուղղելու համար չկան համապատասխան ռեսուրսներ, կամ տվյալ bug-ի առաջնահերթությունը ցածր է, ապա status=Deffered եւ bug-ը հետաձգվում է մինչեւ հաջորդ Release-ը ` status= Next Release:
Developer-ն, ով աշխատում է bug-ի վրա ստատուսը դնում է in_progress:
4.Pending retest:Երբ defect-ը շտկվում է, մշակողը տալիս է հատուկ կոդ՝ ծածկագիրը վերստուգելու համար փորձարկողին:
5.Retest:այս փուլում փորձարկողն իրականացնում է կոդի վերստուգում՝ ստուգելու՝ արդյոք թերությունը շտկված է մշակողի կողմից, թե ոչ, և կարգավիճակը փոխում է «re-test»։
6.Checked:Թեստավորողը նորից փորձարկում է bug-ը developer-ի կողմից այն շտկելուց հետո։ Եթե software-ի մեջ սխալ չի հայտնաբերվել, ապա bug-ը շտկվում է, և նշանակված կարգավիճակը «verified»:
7.Reopen:Եթե bug-ը պահպանվում է նույնիսկ այն բանից հետո, երբ developer-ը շտկել է bug-ը, թեստավորողը փոխում է կարգավիճակը «reopened»: Կրկին bug-ը անցնում է life cycle:
8.Closed:Եթե bug-ը այլևս գոյություն չունի, փորձարկողը վերագրում է «closed» կարգավիճակը:
9.Dublicate:Եթե defect-ը կրկնվում է երկու անգամ կամ համապատասխանում է bug-ի նույն հասկացությանը, կարգավիճակը փոխվում է «dublicate»:
10.Reject:Եթե developer-ը զգում է, որ defect-ը իրական defect չէ, ապա այն փոխվում է «rejected»:
11.Deffered:Եթե ներկա bug-ը առաջնահերթություն չէ, և եթե ակնկալվում է, որ այն կշտկվի հաջորդ անգամ, ապա փոխվում է «Deffered»։
12.Not a bug:Եթե դա չի ազդում հավելվածի ֆունկցիոնալության վրա, ապա bug-ին վերագրված կարգավիճակը «not a bug»:

1.Թեստավորողը գտնում է defect-ը
2.Status-ը տրված է defect- New
3.Defect-ը փոխանցվում է Ծրագրի ղեկավարին վերլուծության համար
4.Ծրագրի ղեկավարը որոշում է, թե արդյոք թերությունը վավեր է
5.Այստեղ թերությունը վավեր չէ. կարգավիճակը տրվում է «Մերժված է»:
6.Այսպիսով, ծրագրի ղեկավարը նշանակում է rejected status: Եթե defect-ը չի մերժվում, ապա հաջորդ քայլը ստուգելն է, թե արդյոք այն իր շրջանակում է: Ենթադրենք, մենք ունենք մեկ այլ գործառույթ՝ էլփոստի 7.գործառույթ նույն հավելվածի համար, և դուք դրա հետ կապված խնդիր եք գտնում: Բայց դա ընթացիկ թողարկման մաս չէ, երբ այդպիսի թերություններ կան
8.նշանակվել է որպես հետաձգված կամ հետաձգված կարգավիճակ:
9.Հաջորդը, մենեջերը ստուգում է, թե արդյոք նախկինում նման թերություն է առաջացել: Եթե այո, թերությունը նշանակվում է կարգավիճակի կրկնօրինակ:
10.Եթե ոչ, թերությունը վերագրված է developer-ին, ով սկսում է շտկել կոդը: Այս փուլում թերությանը վերագրվում է ընթացքի կարգավիճակ:
11.Երբ կոդը ամրագրվի: Թերությանը վերագրվում է ֆիքսված կարգավիճակ
12.Հաջորդը, փորձարկողը նորից կփորձարկի կոդը: Փորձարկման գործն անցնելու դեպքում թերությունը փակվում է: Եթե փորձարկման դեպքերը կրկին ձախողվեն, ապա թերությունը կրկին բացվում է և վերագրվում է մշակողին:
13.Դիտարկենք մի իրավիճակ, երբ Թռիչքի ամրագրման 1-ին թողարկման ժամանակ ֆաքսի պատվերում թերություն է հայտնաբերվել, որը շտկվել է և նշանակվել է փակված կարգավիճակ: Երկրորդ 14.արդիականացման ժամանակ նույն թերությունը նորից հայտնվեց: Նման դեպքերում փակ թերությունը նորից կբացվի։

Օգտակար հղումներ՝

Defect/Bug life cycle article/eng
Bug life cycle video tutorial/eng
Bug life cycle video tutorial/rus