Тежест и приоритет при тестване, с примери от реалния живот
Реших да споделя наблюденията си относно сериозността и приоритета в доклади за грешки. Смешно е, но има малко места, където можете да намерите Приоритет, всеки някак заобикаля сериозността и пропуска приоритета. Затова исках да ви разкажа за някои примери от реалния живот, където и в какви ситуации можете да използвате „Тежест“ и „Приоритет“ в отчетите за грешки.
Какво е сериозност и приоритет?
Тежест Дали степента, до която дефектът ще се отрази негативно на продукта. Излага тестер, показва ефекта на дефекта върху работата на приложението.
Градиране на тежестта на дефектите
- S1 Blocker - тестването е блокирано -
- S2 Критично - важна функция не работи
- S3 Major - по-малко важна функция не работи
- S4 Minor - проблемът е незначителен
- S5 Trivial - козметични редакции
Приоритет Редът, в който дефектите трябва да бъдат коригирани Определя се от развитието и бизнеса (показва се от програмисти, PM, TeamLead на проекта). Колкото по-висок е приоритетът, толкова по-скоро дефектът трябва да бъде коригиран.
Дипломиране с приоритет на дефекти
- P1 Високо - поправете незабавно
- P2 Среден - по късно
- P3 Ниско - през следващите пет години
Често при проследяването на грешки се използва само сериозност, което не е много правилно, тъй като по време на анализа на времето и времето за развитие от бизнеса, грешките от сериозност - „Майор“ могат да отидат на „Критично“ или дори „Блокиране“, но всъщност не са. Например, печатна грешка може да се превърне в блокираща поради скорошния продукт. Въпреки че е достатъчно да въведете приоритет и да зададете такава грешка на най-висок приоритет преди пускането.
Защо си струва да приложите Приоритет?
В докладите за грешки според тежестта тестващият може да анализира къде и колко плачевна е ситуацията за продукта. Да кажем, ако има куп грешки с висока сериозност - това е индикатор, че нещо се обърква. Но ако куп грешки с висок приоритет (Приоритет) не означава, че всичко е лошо в продукта. Почувствай разликата?
Ако имате незначителни грешки - те са блокиращи поради факта, че бизнес процесите изискват това - картината е значително изкривена, оказва се, че се крие в проследяването на грешки. Затова считам, че приоритетът трябва да бъде въведен в проектите, както и да се прави разлика между Тежест и Приоритет.