Подходы к оценке качества релизов программного обеспечения

В современных компаниях по разработке программного обеспечения (ПО), обычно используется подход итеративного создания, развития и улучшения программ, включающий в себя этапы:

• анализ запросов (analysis) заказчика 
• планирование и постановка задач разработчикам для очередного цикла разработки (planning);
• разработка ПО (develop) программистами;
• тестирование (testing) решенных программистами задач;
• релиз (release) – итог очередной итерации разработки ПО;
• передача, внедрение (update) и апробация релиза у заказчика.

Тестирование программного обеспечения (Software Testing) – это вид деятельности, направленный как на оценку качества ПО, так и на его улучшение, путём выявления недостатков и проблем. Тестирование заключается в динамической верификации (проверки соответствия между реальным и ожидаемым) поведения программ на конечном наборе тестов, выбранном определенным образом [1].
В тестировании ПО можно выделить следующие направления:

• функциональное тестирование (ручное и автоматическое),
• нагрузочное тестирование,
• тестирование информационной безопасности,
• оценка рисков внедрения и качества релизов.

Под функциональным тестированием (Functional Testing) будем понимать проверку соответствия реализованного функционала приложения заявленному в техническом задании (ТЗ), или условиям, поставленным в соответствующей задаче по разработке.

Под нагрузочным тестированием (или тестированием производительности, Performance testing) будем понимать автоматизированное тестирование, имитирующее работу определенного количества пользователей в приложении.

Под тестированием безопасности (Security Testing) будем понимать стратегию тестирования, направленную на выявление уязвимостей, присущих ПО, которые злоумышленник потенциально сможет эксплуатировать и реализовать определенные угрозы информационной безопасности (ИБ).

Релиз ПО включает в себя блок задач, которые необходимо решить программистам в течение очередного цикла разработки ПО:

• задачи по разработке нового функционала (new tasks);
• задачи по доработке и улучшению функционала (improvements);
• задачи-дефекты или «баги» (defects, bugs) по исправлению найденных на предыдущих этапах ошибок в программе.

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

Под показателем рисков внедрения будем понимать степень возможности отказа в работоспособности установленного у заказчика ПО. Отказ в работоспособности ПО сопровождается потерями ресурсов, времени на восстановление, денег, репутации, человеко-часов разработчиков и тестировщиков из-за необходимости повторения цикла разработки.

Под показателем качества релиза будем понимать степень уверенности разработчиков в готовности программы к внедрению.

Такими показателями могут быть как собственные субъективные оценки руководителя проекта о рисках и качестве релиза, подготовленные, например, в виде отчёта, так и некоторая система статистических показателей.

Для оценки рисков внедрения и качества очередного релиза допустимо использование обычного вероятностного подхода, где показатели измеряются на шкале от 0 до 100%. Схематично взаимосвязь понятий рисковых и качественных задач представлены на рис. 1.

Рис.1. Взаимосвязь рисковых и качественных задач

За риск внедрения релиза принимают величину, измеряемую на шкале от 0 до 100% и характеризующую вероятность нахождения ошибок в программе из-за нерешенных и не протестированных задач:

(1)

где All – общее число задач запланированных в очередном релизе, 

Resolved – число задач, решенных программистами, 

Tested – число протестированных задач из числа решенных.

За качество релиза принимают величину, измеряемую на шкале от 0 до 100% и характеризующую вероятность отсутствия ошибок среди решенных и проверенных тестировщиками задач:

(2)

Достоинствами статистических подходов является простота их реализации и наглядность результатов оценки.

Недостатки такого подхода к оценке рисков и качества релиза:

• необходимость интерпретации получаемых числовых характеристик экспертами;
• отсутствие учёта важности, сложности и связей задач;
• отсутствие учёта мнений экспертов относительно рисков и качества релиза;
• отсутствие учёта субъективной, нечеткой составляющей риска и качества.

Для частичного преодоления указанных недостатков предлагается использовать модифицированный вероятностный подход.

Кроме указанных выше параметров, вводятся дополнительные: 

All_B – число задач с багами среди запланированных к решению в релизе, 

Resolved_B – число решенных задач с дефектами, 

Tested_B – число решенных и протестированных задач с дефектами, 

w – показатель веса (weight) для обычных задач, 

w_B –  показатель веса для задач с дефектами. 

В этом случае формулы (1) и (2) для оценки риска и качества релиза модифицируются в формулы (3) и (4) соответственно:

