<?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: Big Test Design Up-Front</title>
	<atom:link href="http://www.shino.de/2010/03/14/big-test-design-up-front/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.shino.de/2010/03/14/big-test-design-up-front/</link>
	<description>Software Testing, Craftsmanship, Leadership and beyond</description>
	<lastBuildDate>Mon, 06 Sep 2010 11:07:38 +0200</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Markus Gärtner</title>
		<link>http://www.shino.de/2010/03/14/big-test-design-up-front/comment-page-1/#comment-114</link>
		<dc:creator>Markus Gärtner</dc:creator>
		<pubDate>Mon, 15 Mar 2010 10:13:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.shino.de/?p=603#comment-114</guid>
		<description>@Thomas
Great feedback. Interestingly while thinking through whether or not the mission was accomplished, we remembered your comment from a similar earlier mission. I support your claim on the difference between a tester and a test professional. Indeed, it&#039;s at the core of Matt Heusser&#039;s Miagi-Do school of software testing.

@Ilker
Well, I would use the product to gather additional information about the product to build my model and refine it. The points where the documentation alone is weak, leaves gaps in your model. You can gather additional information by talking with the customer, by talking to the developer, or by talking to the product, if it&#039;s available for you. The risk of wrong information from either of these sources is the same to me. This is why testing puts a reliance on critical thinking.

