Про Тестинг - Тестування - Баг репорт - Серйозність та Пріоритет Бага чи Дефекту
Розділ: Тестування > Тестові Артефакти > Баг Репорт > Серйозність та Пріоритет Дефекту
Серйозність та Пріоритет Дефекту
Різні системи баг трекінгу пропонують нам різні шляхи опису серйозності та пріоритету баг репорту, незмінним залишається лише сенс, що вкладається ці поля. Усі знають такий баг-трекер, як Atlassian JIRA. У ньому, починаючи з якоїсь версії замість одночасного використання полів Severity та Priority, залишили лише Priority, яке зібрало в собі властивості обох полів: Originally, JIRA did have both a Priority and a Severity field. Severity field був вилучений для числа реазон. Таким чином, ті, хто звик працювати з JIRA, не завжди розуміють різницю між цими поняттями, оскільки не мали досвіду їх спільного використання. Виходячи з особистого досвіду, я наполягаю на розподілі цих понять, а точніше на використанні обох полів Severity і Priority, оскільки зміст, що вкладається в них, різний:
Серйозність(Severity ) - це атрибут, що характеризує вплив дефекту на працездатність програми.
Пріоритет(Priority ) - це атрибут, що вказує на черговість виконання завдання чи усунення дефекту. Можна сміливо сказати, що це інструмент менеджера з планування робіт. Що пріоритет, то швидше потрібно виправити дефект.
Градація Серйозності дефекту (Severity)
S1 Блокуюча (Blocker)Блокуюча помилка, що приводить додаток у неробочий стан, в результаті якого подальша робота з системою, що тестується, або її ключовими функціями стає неможлива. Вирішення проблеми необхідне для подальшого функціонування системи.
S2 Критична (Critical)Критична помилка, що неправильно працюєключова бізнес логіка, дірка в системі безпеки, проблема, що призвела до тимчасового падіння сервера або деяку частину системи, що призводить до неробочого стану, без можливості вирішення проблеми, використовуючи інші вхідні точки. Вирішення проблеми необхідне для подальшої роботи з ключовими функціями системою, що тестується.
S3 Значна (Major)Значна помилка, частина основної бізнес-логіки працює некоректно. Помилка не критична або є можливість для роботи з функцією, що тестується, використовуючи інші вхідні точки.
S4 Незначна (Minor)Незначна помилка, що не порушує бізнес логіку частини програми, що тестується, очевидна проблема користувальницького інтерфейсу.
S5 Тривіальна (Trivial)Тривіальна помилка, що не стосується бізнес логіки програми, погано відтворювана проблема, малопомітна за допомогою інтерфейсу користувача, проблема сторонніх бібліотек або сервісів, проблема, що не впливає на загальну якість продукту.
Градація Пріоритету дефекту (Priority)
P1 Високий (High)Помилка має бути виправлена якнайшвидше, т.к. її наявність є критичною для проекту.
P2 Середній (Medium)Помилка має бути виправлена, її наявність не критична, але вимагає обов'язкового рішення.
P3 Низький (Low)Помилка має бути виправлена, її наявність не критична, і не вимагає термінового рішення.
Порядок виправлення помилок за їх пріоритетами:
High -> Medium -> Low
Вимоги до кількості відкритих багів
Бажаємо запропонувати вам наступний підхід до визначення вимог до кількості відкритих багів:
- Наявність відкритих дефектів P1, P2 та S1, S2,вважається неприйнятним для проекту. Усі подібні ситуації потребують термінового вирішення та йдуть під контроль до менеджерів проекту.
- Наявність строго обмеженої кількості відкритих помилок P3 і S3, S4, S5 не є критичним для проекту і допускається у програмі, що видається. Кількість відкритих помилок залежить від розміру проекту та встановлених критеріїв якості.
Всі вимоги до відкритих помилок обумовлюються і документуються на етапі прийняття рішення про якість продукту, що розробляється. Як приклад документування таких вимог - це пункт Критерії закінчення тестування щодо тестування.