<?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: Testing Clichés Part II &#8211; Testing should be separate from development</title>
	<atom:link href="http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/feed/" rel="self" type="application/rss+xml" />
	<link>http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/</link>
	<description>by rikard edgren, henrik emilsson, martin jansson and friends</description>
	<lastBuildDate>Thu, 19 Aug 2010 13:06:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Rikard Edgren</title>
		<link>http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/comment-page-1/#comment-290</link>
		<dc:creator>Rikard Edgren</dc:creator>
		<pubDate>Fri, 29 Jan 2010 16:00:22 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=773#comment-290</guid>
		<description>Saam, very good point! It&#039;s &quot;the whole&quot; that matters, and I have never heard someone say &quot;developers should be separated from testing&quot;

Chad, more defects are found during system testing because defects can not be seen (as easily) when looking at component level.
And the intention of system testing is to find out how the system works, the separation is just a means that some people came up with because they had seen, or were afraid of biased testers that don&#039;t truly want to find errors.
But you are right that you can become too involved with the features, but I see that as a risk to mitigate by being aware of it.
But the details might not be so important, the open communication is what is needed.

Joe, I agree, and the honest experimenting might be the best, maybe by switching between tight and loose integration every second year.

Emile, I also sit in a room with testers and it works really good.
As long as testers and developers are within a minute away, you have a chance of effective communication.</description>
		<content:encoded><![CDATA[<p>Saam, very good point! It&#8217;s &#8220;the whole&#8221; that matters, and I have never heard someone say &#8220;developers should be separated from testing&#8221;</p>
<p>Chad, more defects are found during system testing because defects can not be seen (as easily) when looking at component level.<br />
And the intention of system testing is to find out how the system works, the separation is just a means that some people came up with because they had seen, or were afraid of biased testers that don&#8217;t truly want to find errors.<br />
But you are right that you can become too involved with the features, but I see that as a risk to mitigate by being aware of it.<br />
But the details might not be so important, the open communication is what is needed.</p>
<p>Joe, I agree, and the honest experimenting might be the best, maybe by switching between tight and loose integration every second year.</p>
<p>Emile, I also sit in a room with testers and it works really good.<br />
As long as testers and developers are within a minute away, you have a chance of effective communication.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Saam</title>
		<link>http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/comment-page-1/#comment-289</link>
		<dc:creator>Saam</dc:creator>
		<pubDate>Thu, 28 Jan 2010 23:29:37 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=773#comment-289</guid>
		<description>As I see it, this is not a matter of what is most effective from a test perspective. I think other aspects, such as what approach is most effective in providing the fastest turn-around from fault found to problem fixed, are more interesting here. However, in the end it comes down to what you write - achieving better end results togheter.</description>
		<content:encoded><![CDATA[<p>As I see it, this is not a matter of what is most effective from a test perspective. I think other aspects, such as what approach is most effective in providing the fastest turn-around from fault found to problem fixed, are more interesting here. However, in the end it comes down to what you write &#8211; achieving better end results togheter.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chad Patrick</title>
		<link>http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/comment-page-1/#comment-288</link>
		<dc:creator>Chad Patrick</dc:creator>
		<pubDate>Thu, 28 Jan 2010 14:56:23 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=773#comment-288</guid>
		<description>If this was the case, wouldn&#039;t we see a higher percentage of defects found during unit/component testing?  That is developer testing.  System testing is intended to be segregated.  I&#039;m not saying developers don&#039;t make good testers, quite the opposite.  Some of my best testers were solid developers.  However, when the two are too closely coupled, I&#039;ve seen complacency take over and when you know each other a little too well, documentation starts to slack because testers &#039;read between the lines&#039;.

Open communication between the two is great and to be encouraged, but I still believe it&#039;s better to have a healthy level of separation.</description>
		<content:encoded><![CDATA[<p>If this was the case, wouldn&#8217;t we see a higher percentage of defects found during unit/component testing?  That is developer testing.  System testing is intended to be segregated.  I&#8217;m not saying developers don&#8217;t make good testers, quite the opposite.  Some of my best testers were solid developers.  However, when the two are too closely coupled, I&#8217;ve seen complacency take over and when you know each other a little too well, documentation starts to slack because testers &#8216;read between the lines&#8217;.</p>
<p>Open communication between the two is great and to be encouraged, but I still believe it&#8217;s better to have a healthy level of separation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Strazzere</title>
		<link>http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/comment-page-1/#comment-287</link>
		<dc:creator>Joe Strazzere</dc:creator>
		<pubDate>Thu, 28 Jan 2010 14:38:22 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=773#comment-287</guid>
		<description>Good points, all.

In the right situation, all sorts of degrees of separation between Testing and Development can work.

And in the wrong situation, all sorts of degrees of separation between Testing and Development can fail.

Experimenting with different models, understanding the potential pitfalls of each,  and being honest about the outcomes, seems to have been the best approach for me.</description>
		<content:encoded><![CDATA[<p>Good points, all.</p>
<p>In the right situation, all sorts of degrees of separation between Testing and Development can work.</p>
<p>And in the wrong situation, all sorts of degrees of separation between Testing and Development can fail.</p>
<p>Experimenting with different models, understanding the potential pitfalls of each,  and being honest about the outcomes, seems to have been the best approach for me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Emile Zwiggelaar</title>
		<link>http://thetesteye.com/blog/2010/01/testing-cliches-part-ii-testing-should-be-separate-from-development/comment-page-1/#comment-286</link>
		<dc:creator>Emile Zwiggelaar</dc:creator>
		<pubDate>Thu, 28 Jan 2010 13:34:34 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=773#comment-286</guid>
		<description>This is a subject that has come up in the team that I work in several times (and will be back for sure).

We (as testers) feel strongly that knowing &#039;everything&#039; will lower our level of objectiveness in our testwork. This would be the case when we would be sitting in the same room as the developers.

So we favour the situation as we have now where all testers from similar projects are sitting close to each other (same room) and the developers are nearby to obtain all information needed. Still working together with them and exchanging knowledge but some seperation as well.

Maybe the type and or size  of project makes a difference in whether or not testers should sit with developers.......</description>
		<content:encoded><![CDATA[<p>This is a subject that has come up in the team that I work in several times (and will be back for sure).</p>
<p>We (as testers) feel strongly that knowing &#8216;everything&#8217; will lower our level of objectiveness in our testwork. This would be the case when we would be sitting in the same room as the developers.</p>
<p>So we favour the situation as we have now where all testers from similar projects are sitting close to each other (same room) and the developers are nearby to obtain all information needed. Still working together with them and exchanging knowledge but some seperation as well.</p>
<p>Maybe the type and or size  of project makes a difference in whether or not testers should sit with developers&#8230;&#8230;.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
