<?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: The code freeze is killing the dinosaurs</title>
	<atom:link href="http://tynerblain.com/blog/2006/03/01/the-code-freeze-is-killing-the-dinosaurs/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/03/01/the-code-freeze-is-killing-the-dinosaurs/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sun, 12 Feb 2012 19:10:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/03/01/the-code-freeze-is-killing-the-dinosaurs/comment-page-1/#comment-467</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Mon, 20 Mar 2006 00:57:55 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/03/01/the-code-freeze-is-killing-the-dinosaurs/#comment-467</guid>
		<description>Jim, thanks for reading, and for the comments!

I completely agree with your point that there is stuff that is impractical to test in an automated fashion (impossible, not justified, etc).  I absolutely agree that a mixture of testing is appropriate, and varies from extremely automated to extremely manual - depending on the application&#039;s purpose, design, and goals.

The most important thing is that the development team shouldn&#039;t hide in a cave and write code until they think they are done, but rather incorporate testing iteratively throughout the process.  

Bricklayers check the level of each row of bricks as they go, and correct any problems as soon as they appear - they don&#039;t wait until the entire wall is finished to discover that they are an inch out of level.

Great zinger with the the bug-eating!

And thanks again, please - keep it coming and keep me honest.

Scott</description>
		<content:encoded><![CDATA[<p>Jim, thanks for reading, and for the comments!</p>
<p>I completely agree with your point that there is stuff that is impractical to test in an automated fashion (impossible, not justified, etc).  I absolutely agree that a mixture of testing is appropriate, and varies from extremely automated to extremely manual &#8211; depending on the application&#8217;s purpose, design, and goals.</p>
<p>The most important thing is that the development team shouldn&#8217;t hide in a cave and write code until they think they are done, but rather incorporate testing iteratively throughout the process.  </p>
<p>Bricklayers check the level of each row of bricks as they go, and correct any problems as soon as they appear &#8211; they don&#8217;t wait until the entire wall is finished to discover that they are an inch out of level.</p>
<p>Great zinger with the the bug-eating!</p>
<p>And thanks again, please &#8211; keep it coming and keep me honest.</p>
<p>Scott</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Hancock</title>
		<link>http://tynerblain.com/blog/2006/03/01/the-code-freeze-is-killing-the-dinosaurs/comment-page-1/#comment-459</link>
		<dc:creator>Jim Hancock</dc:creator>
		<pubDate>Sun, 19 Mar 2006 10:30:35 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/03/01/the-code-freeze-is-killing-the-dinosaurs/#comment-459</guid>
		<description>This article sounds great if we are working in an ideal world, but there are several exposures:

1) At least GUI automation testing requires script creation/maintenance AFTER the new code is created.  

2) There is some testing that is hard (or even impossible) to automate.

3) It may not be cost efficient to automate everything.

4) Manual testing often yields more complexity and diversity with regards to testing (google Exploratory Testing).  

5) Manual Testing also produces more of a &quot;user experience&quot; giving a better sense of user acceptance and a broader view of the app.

Anyway, I feel in most cases that it is important to have some mix of automation and manual testing to be most successful.  

After all, don&#039;t both reptiles and mammals eat bugs?  :)</description>
		<content:encoded><![CDATA[<p>This article sounds great if we are working in an ideal world, but there are several exposures:</p>
<p>1) At least GUI automation testing requires script creation/maintenance AFTER the new code is created.  </p>
<p>2) There is some testing that is hard (or even impossible) to automate.</p>
<p>3) It may not be cost efficient to automate everything.</p>
<p>4) Manual testing often yields more complexity and diversity with regards to testing (google Exploratory Testing).  </p>
<p>5) Manual Testing also produces more of a &#8220;user experience&#8221; giving a better sense of user acceptance and a broader view of the app.</p>
<p>Anyway, I feel in most cases that it is important to have some mix of automation and manual testing to be most successful.  </p>
<p>After all, don&#8217;t both reptiles and mammals eat bugs?  :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

