<?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: Manual Testing Is a Must</title>
	<atom:link href="http://blog.brodzinski.com/2010/03/manual-testing.html/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.brodzinski.com/2010/03/manual-testing.html</link>
	<description>Dealing with software projects in real life</description>
	<lastBuildDate>Fri, 10 Feb 2012 19:07:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5495</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Mon, 15 Mar 2010 21:17:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5495</guid>
		<description>George,

I should have added &quot;written&quot; or &quot;specified&quot; before &quot;the plan.&quot; Yes, good tester will have some plan in their head but I don&#039;t think they&#039;ll start with writing it down and follow it as a checklist. And from a perspective of a project as a whole plan which can&#039;t be articulated in any way isn&#039;t really a plan. No one can do anything with such thing.

On the other hand there can be detailed plan, i.e. extensive list of test cases, which is given to the testers and they&#039;re expected to check it all, case by case. They don&#039;t come up with it.</description>
		<content:encoded><![CDATA[<p>George,</p>
<p>I should have added &#8220;written&#8221; or &#8220;specified&#8221; before &#8220;the plan.&#8221; Yes, good tester will have some plan in their head but I don&#8217;t think they&#8217;ll start with writing it down and follow it as a checklist. And from a perspective of a project as a whole plan which can&#8217;t be articulated in any way isn&#8217;t really a plan. No one can do anything with such thing.</p>
<p>On the other hand there can be detailed plan, i.e. extensive list of test cases, which is given to the testers and they&#8217;re expected to check it all, case by case. They don&#8217;t come up with it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: George Dinwiddie</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5493</link>
		<dc:creator>George Dinwiddie</dc:creator>
		<pubDate>Mon, 15 Mar 2010 20:34:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5493</guid>
		<description>I&#039;m curious about the statement, &quot;Experienced quality engineer with no plan at all will do way better job than poor or inexperienced tester with the best plan. &quot;

I&#039;m not sure how an good, experienced tester could have &quot;no plan&quot; even if unable to articulate that plan to you.

And I&#039;m not sure how a tester who can come up with &quot;the best plan&quot; can be considered poor.</description>
		<content:encoded><![CDATA[<p>I&#8217;m curious about the statement, &#8220;Experienced quality engineer with no plan at all will do way better job than poor or inexperienced tester with the best plan. &#8221;</p>
<p>I&#8217;m not sure how an good, experienced tester could have &#8220;no plan&#8221; even if unable to articulate that plan to you.</p>
<p>And I&#8217;m not sure how a tester who can come up with &#8220;the best plan&#8221; can be considered poor.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5229</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Thu, 11 Mar 2010 19:11:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5229</guid>
		<description>Yes, the more you move onto automatic testing the less effort your testers spend on assuring you keep quality in simple things. For me automatic testing is a king when in comes to regression. If every bug fix consist not only a fix but also a unit test (or a couple of them) which verify problematic situation we can easily to forget the thing during manual testing.

This allows us more to go free ride during manual tests which is more fun for testers and yields much more interesting results, i.e. revealing basically all hard-core bugs we find.</description>
		<content:encoded><![CDATA[<p>Yes, the more you move onto automatic testing the less effort your testers spend on assuring you keep quality in simple things. For me automatic testing is a king when in comes to regression. If every bug fix consist not only a fix but also a unit test (or a couple of them) which verify problematic situation we can easily to forget the thing during manual testing.</p>
<p>This allows us more to go free ride during manual tests which is more fun for testers and yields much more interesting results, i.e. revealing basically all hard-core bugs we find.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marek Kirejczyk</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5227</link>
		<dc:creator>Marek Kirejczyk</dc:creator>
		<pubDate>Thu, 11 Mar 2010 18:56:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5227</guid>
		<description>True, true, manual testing is always a must, 3 times yes! Automated testing is great, can reduce manual testing 10 times, but in the end someone has to click on it. 
In fact if you want to be agile and be able to release every 1-2 weeks to the production, you need all of this unit testing (tdd strongly recommended), some automated acceptance testing (including all target platforms), code review and still some manual testing for each feature and moreover some manual testing for regression. 

And this is exacly what good agile teams does. Many scrum teams are able to release every sprint banking software or life critical software to medical hardware all over the planet.

Thanks to great automated tests on many levels. But in the end there is always a guy clicking on the machine, checking if things still make sens.</description>
		<content:encoded><![CDATA[<p>True, true, manual testing is always a must, 3 times yes! Automated testing is great, can reduce manual testing 10 times, but in the end someone has to click on it.<br />
In fact if you want to be agile and be able to release every 1-2 weeks to the production, you need all of this unit testing (tdd strongly recommended), some automated acceptance testing (including all target platforms), code review and still some manual testing for each feature and moreover some manual testing for regression. </p>
<p>And this is exacly what good agile teams does. Many scrum teams are able to release every sprint banking software or life critical software to medical hardware all over the planet.</p>
<p>Thanks to great automated tests on many levels. But in the end there is always a guy clicking on the machine, checking if things still make sens.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5226</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Thu, 11 Mar 2010 18:13:20 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5226</guid>
		<description>Thoralf,

Of course there is no conflict between automatic and manual testing. Of course it is better to have them both and each in at least a few flavors. However we&#039;re often tempted to switch purely to these cool techniques which makes the code self-testing. Sometimes you will even find people advising you to do so.

And this is just stupid. While manual testing is expensive it is also indispensable. At least this is what I believe in.</description>
		<content:encoded><![CDATA[<p>Thoralf,</p>
<p>Of course there is no conflict between automatic and manual testing. Of course it is better to have them both and each in at least a few flavors. However we&#8217;re often tempted to switch purely to these cool techniques which makes the code self-testing. Sometimes you will even find people advising you to do so.</p>
<p>And this is just stupid. While manual testing is expensive it is also indispensable. At least this is what I believe in.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5225</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Thu, 11 Mar 2010 18:09:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5225</guid>
		<description>Phil,

Maybe I haven&#039;t stressed it enough but when I think manual testing I think very good manual testing. If I have testers who are going to work like mindless golems and just blindly follow test scenarios I guess I can exchange them with one developer who would write some automatic tests and I will be a good deal.

However when you think about one of these die-hard tester who can sense a bug in a distance of hundred meters I wouldn&#039;t exchange them pretty much for anything.</description>
		<content:encoded><![CDATA[<p>Phil,</p>
<p>Maybe I haven&#8217;t stressed it enough but when I think manual testing I think very good manual testing. If I have testers who are going to work like mindless golems and just blindly follow test scenarios I guess I can exchange them with one developer who would write some automatic tests and I will be a good deal.</p>
<p>However when you think about one of these die-hard tester who can sense a bug in a distance of hundred meters I wouldn&#8217;t exchange them pretty much for anything.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thoralf Klatt</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5222</link>
		<dc:creator>Thoralf Klatt</dc:creator>
		<pubDate>Thu, 11 Mar 2010 17:41:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5222</guid>
		<description>To me it&#039;s no contradiction to do ATDD according to conditions of satisfaction which you have committed automate in CI during iteration, while *on top* (or in exploratory cross-feature test iteration) you do manual expert tests which you automate asa you found a bug to add to regression of that case. btw - conditions of satisfaction for userstories are not only defined by newbees (and if then you learn...)</description>
		<content:encoded><![CDATA[<p>To me it&#8217;s no contradiction to do ATDD according to conditions of satisfaction which you have committed automate in CI during iteration, while *on top* (or in exploratory cross-feature test iteration) you do manual expert tests which you automate asa you found a bug to add to regression of that case. btw &#8211; conditions of satisfaction for userstories are not only defined by newbees (and if then you learn&#8230;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil Ruse</title>
		<link>http://blog.brodzinski.com/2010/03/manual-testing.html#comment-5200</link>
		<dc:creator>Phil Ruse</dc:creator>
		<pubDate>Thu, 11 Mar 2010 08:34:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1680#comment-5200</guid>
		<description>Much as I rely on unit testing, it&#039;s that random element that QA teams provide that makes the difference. Done right it&#039;s a real positive; but then again, some are so regimented, manual testing by a script written in front of them, that it takes away that advantage.</description>
		<content:encoded><![CDATA[<p>Much as I rely on unit testing, it&#8217;s that random element that QA teams provide that makes the difference. Done right it&#8217;s a real positive; but then again, some are so regimented, manual testing by a script written in front of them, that it takes away that advantage.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

