Анализ динамики критичности дефектов

С течением времени количество ошибок в тестируемой программе становится меньше и в какой-то момент становится  нужно прекращать тестирование. Определить этот момент не так-то просто.

Cуществуют несколько подходов:

  1. Кончились деньги на тестирование.
  2. Найдены и исправлены все дефекты (я не знаю, как это сделать) .
  3. Выполнены все запланированные тесты и не осталось ни одного активного дефекта с важностью «Критично».
  4. Обеспечено разумное тестовое покрытие (любым способом) и совокупность активных дефектов признана допустимо хорошей (согласно утвержденного регламента) для передачи в эксплуатацию.
  5. Кривая активных дефектов четвертый раз была равна нулю (любопытный метод от Microsoft).
  6. Экспертное мнение опытного (стаж в коммерческой разработке ПО от 10 лет) инженера по качеству.
  7. Отсутствие или допустимое число замечаний по итогам приемо-сдаточных испытаний
  8. Оценка числа невыявленных дефектов и уровня дефектности программного модуля признана удовлетворительной на основании проведенных статистическими исследований:
    a. Частичного перекрытия зон тестирования
    b. Искусственной вставки известного числа дефектов в тестируемый код
    c. Выборочного исследования

Экспертное мнение дешевый и часто самый надежный метод оценки готовности. Но ему не так часто верят. Действительно, а факты где? Чем доказать, что софт не готов?

Я предлагаю еще один метод анализа.

Количество находимых ошибок за единицу времени относительно стабильная величина и находится в пределах статистических отклонений.  Это следствие сразу нескольких причин.

Причина первая.  «Приминать траву» можно до бесконечности.  Всегда можно придумать еще одно улучшение и оформить его как дефект.

Причина вторая. Основное время тестирования уходит на описание дефектов.
Пройдете вы за неделю 50 или 1000 сценариев – все равно в среднем вы опишите примерно одно и то же число ошибок (30-150 в зависимости от проекта).

Таблица 1  Число найденных ошибок понедельно в разрезе критичности
 
Если построить понедельный график количества найденных ошибок, то получится что-то такое:
 
Рисунок 1. Число найденных ошибок по неделям

 

 Для анализа не годится.
Но можно построить точно такой же график с разбивкой по важности (не стоит использовать приоритет). Кстати именно для такого анализа имеет смысл вести два атрибута: критичность и приоритет. Приоритет нужен для управления, критичность для статистического анализа.
 
Рисунок 2. Число найденных ошибок понедельно в разрезе критичности

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

Следующий шаг состоит в «приведении к общему знаменателю» дефектов с разным показателем важности. Нужно придумать функцию, которая будет использовать веса приоритетов. Хороший вариант был предложен Тагути (смотри «Функция потерь Тагути»)
В соответствии с этой функций зададим веса:
• Critical - 16
• Major - 9
• Average – 4
• Minor – 1

Следующий шаг – нормирование на трудозатраты. Число найденных ошибок сильнее всего зависит от того, сколько часов из 40 мы уделили тестированию. Влияние трехдневной болезни очень велико.

Можно вести учет времени, но это трудоемко и точность оставляет желать лучшего. Гораздо проще отнормировать на число найденных ошибок за период. Таким образом, мы в чистом виде получим изменение характера ошибок.
 
Рисунок 3.  Профиль критичности

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

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

Значение между единицей и четверкой говорит о хорошем состоянии проекта. Глядя на этот график я предполагаю, что после десятой недели тестирование можно прекратить. Для определенной категории проектов.  А если брать проекты с низкими требованиями к бездефектности вроде wordpress, то и восьмая неделя была явно лишней.

У этого метода анализа естественно есть ограничения в применимости. К ним относятся:

  • Разнесение во времени разных видов тестов. Так тестирование ссылочной целостности выявляет множество критичных ошибок, но может идти после тестирования базового функционала.
  • Разные участки программы делали программисты с резко отличающимся опытом.
  • У вас не накоплено статистически значимое количество исходных данных.
  • И т.д. и т.п.

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

Как строить такие графики.
Практически бессмысленно искать инструменты поддержки принятия решений в BTS нижнего сегмента. Популярные багзила и мантис это простенькие средства учета дефектов, а никак не системы управления тестированием.

В системах энтерпрайз уровня подобная анатлитика есть. Так например, Rational Clear Quest имеет встроенный и очень неплохой генератор отчетов. Вот этот отчет был получен в Rational Clear Quest почти честным способом. Почти, потому что SQL запрос пришлось таки допиливать вручную.
 
Рисунок 4. Число найденных ошибок понедельно в разрезе критичности. Отчет ClearQuest.

Другой вопрос, и он самый важный: ”Будете ли вы делать такой анализ?”

 

Приложение 1. SQL запрос для получения графика в CQ.
select distinct cal.start_date,count(T1.severity) as record_count,T1.severity from weekcal cal,Defect T1 where (cal.start_date >= #2000-01-10# and cal.start_date <= #2001-01-01#) and (T1.submit_date >= cal.start_date   and T1.submit_date <   cal.end_date) group by cal.start_date,T1.severity order by cal.start_date, T1.severity

 

 

Комментариев: 2

  1. saveug написал:

    Возникло несколько вопросов:

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

    2. Не очень понял разницу между рис. 2 и рис. 3, они отображают практически одно и то же, однако для рис. 3 требуются какие-то дополнительные телодвижения (умные фразы и т.п.) Из рис. 2 уже видно, что нет критикал и совсем мало мейджоров, видим сходимость стабилизации, зачем еще какие-то замуты?

    И вот еще вопрос:

    Наблюдать за фактическим ходом тестирования конечно интересно, но вот куда более интересна методика прогнозирования продолжительности этапа стабилизации для очередного инкремента продукта. Есть у Вас подобные методики или практики?

  2. SALar написал:

    1. Важность и критичность - разные атрибуты. Использовать один атрибут проще, но в статье приведена достаточно сложная система анализа.
    Есть много способов управления дефектами и есть много способов анализа. Часть из них мне известна, и часть мной описана. Я не говорю, что это панацея, это просто это один из возможных способов анализа. Кстати, не самый лучший.
    2 и 3. Это один из способов приведения к “общему знаменателю”. Это способ оценить что хуже, один “критикал” или десять миноров. Применимо не ко всем проектам, но иногда можно использовать.
    Честно предупреждаю, что не всегда.

    > Наблюдать за фактическим ходом тестирования конечно интересно, но вот куда более интересна методика прогнозирования продолжительности этапа стабилизации для очередного инкремента продукта. Есть у Вас подобные методики или практики?
    Да. Мои оценки сходились с точностью порядка 10% (возможно случайность, но было и есть). При этом мои оценки сильно расходились с оценкой других заинтересованных лиц проекта и были, как правило, более точными.
    Не все методики я пока могу описать или передать. Т.е. часть этих знаний - это мой опыт. К моему глубокому сожалению, пока неотделимый от меня.

    PS. Вы очень правильно выделили одну из возможностей использовать группу тестирования. Оценка срока пригодности продукта. Это отдельная, как правило, не озвучиваемая цель.
    Примите знак моего уважения перед вашим опытом.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.