Defect Severity and Priority

Defect Severity and Priority

Severity-ն թեստավորման ենթակա app-ի ֆունկցիոնալության վրա bug-ի ազդեցության աստիճանն է: Tester-ը հիմնվելով test case-ի եւ requirement-ների իմացության վրա, որոշում է Severity-ի տիպը:
Priority-ն սահմանվում է որպես կարգ, ըստ որի պետք է bug-ը ֆիքսվի: Bug-ը, որը software system-ը դարձնում է անօգտագործելի, ունի ավելի բարձր առաջնահերթություն, քան նրանք, որոնց դեպքում software-ի ձախողվելու հավանականությունը փոքր է: Որքան բարձր է Priority-ն, այնքան ավելի շուտ է ֆիքսվում Bug-ը: Որոշում է manager-ը կամ client-ը:

Severity Levels
Blocker– Այս Bug-ը առաջացնում է app-ի ամբողջական խափանում, եւ tester-ը չի կարողանում այլեւս առաջ գնալ : Միշտ ունի high priority:
Critical – Մասամբ խափանում է app-ի աշխատանքը: Այսինքն user-ը դեռ կարողանում է որոշ ֆունկցիաներից օգտվել կամ նույն սցենարը հնարավոր է այլ կերպ իրականացնել: Միշտ ունի high priority:
Major- Այս դեպքում համակարգը չի խափանվում, բայց առաջանում է որոշակի անցանկալի վարքագիծ: Այս bug-երը հավասարապես կարեւոր են եւ պետք է ուղղվեն առանց հետաձգելու:
Minor & Trivial– Նշանակալի վնաս չեն պատճառում համակարգին: Կարող են լինել UI փոքր խնդիրներ, ուղղագրական սխալներ, հավասարեցման, գույների հետ կապված խնդիրներ, որոնք ֆունկցիոնալության վրա ոչ մի ազդեցություն չունեն:


Priority Levels
High (P1) - Սխալը պետք է ուղղվի հնարավորինս շուտ, քանի որ համակարգը չի կարող օգտագործվել մինչեւ ուղղվելը:
Medium (P2) – P1 Priority ունեցող դեֆեկտներից հետո, պետք է ուղղվեն P2-ները: Նման խնդիրները չեն խանգարում հետագա թեստավորմանը:
Low (P3) – Կուղղվի միայն առավել լուրջ սխալներ ուղղելուց հետո:


Severity-ին որոշելու տարբերակներ

Որոշել bug-ի հաճախականությունը. Որոշ դեպքերում այն փոքր խնդիրները, որոնք հաճախ են կրկնվում, ավելի լուրջ կարող են լինել:
bug-ի առանձնացում. bug-ն առանձնացնելը կարող է օգնել դրա ազդեցությունը պարզելու հարցում:

Օրինակներ

Scenarion 1: High priority and blocker severity

1.Շատ տարածված օրինակ՝ Օգտվողը չի կարողանում մուտք գործել հավելված՝ համապատասխան հավատարմագրերով: Սա շատ կարևոր սցենար է, որը պետք է հնարավորինս արագ շտկվի։
2.Էլեկտրոնային առևտրի կայքէջում օգտատերը չի կարող ապրանքը ավելացնել զամբյուղի մեջ / չի կարող դուրս գալ զամբյուղից վճարման համար: Եթե տեղի է ունեցել իրական հավելվածում, այս խնդիրը կարող է մեծ մակարդակով ազդել բիզնեսի վրա:
3.Գրանցվելուց հետո օգտվողը չի ստանում հղումը գրանցման գործընթացը ավարտելու համար:
4.Համակարգը խափանում է, երբ որոնման վանդակում տրամադրվում են անվավեր հիմնաբառեր (օրինակ՝ XSS սկրիպտներ):

Scenario 2: Low priority and low severity

1.Ուղղագրական փոքր սխալներ այնպիսի էջերում, ինչպիսիք են «Կայքի քարտեզ», «Կարիերա» կամ «Ընկերության բլոգ» էջերը:
2.«Մեր մասին» էջի կոճակի գույնը մի փոքր այլ է:
3.Ընկերության բլոգների էջի բովանդակության հետ հավասարեցման աննշան խնդիրներ:

Scenario 3: High priority and low severity

1.Շատ տարածված օրինակ՝ «Ընկերության լոգոն» չի ցուցադրվում այնպես, ինչպես սպասվում էր: Այս թերությունը չի ազդում որևէ ֆունկցիոնալ սցենարի վրա, բայց կարող է ազդել ընկերության ապրանքանիշի արժեքի վրա: Այնպես որ, այս խնդիրը պետք է լուծվի առանց ուշացման։

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

Defect severity and priority article/eng
Defect severity and priority article/rus
Defect severity and priority video tutorial/eng
Defect severity and priority video tutorial/rus