Software Test
КЛАССИФИКАЦИЯ БАГОВ.
Михаил Портнов. Директор Portnov Computer School.
При формальном описании проблемы среди прочего необходимо определить severity и priority этой проблемы.
Severity характеризует насколько серьезна проблема с точки зрения ущерба функциональности. Эту классификацию должен провести тестер, открывающий баг в базе данных.
Priority упорядочивает порядок, в котором баги чинятся программистом. Тестер не может и не должен вмешиваться в этот процесс. Пусть этим займется менеджер программиста. Он лучше знает кто и чем должен заниматься в его команде. В том числе, и кому придется чинить проблему.
Очень важно понимать разницу между этими двумя типами классификации и не путаться в них.
Мне довелось работать в шести софтверных компаниях - маленьких стартапах и в таких гигантах индустрии как Лотус и Борланд. С одной стороны, каждая компания имеет свои взгляды на систему классификации как по priority, так и по severity. Но, что любопытно, несмотря на различия в используемых названиях категорий и их количестве, все, что мы можем сказать о severity прекрасно умещается всего в четыре категории:
Critical - проблемы, которые не могут быть обойдены пользователем даже с помощью звонка в TechSupport. Нет возможности выкрутиться по ходу дела и завершить работу. Отсутствует workaround. Другое часто встречающееся название для этой группы - fatal. К этой категории относятся все проблемы, ведущие к потере информации - data corruption, crash, hang (зависание системы) и проч.
Serious - серьезное функциональное нарушение, которое можно в принципе обойти и завершить выполняемую операцию.
Minor - Это то, что не мешает пользователю работать, но создает мелкие неудобства или действует на нервы. Речь не идет об усовершенствовании продукта. Мы говорим именно о ПРОБЛЕМАХ на уровне стандартов или технического задания. Сюда относятся в первую очередь проблемы user interface, но не только.
Enhancement - тут мы имеем ввиду все то, что не является нарушением техзадания, но поможет сделать продукт лучше, удобнее в пользовании. Иногда используют слово Suggestion.
Можно иметь больше, чем четыре категории, но они не добавляют особой ценности. Когда я пришел работать в Лотус, то первым делом полез в Bug Tracking System и начал пытать менеджера почему там восемь категорий и где между ними граница. Категории вообще не имели названий, а шли по номерам - 1, 2, 3 и так далее до 8. Тот "почесал репу" и сказал так "Первые три категории будут чинить, а остальные нет. Так что, используй свою интуицию и не перенапрягайся по этому вопросу". Как мы видим, категорий оказалось все равно четыре - 1, 2, 3, и все остальные.
Еще пару слов о соотношении severity и priority. Посмотрим на такую проблему:
При попытке сохранить файл выскакивает message box с вопросом "Do you really want to save that file?" Пользователь нажимает кнопочку YES, а сообщение выскакивает снова. Он опять нажимает кнопочку, но сообщение его преследует. После дясятка безуспешных попыток пользователь звонит в TechSupport и спрашивает в чем дело. Ему культурно объясняют, что это известная проблема и все что нужно - это продолжать нажимать кнопочку. И действительно - на 20-м или около того нажатии файл сохраняется. Эта проблема идет по разряду Serious а не Critical, потому, что у нее есть workaround, то есть, можно выкрутиться. С точки зрения менеджера проекта эта же проблема получит priority High (считаем, что у нас есть high, medium, low), потому что с такими проблемами компания станет всеобщим посмешищем.
Таким образом, к самому высокому уровню priority может вполне относиться проблема с не самым высоким уровнем severity. И наоборот, какой-нибудь экзотический crash, на который в реальной жизни крайне сложно наткнуться, может иметь относительно низкий приоритет в починке по сравнению с проблемой в интерфейсе, которая мгновенно бросается в глаза.
