Сообщений в теме: 9

[iXus]

Доброе время суток коллеги!

Передо мной была поставлена задача провести investigate такой метрики как сходимость деффектов...
То есть необходимо узнать как рассчитывается, затем, как лучше/технологичнее ее получать?

1) Нашел я следующую формулу:

k = (FIXED Bugs + CLOSED Bugs +1) / (OPENED Bugs + 1)

Целевой показатель: 1 +/- 0.1

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


2) С другой стороны я нарыл формулу:

k = RESOLVED Bugs / OPENED Bugs

К Resolved можно отнести - FIXED, INVALID, WORKSFORME, CLOSED - это же тоже заведенные баги и их надо учитытвать... Но к примеру INVALID и WORKSFORME баги не отражают какой-то деятельности программеров с кодом... То есть это грубо говоря никому ненужные баги, которые возиожно и не стоит учитывать при измерении сходимости багов.

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

Возможно кто-то из Вас сталкивался с этим вопросом и может поделится опытом? Какая все-таки формула по нахождению сходимости багов?
Заранее благодарен за любую полезную информацию!

Прикрепленные файлы

•  Pic1.JPG   93,19К   152 Количество загрузок:
•  Converg.JPG   114,41К   166 Количество загрузок:

[iXus]

Вобщем проанализировав проблему я пришел к следующему...

"bug convergence" - The point at which the rate of fixed bugs exceeds the rate of found bugs. © Microsoft Frameworks Integrated Glossary

То есть это просто точка, в которой произошло выравнивание OPENED и FIXED багов, грубо говоря - 15 октября 2006 года...
То есть в этом понимании: Чтобы рассчитать сходимость необходимо подсчитывать каждый день количество багов, строить график и следить когда количества сравняются...

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

[LeshaL]

Привет!
Не смогу ответить на все вопросы. Если честно, никогда не применял таких метрик ибо они как-то не нужны были.

К Resolved можно отнести - FIXED, INVALID, WORKSFORME, CLOSED - это же тоже заведенные баги и их надо учитытвать... Но к примеру INVALID и WORKSFORME баги не отражают какой-то деятельности программеров с кодом... То есть это грубо говоря никому ненужные баги, которые возиожно и не стоит учитывать при измерении сходимости багов.

С точки зрения простой логики, могу посоветовать следующее.
1. Баги типа INVALID, DUPLICATE и WONTFIX - я бы не стал учитывать вообще, т.к. это не дефекты продукта.
2. По поводу WORKSFORME (аналог NOT-REPRODUCIBLE, если не ошибаюсь) - двоякое мнение. Часть дефектов, вполне возможно была, но они починились при починке других ошибок, например. Такие надо учитывать. Вторая причина закрывать баг таким образом - когда проблема реально не воспроизводится. Возможно был глюк у человека нашедшего баг (чего-то настроил не так, например). Такие я бы не учитывал.
3. Я не стал бы считать баги, который промаркированы разработчиком как FIXED, если они еще не заверифицированы. Т.к. фикс может и не работать.

Т.о. для простой формулы
k = RESOLVED Bugs / OPENED Bugs
имхо, расклад будет такой:
RESOLVED Bugs == все починеные(FIXED и часть невоспроизводимых) и уже заверифицированные баги
OPENED Bugs == все открытые, которые признаны реальными дефектами (т.е. не INVALID, DUPLICATE и WONTFIX) + те, которые были такими, но уже починены или починены и заверифицированы.

Т.о. если у нас все найденый дефекты, реальные баги и они все сразу же фиксятся и верифицируются, мы получим 1. Значение >1, будет в случае, когда новые баги находятся плохо, а старые активно чинятся. 1< - наоборот. И если, вдруг, появляется какой-то перец, который пишет пачку недефектов (инвалидов и дубликатов) - его "активность", картины не испортит.

Цифры:
Нашли 20 нормальных дефектов, 5 недефектов. Из них реально исправили 12(и заверифицировали), 2 исправили плохо(но об этом еще никто не знает) и 5 недефектов закрыли как инвалиды.
Мой подход(типа реальная картина):
12/20 = 0.6
Без учета инвалидов и верификации:
(12+2)/20 = 0.7
Учитывая инвалиды и верификацию:
(12+5)/25 = 0.68
Учитывая все на свете:
(12+2+5)/25 = 0.76

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

