Найти в Дзене
Будни тестировщика

Серьезность.

Связанным с полем "Влияние" является поле "Серьезность", которое содержит начальное впечатление сообщающего о дефекте о том, насколько серьезна проблема. Это может быть описано либо в качественном отношении (т. е. "Это реально, реально плохо. Реально, реально, реально плохо" или "Если честно, это совсем не проблема"), либо при помощи стандартизованной шкалы количественно. Последнее гораздо популярнее, но обычно у каждой организации имеется свой подход. Это может быть нечто совсем простое вроде цифровой шкалы, где "1" означает очень незначительную мелочь, а "10" оказывается непреодолимой проблемой. Однако часто встречаются градации с дескрипторами. Пример подобной системы оценок приведен ниже. 1. Блокер. Дефект настолько серьезный, что система не может быть выпущена без его исправления или разработки обходного пути. Примерами дефектов-блокеров могут стать ситуации, когда система не позволяет пользователю авторизоваться или же прекращает работу, когда кто-то нажимает клавишу . 2. Критиче

Связанным с полем "Влияние" является поле "Серьезность", которое содержит начальное впечатление сообщающего о дефекте о том, насколько серьезна проблема. Это может быть описано либо в качественном отношении (т. е. "Это реально, реально плохо. Реально, реально, реально плохо" или "Если честно, это совсем не проблема"), либо при помощи стандартизованной шкалы количественно. Последнее гораздо популярнее, но обычно у каждой организации имеется свой подход. Это может быть нечто совсем простое вроде цифровой шкалы, где "1" означает очень незначительную мелочь, а "10" оказывается непреодолимой проблемой. Однако часто встречаются градации с дескрипторами.

Пример подобной системы оценок приведен ниже.

1. Блокер. Дефект настолько серьезный, что система не может быть выпущена без его исправления или разработки обходного пути. Примерами дефектов-блокеров могут стать ситуации, когда система не позволяет пользователю авторизоваться или же прекращает работу, когда кто-то нажимает клавишу .

2. Критический. Хотя система может быть выпущена с дефектом подобной величины, он оказывает серьезное влияние на основную функциональность программы или делает ее практически непригодной к использованию. Другими словами, дефект, который мог бы быть помечен как блокер, но для которого существует какое-то решение, может быть классифицирован как критический.

3. Значительный. Это дефект, который вызывает относительно серьезные проблемы, хотя и не настолько серьезные, чтобы полностью остановить систему. Весьма вероятно, что пользователь заметит дефект, работая с той частью программы, где этот дефект присутствует.

4. Обычный. Это дефект, который доставляет неудобства пользователю, или же более серьезный дефект с простым и понятным решением.

5. Незначительный. Этот дефект может быть замечен, а может нет, и при этом не вызывает больших проблем для пользователя, или же для него существует простое и понятное решение.

6. Тривиальный. Этот дефект, вероятно, даже не заметят до тех пор, пока его не начнут искать специально. Примером может быть опечатка в большом блоке текста.

7. Улучшение. Иногда этот дефект даже и не является дефектом. Это нечто, что хочет пользователь, но при этом не определенное требованиями, или то, что не вписывается в рамки текущего проекта. В этом случае дефект может быть оформлен как улучшение. Другой вариант — пользователь может подумать, что проблема является дефектом, но менеджмент отклонит это предложение и отметит его как улучшение.

Оценка серьезности дефекта зачастую является скорее искусством, чем наукой, хотя существует некоторая эвристика для определения того, насколько серьезна проблема. В зависимости от области работы тестировщика ПО, а также внутренних правил тестирования в его организации, серьезность дефекта может кардинально отличаться. Даже в рамках одной организации могут быть конфликты между инженерами, менеджерами, тестировщиками и прочими заинтересованными лицами по поводу того, насколько серьезен дефект.

Серьезность не должна быть принята за приоритет. Серьезность говорит о том, насколько серьезна проблема, в то время как приоритет определяет порядок, в котором организация хотела бы видеть исправление проблемы. Например, у опечатки на главной странице веб-приложения низкая серьезность, т. к. она не оказывает влияния на функциональность программы. Тем не менее это создает плохое впечатление о создавшей приложение компании, и для исправления потребуется совсем немного времени разработчика. В этом случае приоритет может быть очень высоким. С другой стороны, у дефекта может быть низкий приоритет, но высокая серьезность. В качестве примера можно привести проблему с производительностью чтения информации из базы данных, которая оказывается настолько низкой, что делает систему практически непригодной к использованию после получаса работы. Это очень серьезная проблема. Однако на ее исправление уйдет много времени, а оптимизация базы данных уже запланирована по ходу проекта, и поэтому у проблемы будет низкий приоритет. Но при прочих равных условиях обычно дефекты высокой серьезности имеют более высокий приоритет, чем дефекты более низкой серьезности.