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

[count_tic]

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

[sasha1884@mail.ru]

Ну, тут как обстоят дела: если имеются баги Blocker, то о деплойменте в продакшн разработчики могут забыть. А вообще в целом, можно составить таблицу по приоритетам - от 1-Blocker, до 4-Low, чем больше багов высокого приоритета, тем меньше шансов у билда стать потенциальным клиентом на продакшен.

[Alfa]

Можно складывать количество багов с весом. Например blocker - 100 баллов, critical - 50, major - 20 и т.д.
В результате получите одно число. Если оно не превосходит некоего порога, который выясните экспериментально или методом тыка, то билд хороший. Соответственно чем число меньше, тем лучше.
Тут так же важно чтоб все участники процесса (менеджер, разработчики, тестировщики и т.д.) согласились на коэффициенты и пороговое значение, тогда от такой метрики будет толк. Она не будет объективна (она никогда такой не будет), но она не будет и субъективна с перекосом в одну из сторон.

[KaNoN]

Можно складывать количество багов с весом. Например blocker - 100 баллов, critical - 50, major - 20 и т.д.
В результате получите одно число. Если оно не превосходит некоего порога, который выясните экспериментально или методом тыка, то билд хороший. Соответственно чем число меньше, тем лучше.

Мы подобную схему применяем. Но у нас есть еще коефициент, зависящий от visibility, то есть от того, насколько часто на такой баг можно натолкнуться. Даже если баг и блокирующий, но возникает при очень хитром сочетании опций в каком-то модальном диалоге n-ного уровня, то его реальная критичность заметно ниже, чем если некорректно работает некоторый ключевой функционал. То есть баг по severity ниже, но по важности выше.

Можно еще дополнительные коефициенты ввести при необходимости. Все зависит от того, как вы можете выстроить градацию компонентов системы.

Тут так же важно чтоб все участники процесса (менеджер, разработчики, тестировщики и т.д.) согласились на коэффициенты и пороговое значение, тогда от такой метрики будет толк. Она не будет объективна (она никогда такой не будет), но она не будет и субъективна с перекосом в одну из сторон.

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

[zemljak]

Попробуйте почитать про AHP (Analytic Hierarchy Process). Например http://msdn.microsof...e/cc163785.aspx

Очень классная вещь! Позволяет сравнивать несравнимые, на первый взгляд, вещи. Так и вы - сможете оценить (сравнить) качество разных билдов.

[NeOn]

Мы подобную схему применяем. Но у нас есть еще коефициент, зависящий от visibility, то есть от того, насколько часто на такой баг можно натолкнуться. Даже если баг и блокирующий, но возникает при очень хитром сочетании опций в каком-то модальном диалоге n-ного уровня, то его реальная критичность заметно ниже, чем если некорректно работает некоторый ключевой функционал. То есть баг по severity ниже, но по важности выше.

Можно еще дополнительные коефициенты ввести при необходимости. Все зависит от того, как вы можете выстроить градацию компонентов системы.

Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают (или найдут более короткий путь), причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.

[Bars Master]

Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают, причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.

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

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

лично я советовать уже ничего не могу, буду повторяться, все что нужно посоветовали выше. Постарайтесь собрать информацию в одно целое и выбрать из неё, то что необходимо для тестирования именно вашего ПО.

[rlabs]

Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают (или найдут более короткий путь), причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.

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

Третий показатель оказывает очень сильное влияние, посколько сломать код ради исправления пусть и важной, но проявляющейся только раз в году проблемы - серьезный риск.

[Bars Master]

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

Я к чему, если есть вероятность внесения новых ошибок, в чем проблема? находятся новые ошибки и исправляются, если при каждом внесении изменений в ПО появляются критичные ошибки, то уж пардон тут дело в разработчиках.

[Alfa]

Попробуйте почитать про AHP (Analytic Hierarchy Process). Например http://msdn.microsof...e/cc163785.aspx

Очень классная вещь! Позволяет сравнивать несравнимые, на первый взгляд, вещи. Так и вы - сможете оценить (сравнить) качество разных билдов.

Подход интересный, но бесполезный в большинстве случаев. Представьте, что у вас не два билда а 10, не два параметра а 10 и попробуйте посчитать такую штуку. Нормальный человек запариться это считать, ну можно конечно заставить считать это машину. Но тут есть еще проблема погрешности. Неужели кто-то может точно выдавать оценки? Посчитайте погрешность. После этого я подозреваю (лишь подозреваю), что значашей останется только первая цифра.
А потом менеджер вас спросит каково качество билдов 1 и 2, а вы ему скажите у 1-го 0.531, а у 2-го 0.565. И что? Это соответсвует действительности? Не верю. По таким данным нельзя ничего решить, тем более если погрешность не посчитана.
Сравнивать несравниваемое не так просто, как кажется.

Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.

Возмите такие параметры, чтоб один блокирующий баг "портил" всю сборку.

