<?xml version="1.0" encoding="WINDOWS-1251"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Комментарии на запись: Анализ динамики критичности дефектов</title>
	<link>http://blog.shumoos.com/archives/221</link>
	<description>Блог об управлении, модульных тестах, аналитике и пр.</description>
	<pubDate>Sun, 20 May 2012 18:28:29 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>от: SALar</title>
		<link>http://blog.shumoos.com/archives/221#comment-443</link>
		<pubDate>Tue, 27 Apr 2010 17:29:59 +0000</pubDate>
		<guid>http://blog.shumoos.com/archives/221#comment-443</guid>
					<description>1. Важность и критичность - разные атрибуты. Использовать один атрибут проще, но в статье приведена достаточно сложная система анализа. 
Есть много способов управления дефектами и есть много способов анализа. Часть из них мне известна, и часть мной описана. Я не говорю, что это панацея, это просто это один из возможных способов анализа. Кстати, не самый лучший. 
2 и 3. Это один из способов приведения к "общему знаменателю".  Это способ оценить что хуже, один "критикал" или десять миноров. Применимо не ко всем проектам, но иногда можно использовать. 
Честно предупреждаю, что не всегда.

&gt; Наблюдать за фактическим ходом тестирования конечно интересно, но вот куда более интересна методика прогнозирования продолжительности этапа стабилизации для очередного инкремента продукта. Есть у Вас подобные методики или практики? 
Да. Мои оценки сходились с точностью порядка 10% (возможно случайность, но было и есть). При этом мои оценки сильно расходились с оценкой других заинтересованных лиц проекта и были, как правило, более точными.
Не все методики я пока могу описать или передать. Т.е. часть этих знаний - это мой опыт. К моему глубокому сожалению, пока неотделимый от меня.

PS. Вы очень правильно выделили одну из возможностей использовать группу тестирования. Оценка срока пригодности продукта. Это отдельная, как правило, не озвучиваемая цель. 
Примите знак моего уважения перед вашим опытом.</description>
		<content:encoded><![CDATA[<p>1. Важность и критичность - разные атрибуты. Использовать один атрибут проще, но в статье приведена достаточно сложная система анализа.<br />
Есть много способов управления дефектами и есть много способов анализа. Часть из них мне известна, и часть мной описана. Я не говорю, что это панацея, это просто это один из возможных способов анализа. Кстати, не самый лучший.<br />
2 и 3. Это один из способов приведения к &#8220;общему знаменателю&#8221;.  Это способ оценить что хуже, один &#8220;критикал&#8221; или десять миноров. Применимо не ко всем проектам, но иногда можно использовать.<br />
Честно предупреждаю, что не всегда.</p>
<p>> Наблюдать за фактическим ходом тестирования конечно интересно, но вот куда более интересна методика прогнозирования продолжительности этапа стабилизации для очередного инкремента продукта. Есть у Вас подобные методики или практики?<br />
Да. Мои оценки сходились с точностью порядка 10% (возможно случайность, но было и есть). При этом мои оценки сильно расходились с оценкой других заинтересованных лиц проекта и были, как правило, более точными.<br />
Не все методики я пока могу описать или передать. Т.е. часть этих знаний - это мой опыт. К моему глубокому сожалению, пока неотделимый от меня.</p>
<p>PS. Вы очень правильно выделили одну из возможностей использовать группу тестирования. Оценка срока пригодности продукта. Это отдельная, как правило, не озвучиваемая цель.<br />
Примите знак моего уважения перед вашим опытом.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>от: saveug</title>
		<link>http://blog.shumoos.com/archives/221#comment-441</link>
		<pubDate>Mon, 26 Apr 2010 09:12:46 +0000</pubDate>
		<guid>http://blog.shumoos.com/archives/221#comment-441</guid>
					<description>Возникло несколько вопросов:

1. Я так и не понял смысла введения дополнительного атрибута для определения важности, если таблица 1 изначально была построена на основе приоритета к исправлению (то есть критичности), зачем вообще при тестировании анализировать приоритет планирования? Не проще ли использовать один приоритет, который соответствует важности бага при заведении его тестировщиком?

2. Не очень понял разницу между рис. 2 и рис. 3, они отображают практически одно и то же, однако для рис. 3 требуются какие-то дополнительные телодвижения (умные фразы и т.п.) Из рис. 2 уже видно, что нет критикал и совсем мало мейджоров, видим сходимость стабилизации, зачем еще какие-то замуты?

И вот еще вопрос:

Наблюдать за фактическим ходом тестирования конечно интересно, но вот куда более интересна методика прогнозирования продолжительности этапа стабилизации для очередного инкремента продукта. Есть у Вас подобные методики или практики?</description>
		<content:encoded><![CDATA[<p>Возникло несколько вопросов:</p>
<p>1. Я так и не понял смысла введения дополнительного атрибута для определения важности, если таблица 1 изначально была построена на основе приоритета к исправлению (то есть критичности), зачем вообще при тестировании анализировать приоритет планирования? Не проще ли использовать один приоритет, который соответствует важности бага при заведении его тестировщиком?</p>
<p>2. Не очень понял разницу между рис. 2 и рис. 3, они отображают практически одно и то же, однако для рис. 3 требуются какие-то дополнительные телодвижения (умные фразы и т.п.) Из рис. 2 уже видно, что нет критикал и совсем мало мейджоров, видим сходимость стабилизации, зачем еще какие-то замуты?</p>
<p>И вот еще вопрос:</p>
<p>Наблюдать за фактическим ходом тестирования конечно интересно, но вот куда более интересна методика прогнозирования продолжительности этапа стабилизации для очередного инкремента продукта. Есть у Вас подобные методики или практики?
</p>
]]></content:encoded>
				</item>
</channel>
</rss>

