Серйозність та пріоритет Дефекту (Severity & Priority)

Bug management включає процес документування, категоризації, призначення, відтворення, виправлення і випуску виправленого коду. Пропоновані зміни у програмному забезпеченні - баги, запити на поліпшення і навіть цілі - зазвичай відстежуються та керуються за допомогою баг-трекінгових систем. Додані елементи можуть називатися дефектами, заявками, проблемами або, відповідно до парадигми гнучкої розробки, епіками та сторями (stories and epics). Категорії можуть бути об'єктивними, суб'єктивними або комбінованими, такими як номер версії, область програмного забезпечення, серйозність та пріоритет, а також тип проблеми, такий як фіча-реквест або баг.

Критичність (severity): Важливість впливу конкретного дефекту на розробку чи функціонування компонента чи системи. (IEEE 610)

Пріоритет: Ступінь важливості, що присвоюється об'єкту. Наприклад, дефект. (ISTQB)

Інакше кажучи, серйозність представляє технічний вплив помилки у тих працездатності самого ПЗ, а пріоритет свідчить про черговість виконання завдання чи усунення дефекту, тобто. погляд бізнесу. Пріоритет виставляється будь-якими business stakeholders, включаючи project managers, business analysts, product owner, а серйозність сам тестувальник (або у складних випадках той, хто краще розуміється). Розробник бере таски виходячи з пріоритету.

Градація Серйозності (Severity):

Критична (critical) – існування дефекту призводить до масштабних наслідків катастрофічного характеру, наприклад: втрата даних, розкриття конфіденційної інформації, порушення ключової функціональності програми тощо;
Висока (major) - існування дефекту приносить відчутні незручності багатьом користувачам у межах їх типової діяльності, наприклад: недоступність вставки з буфера обміну, непрацездатність загальноприйнятих клавіатурних комбінацій, необхідність перезапуску програми під час виконання типових сценаріїв роботи;
Середнє (medium) - існування дефекту слабко впливає типові сценарії роботи користувачів, та/або існує обхідний шлях досягнення мети, наприклад: діалогове вікно не закривається автоматично після натискання кнопок «OK»/«Cancel», при роздруківці кількох документів поспіль не зберігається значення поля «Двосторонній друк», переплутані напрями сортувань за полем таблиці;
Низька (minor) - існування дефекту рідко виявляється незначним відсотком користувачів і (майже) не впливає на їх роботу, наприклад: друкарська помилка в глибоко вкладеному пункті меню налаштувань, якесь вікно відразу при відображенні розташоване незручно (потрібно перетягнути його в зручне місце), неточно відображається час до завершення копіювання файлів.

Градація терміновості/пріоритету (Priority):

Найвища (ASAP, as soon as possible) терміновість вказує на необхідність усунути дефект настільки швидко, наскільки це можливо. Залежно від контексту «настільки швидко, наскільки можливо» може змінюватись від «у найближчому білді» до одиниць хвилин;
Висока (high) терміновість означає, що дефект слід виправити позачергово, т.к. його існування або вже об'єктивно заважає роботі, або почне створювати такі перешкоди у найближчому майбутньому;
Нормальна терміновість означає, що дефект слід виправити в порядку загальної черговості. Таке значення терміновості набуває більшість дефектів;
Низька (low) терміновість означає, що в найближчому майбутньому виправлення даного дефекту не вплине на підвищення якості продукту.

Поєднання Severity та Priority

High Priority and High Severity : Будь-який Critical/major збій бізнес-моделі, критична проблема, при якій повністю не працює більша частина функціональності або основний компонент системи:
- натискання на певну кнопку не запускає саму функцію, наприклад, не працює кнопка відправки на сторінці входу, і клієнти не можуть увійти до програми;
- виконання певної функції постійно призводить до помилки 500 сервера і втрати даних;
- система дає збій після того, як ви здійснили платіж або коли ви не можете додати товари до кошика;
- функція банкомату, коли після введення правильного імені користувача та пароля автомат не видає гроші, але списує їх з вашого рахунку;
- на веб-сайті банку з'являється повідомлення про помилку, коли клієнт натискає кнопку переказу грошей.
High Priority and Low Severity : Будь-які minor severity дефекти, які впливають на взаємодію користувача / репутацію:
- очікується, що функція покаже користувачеві конкретну помилку за кодом відповіді. У цьому випадку функціонально код видає помилку, але повідомлення має бути більш релевантним коду;
- помилка в логотипі або назві компанії на головній сторінці, або помилки, що впадають у вічі і здатні вплинути на репутацію компанії;
- друкарські помилки в контактних даних;
- важливі помилки в угодах та юридичних документах.
Low Priority and High Severity : Проблема, яка поки що не вплине на бізнес, але має великий вплив з точки зору функціональності:
- є серйозний баг, але є workaround і виправлення вже може бути заплановане в наступному релізі або функція буде видалена;
- функція генерації річного звіту, яка буде використана лише за півроку;
- рідкість прояви дефекту/сложность відтворення для користувачів.
Low Priority and Low Severity : Будь-які орфографічні помилки/накреслення/розбіжність шрифту в абзаці 3-ї або 4-ї сторінки заявки, а не на головній або титульній сторінці/заголовку. Ці дефекти виникають, коли це не впливає на функціональність, але все ж таки невеликою мірою не відповідає стандартам. Зазвичай сюди класифікуються косметичні помилки або, скажімо, розміри комірки в таблиці інтерфейсу користувача:
- у політиці конфіденційності веб-сайту є орфографічна помилка;
- сторінка часто задаваних питань завантажується дуже довго;
- сімейство шрифтів, розмір шрифту, колір або орфографічна помилка у додатку чи звітах.

Джерела:

Дод. матеріал:

PreviousДефекти та помилки NextАльфа- та бета-тестування (Alpha Testing and Beta Testing)

Last updated 2 years ago