Оценка качества билда.
#1
Отправлено 11 декабря 2007 - 13:49
Надо оценить качетсво билда(по итерации). На проекте только ручное тестирование. Имеем наборы тест кейсов и соответсвенно тест резалты к ним. И имеем баги(с приоритетами по разнім сценариям) найдены на этой итерации. Надо оценить качество билда желательно в чисельном эквиваленте.
Может кто подскажет путь к оценке, что б она была объективная. Проект, билинговая система.
#2
Отправлено 14 марта 2008 - 14:01
#3
Отправлено 14 марта 2008 - 15:07
В результате получите одно число. Если оно не превосходит некоего порога, который выясните экспериментально или методом тыка, то билд хороший. Соответственно чем число меньше, тем лучше.
Тут так же важно чтоб все участники процесса (менеджер, разработчики, тестировщики и т.д.) согласились на коэффициенты и пороговое значение, тогда от такой метрики будет толк. Она не будет объективна (она никогда такой не будет), но она не будет и субъективна с перекосом в одну из сторон.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#4
Отправлено 14 марта 2008 - 16:56
Мы подобную схему применяем. Но у нас есть еще коефициент, зависящий от visibility, то есть от того, насколько часто на такой баг можно натолкнуться. Даже если баг и блокирующий, но возникает при очень хитром сочетании опций в каком-то модальном диалоге n-ного уровня, то его реальная критичность заметно ниже, чем если некорректно работает некоторый ключевой функционал. То есть баг по severity ниже, но по важности выше.Можно складывать количество багов с весом. Например blocker - 100 баллов, critical - 50, major - 20 и т.д.
В результате получите одно число. Если оно не превосходит некоего порога, который выясните экспериментально или методом тыка, то билд хороший. Соответственно чем число меньше, тем лучше.
Можно еще дополнительные коефициенты ввести при необходимости. Все зависит от того, как вы можете выстроить градацию компонентов системы.
Эт точно. Все зависит от договоренностей. Например, допустимая планка не должна превосходить вес блокирующего бага.Тут так же важно чтоб все участники процесса (менеджер, разработчики, тестировщики и т.д.) согласились на коэффициенты и пороговое значение, тогда от такой метрики будет толк. Она не будет объективна (она никогда такой не будет), но она не будет и субъективна с перекосом в одну из сторон.
Также встречался такой критерий, что новый релиз не должен быть хуже по качеству, чем предыдущий. То есть в первую очередь отслеживается, чтоб не было никаких блокеров, а затем уже фиксят баги по мере возможностей, но фикс не заканчивается до тех пор, пока не будет преодолена пороговая отметка. Это как минимум.
#5
Отправлено 17 марта 2008 - 09:44
Очень классная вещь! Позволяет сравнивать несравнимые, на первый взгляд, вещи. Так и вы - сможете оценить (сравнить) качество разных билдов.
#6
Отправлено 17 марта 2008 - 14:25
Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.Мы подобную схему применяем. Но у нас есть еще коефициент, зависящий от visibility, то есть от того, насколько часто на такой баг можно натолкнуться. Даже если баг и блокирующий, но возникает при очень хитром сочетании опций в каком-то модальном диалоге n-ного уровня, то его реальная критичность заметно ниже, чем если некорректно работает некоторый ключевой функционал. То есть баг по severity ниже, но по важности выше.
Можно еще дополнительные коефициенты ввести при необходимости. Все зависит от того, как вы можете выстроить градацию компонентов системы.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают (или найдут более короткий путь), причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.
#7
Отправлено 17 марта 2008 - 14:35
ну во первых я полностью согласен с Вами. и от себя хотел бы добавать, что такой пункт при тестировании как visibility слишком субъективен, ибо объективной оценки данного параметра дать невозможно, по причине того же человеческого фактора.Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают, причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.
Вообще оценка качества вещь отнюдь не нормированная, что для одних систем возможно для других недопустимо..
посему я бы советовал при оценке качества исходить из непосредственно функционала, критичного/некритичного.
лично я советовать уже ничего не могу, буду повторяться, все что нужно посоветовали выше. Постарайтесь собрать информацию в одно целое и выбрать из неё, то что необходимо для тестирования именно вашего ПО.
#8
Отправлено 17 марта 2008 - 14:46
Вообще я против измерения средней температуры по больнице,Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают (или найдут более короткий путь), причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.
но приведу еще один пример оценки проблем, использующий три показателя: важность, частоту повторения и вероятность внесения новых ошибок при исправлении этой.
Третий показатель оказывает очень сильное влияние, посколько сломать код ради исправления пусть и важной, но проявляющейся только раз в году проблемы - серьезный риск.
#9
Отправлено 17 марта 2008 - 14:59
НО нельзя пропускать ПО с важными, и даже пусть редко проявляющейся проблемой. Это редко может наступить...
Я к чему, если есть вероятность внесения новых ошибок, в чем проблема? находятся новые ошибки и исправляются, если при каждом внесении изменений в ПО появляются критичные ошибки, то уж пардон тут дело в разработчиках.
#10
Отправлено 17 марта 2008 - 18:24
Подход интересный, но бесполезный в большинстве случаев. Представьте, что у вас не два билда а 10, не два параметра а 10 и попробуйте посчитать такую штуку. Нормальный человек запариться это считать, ну можно конечно заставить считать это машину. Но тут есть еще проблема погрешности. Неужели кто-то может точно выдавать оценки? Посчитайте погрешность. После этого я подозреваю (лишь подозреваю), что значашей останется только первая цифра.Попробуйте почитать про AHP (Analytic Hierarchy Process). Например http://msdn.microsof...e/cc163785.aspx
Очень классная вещь! Позволяет сравнивать несравнимые, на первый взгляд, вещи. Так и вы - сможете оценить (сравнить) качество разных билдов.
А потом менеджер вас спросит каково качество билдов 1 и 2, а вы ему скажите у 1-го 0.531, а у 2-го 0.565. И что? Это соответсвует действительности? Не верю. По таким данным нельзя ничего решить, тем более если погрешность не посчитана.
Сравнивать несравниваемое не так просто, как кажется.
Возмите такие параметры, чтоб один блокирующий баг "портил" всю сборку.Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Метод оценки можно придумать любой сложности: с одним, двумя, тремя и т.д. различными параметрами у багов (важность, частота и т.д.), важно чтоб эти параметры имели реальное (осмысленное) значение. Если при записи бага тестировщики заполняют поле "частота" от балды, то никакого проку от расчетов с этим полем не будет.
Я например вообще практически не различал важность(severity) у багов, но лишь до тех пор пока это поле не обрело смысл.
Когда все договорились, что важность бага влияет на то, когда баг будет исправлен, я стал проставлять его со смыслом, думая.
Если у вас есть такие поля в багтрекере и они содержат осмысленную информацию о баге, то вам повезло, используйте эту информацию. Но если их таких полей нет или в них нет информации (а лишь мусор), лучше их не трогать.
В целом при оценки качества сборки между итерациями я бы придерживался лозунга "As simple as possible, but not simpler".
Одно число дает один бит информации - выше порога или ниже порога. Хотя не имею ничего против других предложенных выше схем (кроме AHP), если они не нарушают изложенных выше соображений.
Вот для критерия окончания тестирования все гораздо сложнее, но тут нельзя обойтись одним или даже двумя числами.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#11
Отправлено 17 марта 2008 - 19:49
Вот это здорово. Сколько сил было положено на то, чтобы тестировщиков перестали использовать как отладочный ресурс, и тут вдруг озарение.И опять ворвусь в вашу беседу, как я считаю, тестирование это и есть как раз механизм отдалдки ПО,
Это "редко" является риском. Риски бывают всякие. Иногда ими управляют.НО нельзя пропускать ПО с важными, и даже пусть редко проявляющейся проблемой. Это редко может наступить...
Проблема вот в чем. У вас есть некоторый обещанный срок до выпуска версии. Одна или несколько не очень серьезных ошибок требуют изменения архитектуры целой подсистемы приложения. Начинающий разработчик легко даст оценку "за две недели перепишем" (это вообще волшебная величина - две недели). В реальности эти две недели оказываются двумя месяцами на саму по себе разработку, еще парой недель на перетестирование продукта, и месяцем на исправление внесенных ошибок. В результате оптимистичная попытка исправить пару юзабилити проблем выльется в провал проекта.Я к чему, если есть вероятность внесения новых ошибок, в чем проблема? находятся новые ошибки и исправляются, если при каждом внесении изменений в ПО появляются критичные ошибки, то уж пардон тут дело в разработчиках.
Это все очень утрировано, разумеется.
Смысл же в том, что на количество, важность и класс известных ошибок полагаться нельзя. Есть цель релиза, она и определяет критерии.
#12
Отправлено 18 марта 2008 - 07:10
Ну собственно если брать изначально QA как должность, то она подразумевает под собой контроль качества продукта, то есть весь механизм грубо говорят свобидтся к схеме: Видение-ТТ-ТЗ-разработка-тестирование-отладка-тестирование.Вот это здорово. Сколько сил было положено на то, чтобы тестировщиков перестали использовать как отладочный ресурс, и тут вдруг озарение.
естественно утрировано сильно, но смысл в этом. Что именно должность QA должна отвечать за качество продукта, продукт в релизе должен быть функционален ровно столько, сколько заявленно в ТТ, если же продукт не соотвествует ТТ, то это уже провал проекта.
конечно в данной ситуации нужно рассматривать конкретный продукт, но на своем опыте скажу, что такие методы (пропуска ошибок с высоким приоритетом) приводили к потере не малых сумм.Проблема вот в чем. У вас есть некоторый обещанный срок до выпуска версии. Одна или несколько не очень серьезных ошибок требуют изменения архитектуры целой подсистемы приложения. Начинающий разработчик легко даст оценку "за две недели перепишем" (это вообще волшебная величина - две недели). В реальности эти две недели оказываются двумя месяцами на саму по себе разработку, еще парой недель на перетестирование продукта, и месяцем на исправление внесенных ошибок. В результате оптимистичная попытка исправить пару юзабилити проблем выльется в провал проекта.
Я так понимаю, что продукты производимые и тестированые Вами имеют возможность погрешности, исходя из Ваших сообщений. Так что в принципе как я уже говорил, тут необходимо рассматривать каждый продукт в целом, т. к. некоторые продукты контроль которых приходилось выполнять мне не должны иметь погрешностей в функционале, т. к. это возможно очень большие потери финансов/клиентов.
#13
Отправлено 18 марта 2008 - 09:05
Зависит от нужд и целей. Время, деньги, качество. Выберите любые два. Если баг трудно воспроизводится и задействован функционал, который просто далеко зарыт да еще и используется в каком-то вспомагательном модуле, то хоть он и блокирующий, он может быть куда менее важным, чем огрехи основного бизнес-функционала. И лучше уделить время второму багу, который в данном случае серьезнее. Опять же, коефициенты подбираются исходя из нужд, также наносятся и поправки. Так же и исходя из требований к качеству с поправкой на реальность можно определять и пороговое значениеВот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.Мы подобную схему применяем. Но у нас есть еще коефициент, зависящий от visibility, то есть от того, насколько часто на такой баг можно натолкнуться. Даже если баг и блокирующий, но возникает при очень хитром сочетании опций в каком-то модальном диалоге n-ного уровня, то его реальная критичность заметно ниже, чем если некорректно работает некоторый ключевой функционал. То есть баг по severity ниже, но по важности выше.
Можно еще дополнительные коефициенты ввести при необходимости. Все зависит от того, как вы можете выстроить градацию компонентов системы.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают (или найдут более короткий путь), причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.
#14
Отправлено 18 марта 2008 - 09:19
В том-то и дело, что есть и редкопроявляющаяся проблема, а есть проблема, которая просто далеко зарыта. Да, можно бросить усилия на ее решения, потратить кучу времени, но исправить. При этом более видимые и легковоспроизводимые баги останутся неисправленными к моменту релиза, а ведь именно эти баги пользователь обнаружит в первую очередь. Вот на это и расчитан поправочный коэфициент на visibility проблемы.И опять ворвусь в вашу беседу, как я считаю, тестирование это и есть как раз механизм отдалдки ПО, и регрессионное тестирование как раз служит для этого, в итоге при выпуске необходимо получить максимум функциональное ПО без критичных ошибок вообще. Конечно понятно, что ПО без ошибок быть не может "если человек не допускает ошибок, значит он не работает"
НО нельзя пропускать ПО с важными, и даже пусть редко проявляющейся проблемой. Это редко может наступить...
Дело в том, что сроки могут быть ограничены и в ваших же интересах расставить какие-то приоритеты и учитывать то, что некоторые баги все-таки в этой версии будут, так как на их исправление времени нехватает. А постоянное прокручивание тестирования может серьезно отложить выход продукта на рынок, что однажды приведет к тому, что этот продукт будет работать и с меньшими огрехами, чем продукт конкурентов, но он уже не будет востребован, так как ниша уже занята. Время много чего ограничиваетЯ к чему, если есть вероятность внесения новых ошибок, в чем проблема? находятся новые ошибки и исправляются, если при каждом внесении изменений в ПО появляются критичные ошибки, то уж пардон тут дело в разработчиках.
#15
Отправлено 18 марта 2008 - 09:33
Подход интересный, но бесполезный в большинстве случаев. Представьте, что у вас не два билда а 10, не два параметра а 10 и попробуйте посчитать такую штуку. Нормальный человек запариться это считать, ну можно конечно заставить считать это машину. Но тут есть еще проблема погрешности. Неужели кто-то может точно выдавать оценки? Посчитайте погрешность. После этого я подозреваю (лишь подозреваю), что значашей останется только первая цифра.
Вы просто до конца не разобрались :) Количество билдов в наш 21 век роли не играет - за вас все будет считать машина. Да и про какую погрешность вы говорите - вы же сами расставляете коэффициенты. Пусть за вас это сделает менеджер - да неважно кто, важна суть.
А потом менеджер вас спросит каково качество билдов 1 и 2, а вы ему скажите у 1-го 0.531, а у 2-го 0.565. И что? Это соответсвует действительности? Не верю. По таким данным нельзя ничего решить, тем более если погрешность не посчитана.
Сравнивать несравниваемое не так просто, как кажется.
Ну не верьте, никто же вас не заставляет :) Только учтите, что данный метод - чисто математический, и если вы не верите получившимся цифрам - то нет доверия и собственным оценкам. О какой оценке качества тогда может идти речь?
#16
Отправлено 18 марта 2008 - 10:06
Но в целом Ваша точка зрания по моему мнению не считается не правильной, как мне кажется она применима в определенных средах и вполне действующая.. =)
я к чему, думаю Вы со мной согласитесь, что для оценки продукта в принципе и расстановки приоритетов необходимо знать цель и функцию самого продукта
#17
Отправлено 18 марта 2008 - 10:40
Повторюсь, такая оценка будет субъективной, но более адекватной, нежели просто ранжировать по уровню приоритета инцидентов.
#18
Отправлено 18 марта 2008 - 10:48
I . Серьёзность - заполняет тестировщик исходя из своего здравого смысла и руководствуясь такой табличкой:
1. Малый – Косметические дефекты, опечатки.
2. Средний - Дефект, проявляющийся в неправильной работе функциональности
3. Большой - Дефект, проявляющийся в отказе функциональности
4. Критический – Дефект, приводящий к сбою в работе ПО, но не вызывающий фатальных последствий.
5. Фатальный – Дефект, приводящий к непредвиденному разрушению баз данных, порче файлов, поломке или зависанию операционной среды и.т.д.
II. Приоритет - по пятибальной шкале выставляет руководитель проекта, опять же, исходя из своего здравого смысла.
Это зависит от многих факторов. Если дефект фатальный, понятно - он подлежит исправлению в первую очередь. С остальными обязательно надо вникать в суть проекта.
III. Важность требования. Это заполняется при разработке требований, тем кто их разрабатывает.
В результате, Получаем матрицу, по Х - серьёзность, по У - важность требований, в пересечении количество дефектов. Весовые коэффициенты на каждую "серьёзность" у меня пока не выработаны окончательно, это скорее статистические данные по предыдущим разработкам. Приоритет в данном случае является неким поправочным коэффициентом, влияющим на важность. Ибо 150 грамматических ошибок в приложении типа Sovereign Application имеют приоритет выше чем "средний" дефект в требовании с низкой важностью.
Перемножая Важность, Серьёзность, Вес, Количество и суммируя их все мы можем получить некий "Вес дефектов ПО". К нему уже можно присматриваться и оценивать. Понятно, что весовые коэфициенты могут и даже должны корректироваться.
#19
Отправлено 18 марта 2008 - 10:50
Да машина все хорошо посчитает, полностью согласен. И суть важна. Но суть в том, что нет никакой гарантии, что производительность составляет 0.200 от общего качества сборки, а не 0.201 или 0.250. Это и называется погрешность. Даже менеджер не может (о боже!) точно сказать каково это число, он всегда ошибется. Если предположить, что каждое значение в данном методе вы получаете с точностью 10% (что на мой взгляд хорошо), то итоговая погрешность для приведенного случая будет не ниже 17% (будет выше).Вы просто до конца не разобрались :) Количество билдов в наш 21 век роли не играет - за вас все будет считать машина. Да и про какую погрешность вы говорите - вы же сами расставляете коэффициенты. Пусть за вас это сделает менеджер - да неважно кто, важна суть.
Т.е. в приведеном примере надо писать (приблизительно) Build A is 0.5+-0.1, Build C is 0.33+-0.6 и т.д.
В этом случае отличие двух сборок не так очевидно. Не так ли?
Вот и я о том же.Только учтите, что данный метод - чисто математический, и если вы не верите получившимся цифрам - то нет доверия и собственным оценкам. О какой оценке качества тогда может идти речь?
Если метод математический, тогда надо использовать его полностью и не выкидывать такую важную вешь как погрешность.
Если Вы можете точно сказать, что производительность это 0.200 от качества с точностью до последнего нуля, то Вы заблуждаетесь. Я доверяю своим оценкам с точностью до погрешности, получившимся цифрам тоже верю с точностью до погрешности.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#20
Отправлено 18 марта 2008 - 11:01
Так если менеджер не может выставить приоритеты, то он не может ничего сказать о качестве!
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных