Одним из основных критериев для оценки выпущенного программного продукта является его качество. Качество фактически показывает насколько хорошо программисты и тестировщики справились со своей задачей и насколько выпущенный продукт готов к реальному использованию.
К сожалению, по ряду причин выпущенные продукты всегда содержат не обнаруженные на этапе тестирования/разработки дефекты. В большинстве своем они проявляются в результате неучтенных ранее вариантов использования, не предусмотренных вариантов использования, конфликтов с другими программными продуктами в рабочей среде. Кроме того ошибки могут быть результатом плохой работы Quality Assurance отдела или разгильдяйства разработчиков.
В связи с этим встает вопрос как оценить качество продукта и понять насколько хорошо комманда разрабатывающая продукт сделала свою работу.
Мы поставили перед собой задачу подсчета числового выражения общего качества сданной системы и как результат разработали систему подсчет числа ( Quality Score ), которое однозначно определяло бы насколько команда хорошо справилась со своей работой.
Традиционно ошибки в системах учета ( bug track system ) делятся на категории:
Critical
Ошибка которая не позволяет использовать некоторую функциональность системы и не может быть нивелирована с помощью изменения настроек или других действий пользователя
Major
Ошибка которая затрудняет использование системы но которая может быть нивелирована путем изменения настроек или использования альтернативного сценария работы
Minor
Ошибка которая затрудняет использование системы но фактически не влияет на способ работы
Trivial
Ошибка которая фактически не влияет на использование функции системы но отражается на общем качестве. Например орфографические ошибки или ошибки оформления.
На первый взгляд кажется возможным для подсчета QS просто подсчитать количество всех найденных ошибок. Но используя такой метод мы рискуем получить устрашающие цифры для в целом достаточно хорошего продукта. Это может произойти в силу того что большинство ошибок ( даже имещих статус Critical и Major ) не будут мешать повседневному использованию продукта большинством пользователей.
Как пример можно посмотреть на публичный bug tracker Skype ( jira.skype.com ). На момент написания там была следующая картина:
Critical — 242
Major — 151
То есть в целом при устрашающих цифрах мы имеем вполне работоспособный продукт который без особых проблем используют миллионы людей.
С другой стороны возможна ситуация когда наличие даже одной ошибки со статусом Critical ( например сбой в процессе инсталляции ) сделает использование системы полностью не возможным.
В результате вышеизложенных размышлений мы решили создать дополнительную классификацию ошибок в соотвествии с тем при каком сценарии использования она проявляется:
Стандартный сценарий использования:
Сценарий использования который был предусмотрен при создания системы.
В свою очередь все стандартные сценарии так же классифицируются как:
— Базовые сценарии
— Второстепенные сценарии
— Редкие сценарии
Нестандартный сценарий использования:
Сценарий который не был предусмотрен на этапе разработки/тестирования.
В свою очередь делятся на:
— Вариант нормального использования
— Вариант не нормального использования
Сценарий который не был предусмотрен и который не может считаться нормальным способом использования системы.
Каждому типу варианта использования и каждой категории ошибки присваивается определенный коэффициент.
Базовый сценарий
Стандартный 12
Не стандартный 4
Второстепенный сценарий
Стандартный 11
Не стандартный 3
Редкий сценарий
Стандартный 10
Не стандартный 2
Сценарий не нормального
использования 1
Critical 20
Major 10
Minor 5
Trivial 2
Коэффициент для конкретного дефекта подсчитывается как коэффициент категории сценария в котором произошла ошибка на коэффициент серьезности ошибки.
Результирующий коэффициент считается как сумма коэффициентов для всех ошибок.
Как результат мы имеем QS определяющий качество системы. Меньшие значения — большее качество. Идеально качество — 0.
Пример:
— Система с 2 Crtitical дефектами в стандартных базовых сценариях использования и 2
Major дефектами в ненормальніх вариантах использования будет иметь
QS = 500 ( 2 * 20 * 12 + 2* 10 * 1 )
— Система с 1 Major дефктом в нестандартном второстепенном варианте использования и 2 Trivial дефектами в стандартных редких вариантах использования будет иметь QS = 70 ( 1 * 10 * 3 + 2 * 2 * 10 )
К сожалению, по ряду причин выпущенные продукты всегда содержат не обнаруженные на этапе тестирования/разработки дефекты. В большинстве своем они проявляются в результате неучтенных ранее вариантов использования, не предусмотренных вариантов использования, конфликтов с другими программными продуктами в рабочей среде. Кроме того ошибки могут быть результатом плохой работы Quality Assurance отдела или разгильдяйства разработчиков.
В связи с этим встает вопрос как оценить качество продукта и понять насколько хорошо комманда разрабатывающая продукт сделала свою работу.
Мы поставили перед собой задачу подсчета числового выражения общего качества сданной системы и как результат разработали систему подсчет числа ( Quality Score ), которое однозначно определяло бы насколько команда хорошо справилась со своей работой.
Традиционно ошибки в системах учета ( bug track system ) делятся на категории:
Critical
Ошибка которая не позволяет использовать некоторую функциональность системы и не может быть нивелирована с помощью изменения настроек или других действий пользователя
Major
Ошибка которая затрудняет использование системы но которая может быть нивелирована путем изменения настроек или использования альтернативного сценария работы
Minor
Ошибка которая затрудняет использование системы но фактически не влияет на способ работы
Trivial
Ошибка которая фактически не влияет на использование функции системы но отражается на общем качестве. Например орфографические ошибки или ошибки оформления.
На первый взгляд кажется возможным для подсчета QS просто подсчитать количество всех найденных ошибок. Но используя такой метод мы рискуем получить устрашающие цифры для в целом достаточно хорошего продукта. Это может произойти в силу того что большинство ошибок ( даже имещих статус Critical и Major ) не будут мешать повседневному использованию продукта большинством пользователей.
Как пример можно посмотреть на публичный bug tracker Skype ( jira.skype.com ). На момент написания там была следующая картина:
Critical — 242
Major — 151
То есть в целом при устрашающих цифрах мы имеем вполне работоспособный продукт который без особых проблем используют миллионы людей.
С другой стороны возможна ситуация когда наличие даже одной ошибки со статусом Critical ( например сбой в процессе инсталляции ) сделает использование системы полностью не возможным.
В результате вышеизложенных размышлений мы решили создать дополнительную классификацию ошибок в соотвествии с тем при каком сценарии использования она проявляется:
Стандартный сценарий использования:
Сценарий использования который был предусмотрен при создания системы.
В свою очередь все стандартные сценарии так же классифицируются как:
— Базовые сценарии
— Второстепенные сценарии
— Редкие сценарии
Нестандартный сценарий использования:
Сценарий который не был предусмотрен на этапе разработки/тестирования.
В свою очередь делятся на:
— Вариант нормального использования
— Вариант не нормального использования
Сценарий который не был предусмотрен и который не может считаться нормальным способом использования системы.
Каждому типу варианта использования и каждой категории ошибки присваивается определенный коэффициент.
Базовый сценарий
Стандартный 12
Не стандартный 4
Второстепенный сценарий
Стандартный 11
Не стандартный 3
Редкий сценарий
Стандартный 10
Не стандартный 2
Сценарий не нормального
использования 1
Critical 20
Major 10
Minor 5
Trivial 2
Коэффициент для конкретного дефекта подсчитывается как коэффициент категории сценария в котором произошла ошибка на коэффициент серьезности ошибки.
Результирующий коэффициент считается как сумма коэффициентов для всех ошибок.
Как результат мы имеем QS определяющий качество системы. Меньшие значения — большее качество. Идеально качество — 0.
Пример:
— Система с 2 Crtitical дефектами в стандартных базовых сценариях использования и 2
Major дефектами в ненормальніх вариантах использования будет иметь
QS = 500 ( 2 * 20 * 12 + 2* 10 * 1 )
— Система с 1 Major дефктом в нестандартном второстепенном варианте использования и 2 Trivial дефектами в стандартных редких вариантах использования будет иметь QS = 70 ( 1 * 10 * 3 + 2 * 2 * 10 )