Метод оценки можно придумать любой сложности: с одним, двумя, тремя и т.д. различными параметрами у багов (важность, частота и т.д.), важно чтоб эти параметры имели реальное (осмысленное) значение. Если при записи бага тестировщики заполняют поле "частота" от балды, то никакого проку от расчетов с этим полем не будет.
Я например вообще практически не различал важность(severity) у багов, но лишь до тех пор пока это поле не обрело смысл.
Когда все договорились, что важность бага влияет на то, когда баг будет исправлен, я стал проставлять его со смыслом, думая.

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

В целом при оценки качества сборки между итерациями я бы придерживался лозунга "As simple as possible, but not simpler".
Одно число дает один бит информации - выше порога или ниже порога. Хотя не имею ничего против других предложенных выше схем (кроме AHP), если они не нарушают изложенных выше соображений.

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

[rlabs]

И опять ворвусь в вашу беседу, как я считаю, тестирование это и есть как раз механизм отдалдки ПО,

Вот это здорово. Сколько сил было положено на то, чтобы тестировщиков перестали использовать как отладочный ресурс, и тут вдруг озарение.

НО нельзя пропускать ПО с важными, и даже пусть редко проявляющейся проблемой. Это редко может наступить...

Это "редко" является риском. Риски бывают всякие. Иногда ими управляют.

Я к чему, если есть вероятность внесения новых ошибок, в чем проблема? находятся новые ошибки и исправляются, если при каждом внесении изменений в ПО появляются критичные ошибки, то уж пардон тут дело в разработчиках.

Проблема вот в чем. У вас есть некоторый обещанный срок до выпуска версии. Одна или несколько не очень серьезных ошибок требуют изменения архитектуры целой подсистемы приложения. Начинающий разработчик легко даст оценку "за две недели перепишем" (это вообще волшебная величина - две недели). В реальности эти две недели оказываются двумя месяцами на саму по себе разработку, еще парой недель на перетестирование продукта, и месяцем на исправление внесенных ошибок. В результате оптимистичная попытка исправить пару юзабилити проблем выльется в провал проекта.

Это все очень утрировано, разумеется.

Смысл же в том, что на количество, важность и класс известных ошибок полагаться нельзя. Есть цель релиза, она и определяет критерии.

[Bars Master]

Вот это здорово. Сколько сил было положено на то, чтобы тестировщиков перестали использовать как отладочный ресурс, и тут вдруг озарение.

Ну собственно если брать изначально QA как должность, то она подразумевает под собой контроль качества продукта, то есть весь механизм грубо говорят свобидтся к схеме: Видение-ТТ-ТЗ-разработка-тестирование-отладка-тестирование.
естественно утрировано сильно, но смысл в этом. Что именно должность QA должна отвечать за качество продукта, продукт в релизе должен быть функционален ровно столько, сколько заявленно в ТТ, если же продукт не соотвествует ТТ, то это уже провал проекта.

Проблема вот в чем. У вас есть некоторый обещанный срок до выпуска версии. Одна или несколько не очень серьезных ошибок требуют изменения архитектуры целой подсистемы приложения. Начинающий разработчик легко даст оценку "за две недели перепишем" (это вообще волшебная величина - две недели). В реальности эти две недели оказываются двумя месяцами на саму по себе разработку, еще парой недель на перетестирование продукта, и месяцем на исправление внесенных ошибок. В результате оптимистичная попытка исправить пару юзабилити проблем выльется в провал проекта.

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

[KaNoN]

Мы подобную схему применяем. Но у нас есть еще коефициент, зависящий от visibility, то есть от того, насколько часто на такой баг можно натолкнуться. Даже если баг и блокирующий, но возникает при очень хитром сочетании опций в каком-то модальном диалоге n-ного уровня, то его реальная критичность заметно ниже, чем если некорректно работает некоторый ключевой функционал. То есть баг по severity ниже, но по важности выше.

Можно еще дополнительные коефициенты ввести при необходимости. Все зависит от того, как вы можете выстроить градацию компонентов системы.

Вот не согласен я с подходом коэффициентов. По крайней мере в отношении блокирующих.
Баг - есть баг. И даже если для его воспроизведения придется 256 раз ткнуть мышом в пустое место на экране - будьте уверены, пользователи именно так и сделают (или найдут более короткий путь), причем гораздо быстрее, чем вы думаете.
В релизе пользователям таких багов быть не должно. Тем более если речь идет о биллинге или прочих "деньгосчитающих" системах.

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

[KaNoN]

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

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

Я к чему, если есть вероятность внесения новых ошибок, в чем проблема? находятся новые ошибки и исправляются, если при каждом внесении изменений в ПО появляются критичные ошибки, то уж пардон тут дело в разработчиках.

Дело в том, что сроки могут быть ограничены и в ваших же интересах расставить какие-то приоритеты и учитывать то, что некоторые баги все-таки в этой версии будут, так как на их исправление времени нехватает. А постоянное прокручивание тестирования может серьезно отложить выход продукта на рынок, что однажды приведет к тому, что этот продукт будет работать и с меньшими огрехами, чем продукт конкурентов, но он уже не будет востребован, так как ниша уже занята. Время много чего ограничивает