[Green]

Коллеги!

Бессмертный Кузьма Прутков говорил:
- Зри в корень!

Метрики - это средство. А что является целью?

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

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

Когда на графике кривая найденных дефектов сходится с кривой закрытых, значит все - кончай тестировать, отправляй продукт заказчику. Но так бывает очень редко. Обычно существует допущение - при каких условиях можно поставлять продукт, а при каких еще нельзя. К примеру можно определить, что на момент поставки должны быть устранены все дефекты "critical", все дефекты "major", допустимо не более 5% "middle", и не более 15% "minor" (категории взяты "от балды" для примера, у вас могут быть свои). Это значит, что если critical не устранены, то и поставлять продукт нельзя, ибо клиент найдет и сильно расстроится, будет топать ногами и обзываться всякими нехорошими словами на ваше начальство. А как известно, начальство такого не любит.

... однако встречаются мазохисты...

[LeshaL]

Сергей, мне тоже не понятно зачем это надо вычислять. И я на 100% согласен с вашим критерием 0 - critical, 0 - major etc.
Так и работаем - и графиков даже не нужно.
Но если уж надо искать точки, как их там, конвергенции - то надо делать это правильно. Либо делать расчеты исходя из дефектов проекта (что, возможно, имеет какой-то смысл), либо исходя из записей в дефект-трэкере, что непоказательно.

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

Это я к тому, что метриками надо аккуратно пользоваться, четко зная зачем их применять. А то может получиться так, что разработчики посмотрят на такой график, и решат, что их будут штрафовать за то что они мало дефектов закрывают. А если при этом в числителе не учитывать верификацию - то будут закрывать баги не фиксая их. Вот и получится - что показатель всегда близок к 1, а реально чинится все-равно мало. А у тестеров, которые верифицируют баги много ненужной работы - проверить и пероткрыть. При этом знаменатель меняться будет слабо.
А если тестеры решат, что их будут штрафовать за малое количество найденых дефектов. И если учитывать дубликаты\инвалиды - то тестеры начнут кипами писать недефекты. Показатели вырастут. У девелоперов будет куча ненужной работы - понять, что не баг и закрыть.
Всем хорошо, все обеспечены работой. А вот что с качеством продукта и сроками...

[culver]

Кроме того, что можно считать все дефекты в метриках и по ним определять готовность, можно вести метрики только по дефектам высокого приоритета. К примеру, если у вас осталось 30 дефектов невысокого приоритета из 500 , то метрика по всем дефектам будет выглядеть не очень, а вот метрика по дефектам высокого приоритета будет онрмальной. Метрики по высовким приоритетам могут быть показательными и в том случае, если разработчик сам указывает что вот эти дефекты для него некритичны и он готов получить продукт с такими дефектами, которые вы позже пофиксите как сервис пак или патч.
Представление метрик сходимости заказчику, где все сошлось (все что нашли, всезакрыли) - достаточно рисковое мероприятие - вы то понимаете, что вы нашли не все, ибо все найти невозможно. А вот заказчик может этого не понимать и по метрикам решит что все супер. Потом он найдет дефекты и скажет что вы плохо работаете. Если же в метриках есть зазор между закрытыми и открытыми, то всегда можно сказать что вы в курсе о дефекте и его фикс выйдет совсем скоро.
Но если заказчик потребует отчета об известных дефектах, тогда все будет выглядеть совсем по-другому. Многое зависит от того, видит ли заказчик базу дефектов.

[LeshaL]

Привет!
Да, вы правы, можно вводить метрики по различным категориям дефектов (severity, priority, subsystem etc). Но опять же, главное понимать, что отражает метрика и для чего она используется.

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

Надеюсь речь о заказчике, а не о разработчике...

