Анализ динамики критичности дефектов
Апрель 26, 2010С течением времени количество ошибок в тестируемой программе становится меньше и в какой-то момент становится нужно прекращать тестирование. Определить этот момент не так-то просто.
Cуществуют несколько подходов:
- Кончились деньги на тестирование.
- Найдены и исправлены все дефекты (я не знаю, как это сделать) .
- Выполнены все запланированные тесты и не осталось ни одного активного дефекта с важностью «Критично».
- Обеспечено разумное тестовое покрытие (любым способом) и совокупность активных дефектов признана допустимо хорошей (согласно утвержденного регламента) для передачи в эксплуатацию.
- Кривая активных дефектов четвертый раз была равна нулю (любопытный метод от Microsoft).
- Экспертное мнение опытного (стаж в коммерческой разработке ПО от 10 лет) инженера по качеству.
- Отсутствие или допустимое число замечаний по итогам приемо-сдаточных испытаний
- Оценка числа невыявленных дефектов и уровня дефектности программного модуля признана удовлетворительной на основании проведенных статистическими исследований:
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