@Anna
I might have a blog entry on STC coming up today on this topic, which dives into it in some detail. I hope Rosie puts it up, today. I will put a link on my blog, when I see it.</description>
		<content:encoded><![CDATA[<p>@Thomas<br />
Great feedback. Interestingly while thinking through whether or not the mission was accomplished, we remembered your comment from a similar earlier mission. I support your claim on the difference between a tester and a test professional. Indeed, it&#8217;s at the core of Matt Heusser&#8217;s Miagi-Do school of software testing.</p>
<p>@Ilker<br />
Well, I would use the product to gather additional information about the product to build my model and refine it. The points where the documentation alone is weak, leaves gaps in your model. You can gather additional information by talking with the customer, by talking to the developer, or by talking to the product, if it&#8217;s available for you. The risk of wrong information from either of these sources is the same to me. This is why testing puts a reliance on critical thinking.</p>
<p>@Anna<br />
I might have a blog entry on STC coming up today on this topic, which dives into it in some detail. I hope Rosie puts it up, today. I will put a link on my blog, when I see it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anna Baik</title>
		<link>http://www.shino.de/2010/03/14/big-test-design-up-front/comment-page-1/#comment-113</link>
		<dc:creator>Anna Baik</dc:creator>
		<pubDate>Sun, 14 Mar 2010 22:21:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.shino.de/?p=603#comment-113</guid>
		<description>&quot;The last part you described, to take on responsibility for every decision that you take and to be able to defend it, regardless if it’s seen as right or wrong is what makes the difference between a tester and a test professional in my eyes.&quot;

Absolutely.  This is why I think that the debriefing is an essential part of each session (Michael Bolton actually suggested doing a pure debrief session, which I&#039;d really like us to do at some point.)  Learning how to explain your decisions is so important, and so completely ignored in most commercial test training.  (It&#039;s also why I&#039;m really taken with James Bach&#039;s testing playbook idea - explicitly capturing the reasoning behind your test design decisions and making those decisions transparent to others to examine and challenge.)</description>
		<content:encoded><![CDATA[<p>&#8220;The last part you described, to take on responsibility for every decision that you take and to be able to defend it, regardless if it’s seen as right or wrong is what makes the difference between a tester and a test professional in my eyes.&#8221;</p>
<p>Absolutely.  This is why I think that the debriefing is an essential part of each session (Michael Bolton actually suggested doing a pure debrief session, which I&#8217;d really like us to do at some point.)  Learning how to explain your decisions is so important, and so completely ignored in most commercial test training.  (It&#8217;s also why I&#8217;m really taken with James Bach&#8217;s testing playbook idea &#8211; explicitly capturing the reasoning behind your test design decisions and making those decisions transparent to others to examine and challenge.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ilker Cetinkaya</title>
		<link>http://www.shino.de/2010/03/14/big-test-design-up-front/comment-page-1/#comment-112</link>
		<dc:creator>Ilker Cetinkaya</dc:creator>
		<pubDate>Sun, 14 Mar 2010 21:35:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.shino.de/?p=603#comment-112</guid>
		<description>Interesting findings on how a model is being developed. Model building vs. Model refining. Certainly both valid and valueable. However, I personally think that it is very important to build a model from all available input sources - except the product itself. This approach is familiar to me since I&#039;m used to define the tests for my product prior building it. Even in your given scenario, where the product is already at your fingertips, I&#039;d avoid to ask/utilize product in first instance. I&#039;d rather prefer to question the implementation of a feature, not it&#039;s description, even if insufficient or rudimentary.</description>
		<content:encoded><![CDATA[<p>Interesting findings on how a model is being developed. Model building vs. Model refining. Certainly both valid and valueable. However, I personally think that it is very important to build a model from all available input sources &#8211; except the product itself. This approach is familiar to me since I&#8217;m used to define the tests for my product prior building it. Even in your given scenario, where the product is already at your fingertips, I&#8217;d avoid to ask/utilize product in first instance. I&#8217;d rather prefer to question the implementation of a feature, not it&#8217;s description, even if insufficient or rudimentary.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Ponnet</title>
		<link>http://www.shino.de/2010/03/14/big-test-design-up-front/comment-page-1/#comment-111</link>
		<dc:creator>Thomas Ponnet</dc:creator>
		<pubDate>Sun, 14 Mar 2010 20:59:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.shino.de/?p=603#comment-111</guid>
		<description>Since the EWT testing happens in your free time all people taking part are free to disregard the mission, stop in the middle and leave or do whatever they want in their own free time. If they do follow the mission they should understand WHY they&#039;re doing it though:

&quot;You are moving from lovely Europe with measurements based on the metrics system to the US with imperial units. Test Converber v2.2.1 (http://www.xyntec.com/converber.htm) for usability in all the situations you may face. Report back test scenarios for usability testing&quot;

Reading the last sentence, I immediately ask myself &quot;why?&quot;. Why should the tester create scenarios for usability testing. Once an explanation is given that satisfies the tester the motivation will be higher to actually do it. As in a work environment, if you give someone a task but don&#039;t tell them why it&#039;s important to do the task motivation won&#039;t be high. Don&#039;t get me wrong, I think the application is a good one to test/write scenarios against. Apart from the very good explanations that you gave in this blog about moving away from the mission for very valid reasons maybe the motivation for the tester plays a big role as well? 

The last part you described, to take on responsibility for every decision that you take and to be able to defend it, regardless if it&#039;s seen as right or wrong is what makes the difference between a tester and a test professional in my eyes.

I&#039;m looking forward to next weeks session at which I&#039;ll be able to take part again (fingers crossed).</description>
		<content:encoded><![CDATA[<p>Since the EWT testing happens in your free time all people taking part are free to disregard the mission, stop in the middle and leave or do whatever they want in their own free time. If they do follow the mission they should understand WHY they&#8217;re doing it though:</p>
<p>&#8220;You are moving from lovely Europe with measurements based on the metrics system to the US with imperial units. Test Converber v2.2.1 (<a href="http://www.xyntec.com/converber.htm" rel="nofollow">http://www.xyntec.com/converber.htm</a>) for usability in all the situations you may face. Report back test scenarios for usability testing&#8221;</p>
<p>Reading the last sentence, I immediately ask myself &#8220;why?&#8221;. Why should the tester create scenarios for usability testing. Once an explanation is given that satisfies the tester the motivation will be higher to actually do it. As in a work environment, if you give someone a task but don&#8217;t tell them why it&#8217;s important to do the task motivation won&#8217;t be high. Don&#8217;t get me wrong, I think the application is a good one to test/write scenarios against. Apart from the very good explanations that you gave in this blog about moving away from the mission for very valid reasons maybe the motivation for the tester plays a big role as well? </p>
<p>The last part you described, to take on responsibility for every decision that you take and to be able to defend it, regardless if it&#8217;s seen as right or wrong is what makes the difference between a tester and a test professional in my eyes.</p>
<p>I&#8217;m looking forward to next weeks session at which I&#8217;ll be able to take part again (fingers crossed).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
