Архив за Апрель, 2010

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

Понедельник, Апрель 26th, 2010

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

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