Представление метрик сходимости заказчику, где все сошлось (все что нашли, всезакрыли) - достаточно рисковое мероприятие - вы то понимаете, что вы нашли не все, ибо все найти невозможно. А вот заказчик может этого не понимать и по метрикам решит что все супер. Потом он найдет дефекты и скажет что вы плохо работаете. Если же в метриках есть зазор между закрытыми и открытыми, то всегда можно сказать что вы в курсе о дефекте и его фикс выйдет совсем скоро.
Но если заказчик потребует отчета об известных дефектах, тогда все будет выглядеть совсем по-другому. Многое зависит от того, видит ли заказчик базу дефектов.

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

Что касается дефект-трэкера, то не вижу ничего криминального в открытии информации по дефектам. Это - часть продукта. Думаю, что это даже полезно. Если бы у всех выпускаемых продуктов база по дефектам была открыта, то производили бы более качественное ПО. А иначе стыдно бы было :) Но и тут палка о двух концах.

[Darkus]

1. Баги типа INVALID, DUPLICATE и WONTFIX - я бы не стал учитывать вообще, т.к. это не дефекты продукта.

Позволю не согласиться по 1 пунтку.
WONTFIX - это ведь не будет пофиксено? Но от этого дефект продукта не перестал быть дефектом? Поправьте меня, если я не понял :)
INVALID - смотря что под этим понимать...
DUPLICATE - да, это проблема тестировщика, что забил баг, который уже описан. Полностью согласен, что его можно не учитывать.

[LeshaL]

Позволю не согласиться по 1 пунтку.
WONTFIX - это ведь не будет пофиксено? Но от этого дефект продукта не перестал быть дефектом? Поправьте меня, если я не понял :)
INVALID - смотря что под этим понимать...
DUPLICATE - да, это проблема тестировщика, что забил баг, который уже описан. Полностью согласен, что его можно не учитывать.

Вот здесь написано как понимают это создатели багзиллы
https://bugzilla.moz...lds.html#status
В моем понимании так:
INVALID - тут все просто, согласен с мозильцами. Это баг - небаг. Например, для этого сайта я напишу такой баг - "я написал свой плагин к браузеру, но когда он включен не могу зайти на ваш сайт - браузер падает с ошибкой" или "синтаксическая ошибка в рекламе, которая показывается наверху страницы". Понятно, все это к багам сайта отношения не имеет.

WONTFIX - тут немного сложнее. Несколько варантов, когда можно баг закрыть так.
1) то как описано у вас (ну и у мозильцев также) - то что не будет починено, хотя это и баг. Этот вариант можно назвать правильным, только в случае, когда есть третьесторонняя библеотека, в которой баг на самом деле. И пока там кто-то не починит, то и в нашем продукте починить невозможно. Но лучше бы такое не закрывать, а откладывать - чтобы не продолбать момент, когда в третьесторонней библиотеке наконец-то починят причину проблемы.
2) тоже баг, но в предыдущей версии или переписаной функциональности. Например, кто-то взял старую версию программы и произвел действия приводящие к неправильному поведению. Этот кто-то пишет баг. Ему в ответ - да баг, но версия номер такая-то больше не поддерживается - переходите на новую версию, все будет ОК. Чинить не будем.
3) когда баг небаг, а фича. Т.е. человек, нашедший баг, справедливо решил, что это поведение неправильно, т.к. оно не специфицировано. Но по результатм исследования, решают, что такое поведение правильное и апдейтят спецификацию. Все правильно - баг чинить не будут. Но и инвалидом не назовешь.
4) чаще всего - для feature requests или enhancement. Одни люди хотят чего-то, другие им объясняют, почему они этого добавлять не будут.

В любом случае, все это тяжело назвать проблемами программы. Поэтому я предложил их не учитывать. Но хозяин - барин. Кто хочет, может и учитывать.

[Galina]

Сходимость дефектов может служить маячком, ИМХО. Если вдруг "кривые" стали расходиться резко - значит тестровщики нашли много багов, а разработчики не успевают править.... если такая тенденция продолжится, это сулит проблемы... Если вдруг в начале релиза "кривые" сошлись, т.е. тестировщики не находят багов - стоит задуматься там ли "копаем".