<?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: Where Bugs Come From</title>
	<atom:link href="http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/</link>
	<description>Software product success.</description>
	<lastBuildDate>Tue, 16 Mar 2010 02:37:05 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: lean manufacturing software</title>
		<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/comment-page-1/#comment-282365</link>
		<dc:creator>lean manufacturing software</dc:creator>
		<pubDate>Thu, 31 Jan 2008 09:07:28 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/#comment-282365</guid>
		<description>&lt;strong&gt;lean manufacturing software...&lt;/strong&gt;

We have very much promoted this type of business practice ourselves and am glad I came across your blog again. I have added you to our digg bookmarking account. Thanks!...</description>
		<content:encoded><![CDATA[<p><strong>lean manufacturing software&#8230;</strong></p>
<p>We have very much promoted this type of business practice ourselves and am glad I came across your blog again. I have added you to our digg bookmarking account. Thanks!&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Software requirements - process and roles -Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/comment-page-1/#comment-285</link>
		<dc:creator>Software requirements - process and roles -Tyner Blain</dc:creator>
		<pubDate>Tue, 14 Feb 2006 00:25:26 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/#comment-285</guid>
		<description>[...] Note that there are also steps involved in assuring the quality of the solution, and feedback loops in a good software development process. We covered this in our earlier post, Where bugs come from. We&#8217;ve also talked in more detail about the software development process in our post, Describing the software development process. In order to keep this discussion on task, we&#8217;ve simplified our presentation of that material in this post. [...]</description>
		<content:encoded><![CDATA[<p>[...] Note that there are also steps involved in assuring the quality of the solution, and feedback loops in a good software development process. We covered this in our earlier post, Where bugs come from. We&#8217;ve also talked in more detail about the software development process in our post, Describing the software development process. In order to keep this discussion on task, we&#8217;ve simplified our presentation of that material in this post. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Software testing series: Top three measurements of quality -Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/comment-page-1/#comment-207</link>
		<dc:creator>Software testing series: Top three measurements of quality -Tyner Blain</dc:creator>
		<pubDate>Fri, 03 Feb 2006 03:40:23 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/#comment-207</guid>
		<description>[...] This developer perspective is a little misleading, however. To developers, if the software performs according to the spec, it meets the requirements, and is therefore good software. To a product manager, this could represent one of several requirements writing mistakes - the missing behavior should be there but it isn&#8217;t, because it was not documented in the spec. In short, the source of this bug is in the requirements. [...]</description>
		<content:encoded><![CDATA[<p>[...] This developer perspective is a little misleading, however. To developers, if the software performs according to the spec, it meets the requirements, and is therefore good software. To a product manager, this could represent one of several requirements writing mistakes &#8211; the missing behavior should be there but it isn&#8217;t, because it was not documented in the spec. In short, the source of this bug is in the requirements. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Requirements and software development process and where bugs come from --Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/comment-page-1/#comment-140</link>
		<dc:creator>Requirements and software development process and where bugs come from --Tyner Blain</dc:creator>
		<pubDate>Wed, 25 Jan 2006 00:36:48 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/#comment-140</guid>
		<description>[...] [Ed: This post was retitled, edited, and updated as Where bugs come from due to recurring issues for some readers with accessing this page. Please read the updated version (there are some revisions to the content and new links to other content). Thanks] [...]</description>
		<content:encoded><![CDATA[<p>[...] [Ed: This post was retitled, edited, and updated as Where bugs come from due to recurring issues for some readers with accessing this page. Please read the updated version (there are some revisions to the content and new links to other content). Thanks] [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Software testing series: Introduction --Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/comment-page-1/#comment-139</link>
		<dc:creator>Software testing series: Introduction --Tyner Blain</dc:creator>
		<pubDate>Wed, 25 Jan 2006 00:34:38 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/#comment-139</guid>
		<description>[...] We can analyze the costs (and benefits) of testing. We can make our tests efficient to run, or focus on minimizing their maintenance costs. We can apply theory to identify what to test and use statistics to characterize the quality of software. We can try to understand where bugs come from. In our series, we will touch on many of these topics and link to some of the better articles from experts out there. [...]</description>
		<content:encoded><![CDATA[<p>[...] We can analyze the costs (and benefits) of testing. We can make our tests efficient to run, or focus on minimizing their maintenance costs. We can apply theory to identify what to test and use statistics to characterize the quality of software. We can try to understand where bugs come from. In our series, we will touch on many of these topics and link to some of the better articles from experts out there. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Fixing the requirements mess</title>
		<link>http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/comment-page-1/#comment-130</link>
		<dc:creator>Tyner Blain &#187; Fixing the requirements mess</dc:creator>
		<pubDate>Sun, 22 Jan 2006 21:33:29 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/22/where-bugs-come-from/#comment-130</guid>
		<description>[...] Stephen Larrison posted an article in his blog, Survive Outsourcing, about how to compete with offshore-outsourced projects by fixing the requirements mess up front. His background in manufacturing, as well as software development has lead him to a similar perspective as the one I touched briefly on in my post about where bugs come from. [...]</description>
		<content:encoded><![CDATA[<p>[...] Stephen Larrison posted an article in his blog, Survive Outsourcing, about how to compete with offshore-outsourced projects by fixing the requirements mess up front. His background in manufacturing, as well as software development has lead him to a similar perspective as the one I touched briefly on in my post about where bugs come from. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
