Как да дадете приоритет на дефект
Веднага отбелязвам, че горната процедура не е универсална за практическа употреба.
Какво влияе върху приоритета на грешка
Приоритетът е един от ключовите атрибути на грешка, която засяга основно:
1) Качествен показател за продукта като цяло и / или неговите компоненти. Използвайки следните свойства, е възможно да се съберат необходимите показатели, които определят показателите за качество на продукта на текущия етап от неговия жизнен цикъл: - броят на грешките със съответните приоритети; - показатели за сложността / сложността на функционалността; - статистика за разпределението на грешките по функционални модули; —времеви характеристики на процеса на тестване (например, за формализиране на нулево отпадане на грешки, замразяване на кода и т.н.); —други подобни данни.
2) Готовността на продукта на текущия етап на развитие. Въз основа на показателите за качество на продукта (вижте параграфа по-горе) могат да се формализират показатели или критерии, които определят готовността на продукта на текущия етап на развитие.
3) Готовност за завършване на тестовата работа. За да се определи този показател, са необходими индикатори за качество на продукта, които се основават на информация за приоритета на съществуващите грешки.
4) Приоритизиране на текущите задачи за развитие. В зависимост от профила на текущите грешки (техния приоритет и количество спрямо съществуващите ресурси), е необходимо да се коригира последователността от задачи за следващите етапи на развитие.
5) Желание за извършване на работа по приемане, демонстрации, предаване на проекта впроизводствена операция.
За различните модели на разработка (аутсорсинг, продукт, на свободна практика) подходите за приоритизиране на грешки ще се различават значително, както и степента на тяхното действително въздействие върху ключовите аспекти на разработката, изброени по-горе. Това влияние ще бъде обсъдено допълнително.
Глобален приоритет
Глобалната сериозност на грешката се определя от следните компоненти:
— Сериозност — свойство на тестов артефакт, което характеризира въздействието на артефакта върху производителността на приложението. Това е характеристика, определена от гледна точка на функционалност.
- Приоритет - свойство на тестов артефакт, което влияе на реда, в който се изпълнява задача или се елиминира дефект. Това е характеристика, дефинирана от бизнес гледна точка.
- Честота (Frequency) - свойство на тестов артефакт, което характеризира честотата (%) на поява при използване на приложението от крайни потребители. Това е характеристика, дефинирана от гледна точка на потребителски сценарии за използване на продукта.
По този начин глобалният приоритет се определя въз основа на стойностите на три свойства: globalSeverity = F(Priority, Severity, Frequency).
След това разглеждаме тази зависимост по-подробно и я прецизираме.
Принципът на определяне на съставните свойства
1) Сериозност
Определя се от QA специалист, Lead QA или Team Lead след анализ на изискванията, софтуерния продукт и спецификата на конкретен проблем:
Блокер - Дефектът се отнася до критична (по отношение на здравето) функционалност или критични данни. Потребителят няма възможност да извърши целевото действие по други начини.
Примери: —Не мога да вляза,регистрирам; - Не е възможен достъп както до целевите данни, целевите раздели на приложението; —Приложението се срива в определена среда.
Критичен - Дефектът е свързан с критична (по отношение на здравето) функционалност или критични данни. Потребителят може да извърши целевото действие в заобиколно решение, но то (пътят) не е очевидно.
Примери: — Сривове на приложението; — Изключения при работа с приложението; — Функционалност, която не работи в една от средите, достъпни за потребителя; — Неоторизиран достъп до данни/функционалност.
Големи - дефектът се отнася до неприоритетна (по отношение на здравето) функционалност или неприоритетни данни. Има очевидно и лесно решение за извършване на целевата функционалност.
Примери: - Дефекти с вероятностен характер на поява; —Изключения, които не засягат резултата от целевото действие; —Проблеми, които засягат скоростта на използване на приложението и производителността на действията на целевия потребител; —Визуални несъответствия; —Грешки във важно (например продаващо) съдържание и/или графична информация.
Тривиално - Дефектът не е пряко свързан с функционалността и данните. Няма нужда от заобиколни решения за извършване на целевото действие. Не влияе на производителността, скоростта на използване на приложението.
Пример: — Малки разлики в оформлението с оформленията; — Правописни грешки в неприоритетно съдържание; —Незначителни UI, UX подобрения.
В тази техника се разглежда моделът на тежестта. В зависимост от спецификата на вашия проект или процеси могат да се използват алтернативни модели. Например този модел на сериозност може да бъде разширеннива на градация като средно (нормално) и второстепенно.
2) Приоритет
Определя се от ръководителя на проекта (PM / PO) въз основа на въздействието на проблема върху бизнес целите / целите на софтуерния продукт:
- Висок (High): Дефектът трябва да бъде отстранен възможно най-скоро, тъй като засяга най-критичната за бизнеса функционалност.
- Среден (Среден): дефектът трябва да бъде отстранен, тъй като засяга функционалност, която е важна от бизнес гледна точка. Корекцията обаче може да се забави до следващите етапи/спринтове на разработка.
— Ниско (Low): Не се изисква дефектът да бъде коригиран, тъй като не засяга критичната за бизнеса функционалност и корекцията му може да бъде отложена, докато не станат налични ресурси.
3) Честота
Определя се от маркетинг специалист или клиент на проекта въз основа на анализ на поведенческите модели на крайните потребители:
- Висока: Повече от 80% от крайните потребители изпитват проблема.
- Средно: по-малко от 80%, но повече от 30% от крайните потребители изпитват проблема.
- Ниска: по-малко от 30%, но повече от 10% от крайните потребители изпитват проблем.
- Много ниско: По-малко от 10% от крайните потребители изпитват проблема.
Алгоритъм за определяне на глобалния приоритет
Честотата (Frequency) на проблема пряко влияе върху приоритета. Приоритетът (Priority) и сериозността (Severity) пряко засягат глобалния приоритет (Global Severity) на дефекта: globalSeverity = F(Priority, Severity) , където Priority = F(BasePriority, Frequency) . Глобалният приоритет (globalSeverity) се определя от следния алгоритъм:
1. Първоначално изолирани от други фактори, ние определяметежест на дефекта (блокиращ, критичен, незначителен, тривиален).
2. Независимо от тежестта, ние определяме приоритета на дефекта (висок, среден, нисък).
3. Независимо от тежестта и приоритета, ние определяме честотата на дефекта (Висока, Средна, Ниска, Много ниска).
4. След това изчисляваме ефекта на честотата върху първоначално дефинирания приоритет:
| Честота | Промяна на приоритета |
| Високо | Средно-> Високо Ниско -> Среден |
| Среден | Ниско-> Среден |
| ниско | не се променя |
| Много ниско | не се променя |
5. Накрая изчисляваме глобалния приоритет:
| Приоритет/сериозност | Блокатор | Критично | Незначителен | Тривиално |
| Високо | Критичен | Критичен | Незначителен | Тривиално |
| Среден | Критичен | Критичен | Незначителен | Тривиално |
| Нисък | Тривиално | Тривиално |
- Критично - трябва да се коригира. Доставката на проекта не е възможна при наличието на тези дефекти - Незначителни - допустими в малък размер. Не е желателно предаването на проекта при наличието на тези дефекти, но е възможно при наличието на някои от тях - Тривиално - предаването на проекта е възможно при наличието на тези дефекти.
Процедура за определяне на критерии за приемане
Традиционно в различните методологии за управление на проекти има понятия Критерии за приемане и Критерии за готовост – както за продукта като цяло, така и за отделните му версии. Работа с доклад за грешка като документ, съдържащ основна информация за качествените характеристики на софтуерапродукт, той е на финалния етап на итерация (спринт, крайъгълен камък и т.н.), което е от особено значение: - Критериите за приемане са основата за писане на тестови сценарии (контролни списъци, тестови случаи, сценарии от край до край и т.н.); - Готовите критерии активно използват доклади за грешки, за да формират оценка, която характеризира степента на съответствие на продукта с предварително посочени изисквания.
В методологията за приоритизиране на дефекти, описана по-горе, е предоставен основен теоретичен модел. Очевидно е, че в ясен вид той не е подходящ за практическо приложение и трябва да се разглежда като основа за изграждане на най-подходящото приложно решение за конкретен проект.
Основната цел на този модел е да покаже, че приоритизирането на грешки зависи от доста голям брой фактори. И, например, подходът за класиране на потенциални и съществуващи проблеми в проект за SaaS продуктов формат в областта на електронната търговия трябва да бъде различен от подхода в аутсорсинг проект за разширяване или подкрепа на съществуващия бизнес на клиента. Така че за първия проект факторите на маркетинговия компонент при приоритизирането на проблемите ще имат значително по-голяма тежест, отколкото за втория проект.