Тестване

Раздел: Тестване> Тестови артефакти> Доклад за грешки> Тежест и приоритет на дефектите

Различните системи за проследяване на грешки ни предлагат различни начини да опишем тежестта и приоритета на доклад за грешка, само значението на тези полета остава непроменено. Всички познават програма за проследяване на грешки като Atlassian JIRA. В него, като се започне от някаква версия, вместо да се използват едновременно полетата Severity и Priority, е оставен само Priority, който събира свойствата и на двете полета: Първоначално JIRA наистина има и поле за приоритет и сериозност. Полето за сериозност беше премахнато по ред причини. По този начин тези, които са свикнали да работят с JIRA, не винаги разбират разликата между тези понятия, тъй като не са имали опит да ги използват заедно. Въз основа на личния опит настоявам за разделянето на тези понятия, или по-скоро върху използването както на полетата за тежест, така и за приоритет, тъй като значението, вложено в тях, е различно:

Сериозност (Тежест) е атрибут, който характеризира въздействието на дефект върху работата на приложението.

Приоритет (Приоритет) е атрибут, указващ реда, в който дадена задача се изпълнява или дефектът е разрешен. Може да се каже, че това е инструмент на мениджъра за планиране на работа. Колкото по-висок е приоритетът, толкова по-бързо дефектът трябва да бъде отстранен.

Градиране на тежестта на дефектите

S1 Blocker
Блокираща грешка, която прави приложението неработещо, в резултат на което по-нататъшната работа с тестваната система или нейните ключови функции става невъзможна. Решаването на проблема е необходимо за по-нататъшното функциониране на системата.

S2 Критично
Критична грешка, неправилно работеща ключова бизнес логика, дупка в сигурността, проблем, довел до временен срив на сървъра или направил част от системата неработеща, без възможност за разрешаване на проблема с помощта на други входни точки. Решението на проблема е необходимо за по-нататъшна работа с ключовите функции на тестваната система.

S3 Major
Значителна грешка, част от основната бизнес логика не работи правилно. Грешката не е критична или е възможно да се работи с тестваната функция, като се използват различни входни точки.

S4 Minor
Незначителна грешка, която не нарушава бизнес логиката на тестваната част на приложението, очевиден проблем на потребителския интерфейс.

S5 Trivial
Тривиална грешка, която не касае бизнес логиката на приложението, слабо възпроизводим проблем, който трудно се забелязва чрез потребителския интерфейс, проблем с библиотеки или услуги на трети страни, проблем, който не оказва никакво влияние върху цялостното качество на продуктът.

Дипломиране с приоритет на дефекти

P1 Високо
Грешката трябва да бъде отстранена възможно най-скоро, тъй като присъствието му е критично за проекта.

P2 Среден
Грешката трябва да бъде коригирана, нейното присъствие не е критично, но изисква задължително решение.

P3 Ниско
Грешката трябва да бъде поправена, нейното присъствие не е критично и не изисква спешно решение.

Редът на коригиране на грешките по техния приоритет:

Висока -> Средна -> Ниска

Изисквания за броя на отворените грешки

Бихме искали да ви предложим следния подход за определяне на изискванията за броя на отворените грешки:

  • Наличието на отворени дефекти P1, P2 и S1, S2 се счита за неприемливо за проекта. Всички подобни ситуации изискват спешни решения и преминават под контрола на ръководителите на проекти.
  • Наличието на строго ограничен брой отворени грешки P3 и S3, S4, S5 не е критично за проекта и е разрешено в издаденото приложение. Броят на отворените бъгове зависи от размера на проекта и установените критерии за качество.

Всички изисквания за отворени грешки се договарят и документират на етапа на вземане на решение относно качеството на разработвания продукт. Като пример за документиране на такива изисквания това са критериите за край на теста в план за тестване.