 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to identify creative test cases which finds unique bugs and accelerates the quality product releases to the market?</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/how-to-identify-creative-test-cases-which-finds-unique-bugs-and-accelerates-the-quality-product-releases-to-the-market/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/how-to-identify-creative-test-cases-which-finds-unique-bugs-and-accelerates-the-quality-product-releases-to-the-market/</link>
	<description></description>
	<lastBuildDate>Tue, 21 May 2013 13:34:32 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: shillu13</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/how-to-identify-creative-test-cases-which-finds-unique-bugs-and-accelerates-the-quality-product-releases-to-the-market/#comment-83157</link>
		<dc:creator>shillu13</dc:creator>
		<pubDate>Tue, 02 Nov 2010 15:12:38 +0000</pubDate>
		<guid isPermaLink="false">#comment-83157</guid>
		<description><![CDATA[good info... risk ranking is a way to go about seeing what areas needs to be tested]]></description>
		<content:encoded><![CDATA[<p>good info&#8230; risk ranking is a way to go about seeing what areas needs to be tested</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: saimadhu</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/how-to-identify-creative-test-cases-which-finds-unique-bugs-and-accelerates-the-quality-product-releases-to-the-market/#comment-58250</link>
		<dc:creator>saimadhu</dc:creator>
		<pubDate>Tue, 02 Dec 2008 12:38:47 +0000</pubDate>
		<guid isPermaLink="false">#comment-58250</guid>
		<description><![CDATA[Thanks Donmillion for the detailed info and references. I will go thru these references.]]></description>
		<content:encoded><![CDATA[<p>Thanks Donmillion for the detailed info and references. I will go thru these references.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: donmillion</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/how-to-identify-creative-test-cases-which-finds-unique-bugs-and-accelerates-the-quality-product-releases-to-the-market/#comment-58249</link>
		<dc:creator>donmillion</dc:creator>
		<pubDate>Tue, 02 Dec 2008 11:44:55 +0000</pubDate>
		<guid isPermaLink="false">#comment-58249</guid>
		<description><![CDATA[I suppose it depends on what you mean by &quot;unique bugs&quot;, Saimadhu.  I think perhaps you&#039;re asking for a technique that delivers &quot;one bug per test case, one test case per bug&quot; (assuming the bugs are there to find).  The fact is that any test case may stumble across bugs that it wasn&#039;t designed to find, but it&#039;s still possible to design test cases to look for specific bugs.

Glen Myers described such an approach in his 1979 classic, &lt;i&gt;The Art of Software Testing&lt;/i&gt; (revised edition 2004, I think).  He called it, &quot;High-Yield Testing&quot;, the idea being that well-designed testing can find a relatively high &quot;yield&quot; of bugs for a relatively low &quot;investment&quot; of test cases.  Studies in white-box testing by Horgan, London, and Lyu, and in black-box testing by Bender, showed that testers lacking these techniques typically required twice as many test cases to find the same quantity of bugs as testers using the techniques.

One part of &quot;high-yield&quot; testing is to use test techniques that address the risks present in the software.   For example, use: boundary value testing to trap boundary bugs; equivalence partition testing to trap data class bugs; cause-effect graphs to trap combinatorial logic bugs; syntax testing to trap compositional rule bugs; statement testing to trap computational bugs; and so on.

Another part is the concept of &quot;basis set&quot; testing, which originated in the 1920s with electricians trying to find a minimal set of test cases that would isolate the location of a break in a complex circuit.  Beizer calls it the &quot;scientific test technique&quot;, in which, from test case to test case, you change one factor at a time until all relevant &quot;factors&quot; have been tested both positively and negatively.  In process-based testing, for example, you start with the shortest, simplest path from the start of the process to an exit point, then vary one decision at a time until all decision outcomes have been individually tested.  This will normally produce a relatively small test set (maximum &lt;i&gt;n&lt;/i&gt;+1 paths, where &lt;i&gt;n&lt;/i&gt; is the number of decisions in the process) which covers all statements and decisions in the process in such a way that the failure of any test case isolates the probable location of the defect.

These techniques can be applied to both black-box testing (from specifications) and white-box testing (from code).  Combining the two approaches--test modelling techniques targeted at specific &lt;i&gt;types&lt;/i&gt; of bug, and test design techniques that minimise debug time by isolating bug &lt;i&gt;locations&lt;/i&gt;--is probably as close as we can come to &quot;test cases which find UNIQUE bugs and help accelerate time-to-market&quot;.

Regards,

-- Don]]></description>
		<content:encoded><![CDATA[<p>I suppose it depends on what you mean by &#8220;unique bugs&#8221;, Saimadhu.  I think perhaps you&#8217;re asking for a technique that delivers &#8220;one bug per test case, one test case per bug&#8221; (assuming the bugs are there to find).  The fact is that any test case may stumble across bugs that it wasn&#8217;t designed to find, but it&#8217;s still possible to design test cases to look for specific bugs.</p>
<p>Glen Myers described such an approach in his 1979 classic, <i>The Art of Software Testing</i> (revised edition 2004, I think).  He called it, &#8220;High-Yield Testing&#8221;, the idea being that well-designed testing can find a relatively high &#8220;yield&#8221; of bugs for a relatively low &#8220;investment&#8221; of test cases.  Studies in white-box testing by Horgan, London, and Lyu, and in black-box testing by Bender, showed that testers lacking these techniques typically required twice as many test cases to find the same quantity of bugs as testers using the techniques.</p>
<p>One part of &#8220;high-yield&#8221; testing is to use test techniques that address the risks present in the software.   For example, use: boundary value testing to trap boundary bugs; equivalence partition testing to trap data class bugs; cause-effect graphs to trap combinatorial logic bugs; syntax testing to trap compositional rule bugs; statement testing to trap computational bugs; and so on.</p>
<p>Another part is the concept of &#8220;basis set&#8221; testing, which originated in the 1920s with electricians trying to find a minimal set of test cases that would isolate the location of a break in a complex circuit.  Beizer calls it the &#8220;scientific test technique&#8221;, in which, from test case to test case, you change one factor at a time until all relevant &#8220;factors&#8221; have been tested both positively and negatively.  In process-based testing, for example, you start with the shortest, simplest path from the start of the process to an exit point, then vary one decision at a time until all decision outcomes have been individually tested.  This will normally produce a relatively small test set (maximum <i>n</i>+1 paths, where <i>n</i> is the number of decisions in the process) which covers all statements and decisions in the process in such a way that the failure of any test case isolates the probable location of the defect.</p>
<p>These techniques can be applied to both black-box testing (from specifications) and white-box testing (from code).  Combining the two approaches&#8211;test modelling techniques targeted at specific <i>types</i> of bug, and test design techniques that minimise debug time by isolating bug <i>locations</i>&#8211;is probably as close as we can come to &#8220;test cases which find UNIQUE bugs and help accelerate time-to-market&#8221;.</p>
<p>Regards,</p>
<p>&#8211; Don</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sundeepm</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/how-to-identify-creative-test-cases-which-finds-unique-bugs-and-accelerates-the-quality-product-releases-to-the-market/#comment-58215</link>
		<dc:creator>sundeepm</dc:creator>
		<pubDate>Mon, 01 Dec 2008 14:40:07 +0000</pubDate>
		<guid isPermaLink="false">#comment-58215</guid>
		<description><![CDATA[Well there are techniques that could help:
1. Orthogonal Array testing technique : This will definitely limit the number of test cases you need to execute and is
and excellent technique.
2. Decision Coverage and Path Coverage techniques: ensures good coverage of all work flows an application can take

--Sundeep]]></description>
		<content:encoded><![CDATA[<p>Well there are techniques that could help:<br />
1. Orthogonal Array testing technique : This will definitely limit the number of test cases you need to execute and is<br />
and excellent technique.<br />
2. Decision Coverage and Path Coverage techniques: ensures good coverage of all work flows an application can take</p>
<p>&#8211;Sundeep</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 3/10 queries in 0.047 seconds using memcached
Object Caching 309/315 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-21 13:36:05 -->