(3)

(4)

Предлагается использовать значения показателей весов w = 1, w_B = 2, имея в виду, что задачи-дефекты условно «в 2 раза важнее», чем обычные задачи.

Для упрощения получения параметров релиза, используемых при расчете показателей качества и рисков, в системе баг-трекинга Jira, возможно настроить кросс-фильтр «Тип запроса – Статус» (см. рис. 2). При этом для каждого проекта получаем сводные таблицы состояния по всем задачам.

Рис. 2. Кросс-фильтр «Тип запроса – Статус» в системе баг-трекинга Jira.

Собранные данные проще всего агрегировать в одну Excel-таблицу и выполнить расчёты показателей рисков и качества по формулам (3) и (4), как показано на примере на рис. 3.

Столбцы в данной таблице означают:

• Всего – количество задач, запланированных на релиз;
  … (из них с багами) – задачи с багами, найденные до внедрения релиза (в том числе, возможно, и в предыдущих релизах).
• Решено – количество решенных разработчиками задач в релизе (те задачи, у которых они меняли статус на Resolved);
  … (из них с багами) – задачи-баги для которых разработчики поставили статус Resolved.
• Протестировано – число протестированных задач, которым тестировщики поставили статус Tested;
  … (из них с багами) – число задач с багами которые проверены тестировщиками и которым они поставили статус Tested.
• Показатель рисков релиза, % – показывает вероятность нахождения ошибок конечными пользователями среди задач в релизе.
• Показатель качества релиза, % – показывает степень уверенности тестировщиков в том, что среди задач в релизе нет ошибок.

В строке «Весь проект» – используются аналогичные показатели, только статистика собирается для всего проекта целиком.

Рис.3. Агрегированные показатели рисков и качества для релизов.

Пример динамики изменения показателей рисков и качества для одного из проектов группы компаний «Центр» представлен на рис. 4. Динамика представлена простым совокупным графиком. Низкие или высокие риски означают вероятность нахождения ошибок пользователями. Низкое или высокое качество означает степень уверенности инженеров-тестировщиков в проверенных или по каким-либо причинам непроверенных задачах. 

Рис. 4. Динамика изменения показателей рисков и качества в процессе разработки проекта «РЖД Энергопаспорт».

Окончательно оценивается каждый показатель после внедрения предыдущего релиза (после того, как релиз обновлен у пользователей), в остальное время можно оценивать промежуточные параметры релиза.

Данные показатели могут быть использованы при планировании задач для будущих релизов и для оценки возможных затрат на доработку задач.

Руководитель проекта, опираясь на анализ показателей, может выполнить следующие действия, по снижению рисков и улучшению качества следующего релиза:

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

Как видим, даже модифицированный подход не избавляет от необходимости интерпретировать результаты, не учитывает различную сложность и другие характеристики задач, а также не учитывает мнения экспертов (специалистов по качеству) относительно релизов.

Из очевидной связи рисков и качества – согласно формулам (1)-(4) чем выше риск, тем ниже качество – в дальнейшем предлагается использовать нечеткие лингвистические шкалы для оценки качества, опираясь на мощный математический аппарат современной теории нечетких систем.

Подходы к разработке таких шкал для оценки различных свойств информационных систем подробно исследованы и успешно апробированы в методике нечеткой оценки рисков ИБ [2]. Указанную методику возможно модифицировать для решения задачи оценки качества ПО, отождествляя понятия безопасной системы и качественной системы. Такое отождествление допустимо в рамках подхода к разработке безопасного ПО OWASP (The Open Web Application Security Project), в котором под качественным ПО понимается безопасное ПО.

Список литературы:

1. Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004.  http://www.computer.org/portal/web/swebok/home
2. Гильмуллин Т.М. Модели и комплекс программ процесса управления рисками информационной безопасности: дис. ... канд. технич. наук / Т.М. Гильмуллин; Казанский государственный технический университет. – Казань, 2010. – 225 с.

Опубликовано: Гильмуллин Т.М. Подходы к оценке качества релизов программного обеспечения / Т.М. Гильмуллин // Моделирование, идентификация, синтез систем управления МИССУ'2012: Сборник тезисов Пятнадцатой Международной научно-технической конференции, г. Донецк, 9-16 сентября 2012 г. – Донецк: Изд-во ИПММ НАН Украины, 2012. – С. 141-142.