[zemljak]

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

Вы просто до конца не разобрались :) Количество билдов в наш 21 век роли не играет - за вас все будет считать машина. Да и про какую погрешность вы говорите - вы же сами расставляете коэффициенты. Пусть за вас это сделает менеджер - да неважно кто, важна суть.

А потом менеджер вас спросит каково качество билдов 1 и 2, а вы ему скажите у 1-го 0.531, а у 2-го 0.565. И что? Это соответсвует действительности? Не верю. По таким данным нельзя ничего решить, тем более если погрешность не посчитана.
Сравнивать несравниваемое не так просто, как кажется.

Ну не верьте, никто же вас не заставляет :) Только учтите, что данный метод - чисто математический, и если вы не верите получившимся цифрам - то нет доверия и собственным оценкам. О какой оценке качества тогда может идти речь?

[Bars Master]

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

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

[origin]

На все случаи жизни совета тут дать явно не получится. Критерии оценки "годности" билда каждым отделом тестирования выделяются свои, причем, основанные на оценке рисков, как правильно заметил rlabs. К примеру, даже с блокирующим багом, на котором приложение периодически валится с несохранением данных и стоит такой обвал, к примеру, 1000 долларов, своевременное вхождение на рынок этого ПО может принести более миллиона этих самых вечнозеленых. И продактить/нет такой билд уже решается не только тестировщиками, как я думаю. К примеру, имеет смысл субъективно расчиывать для каждого бага величину "потенциального ущерба" (Х), основанную на субъективных факторах ("раздражающей способности" для багов в ГИП, к примеру) и создать примерную шкалу этой величины (0-10). Далее - уровень самих багов (Y), от Low (1) до Urgent (5). Результирующий вес считать как Sum (X*Y). При этом вес даже Low - бага с ужасающим "раздражителем" может быть больше веса бага высокого приоритета, повторяющегося эпизодически и потенциально менее опасного.

Повторюсь, такая оценка будет субъективной, но более адекватной, нежели просто ранжировать по уровню приоритета инцидентов.

[saezar]

Я работаю с тремя параметрами:
I . Серьёзность - заполняет тестировщик исходя из своего здравого смысла и руководствуясь такой табличкой:

1. Малый – Косметические дефекты, опечатки.
2. Средний - Дефект, проявляющийся в неправильной работе функциональности
3. Большой - Дефект, проявляющийся в отказе функциональности
4. Критический – Дефект, приводящий к сбою в работе ПО, но не вызывающий фатальных последствий.
5. Фатальный – Дефект, приводящий к непредвиденному разрушению баз данных, порче файлов, поломке или зависанию операционной среды и.т.д.

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

III. Важность требования. Это заполняется при разработке требований, тем кто их разрабатывает.

В результате, Получаем матрицу, по Х - серьёзность, по У - важность требований, в пересечении количество дефектов. Весовые коэффициенты на каждую "серьёзность" у меня пока не выработаны окончательно, это скорее статистические данные по предыдущим разработкам. Приоритет в данном случае является неким поправочным коэффициентом, влияющим на важность. Ибо 150 грамматических ошибок в приложении типа Sovereign Application имеют приоритет выше чем "средний" дефект в требовании с низкой важностью.

Перемножая Важность, Серьёзность, Вес, Количество и суммируя их все мы можем получить некий "Вес дефектов ПО". К нему уже можно присматриваться и оценивать. Понятно, что весовые коэфициенты могут и даже должны корректироваться.

[Alfa]

Вы просто до конца не разобрались :) Количество билдов в наш 21 век роли не играет - за вас все будет считать машина. Да и про какую погрешность вы говорите - вы же сами расставляете коэффициенты. Пусть за вас это сделает менеджер - да неважно кто, важна суть.

Да машина все хорошо посчитает, полностью согласен. И суть важна. Но суть в том, что нет никакой гарантии, что производительность составляет 0.200 от общего качества сборки, а не 0.201 или 0.250. Это и называется погрешность. Даже менеджер не может (о боже!) точно сказать каково это число, он всегда ошибется. Если предположить, что каждое значение в данном методе вы получаете с точностью 10% (что на мой взгляд хорошо), то итоговая погрешность для приведенного случая будет не ниже 17% (будет выше).
Т.е. в приведеном примере надо писать (приблизительно) Build A is 0.5+-0.1, Build C is 0.33+-0.6 и т.д.
В этом случае отличие двух сборок не так очевидно. Не так ли?

Только учтите, что данный метод - чисто математический, и если вы не верите получившимся цифрам - то нет доверия и собственным оценкам. О какой оценке качества тогда может идти речь?

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

[zemljak]

2Alfa.

Так если менеджер не может выставить приоритеты, то он не может ничего сказать о качестве!