<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Jeff Fry on Testing</title>
	<atom:link href="http://testingjeff.wordpress.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://testingjeff.wordpress.com</link>
	<description>Thoughts on the craft of software testing</description>
	<lastBuildDate>Tue, 15 Dec 2009 04:12:07 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Question about Model-Based Testing by Lanette</title>
		<link>http://testingjeff.wordpress.com/2009/06/03/question-about-model-based-testing/#comment-519</link>
		<dc:creator>Lanette</dc:creator>
		<pubDate>Tue, 15 Dec 2009 04:12:07 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=72#comment-519</guid>
		<description>This is a good summary. I read through James Bach&#039;s slides and I agree, but I also think that I&#039;d like to argue with him about this because it isn&#039;t intended to cover EVERYTHING. I mean, it is a great way to cover the functional testing, but it shouldn&#039;t be the entire test strategy. Any technique when seen as &quot;the magic bullet&quot; is going to fall apart. Only when we have a reasonable balanced diet of appropriate testing for the software under test is it going to be testing that can scale while assuming the right amount of risk.

I really LIKE model based testing because it is way smarter and more flexible than test cases. It has more value over time and as a tester it helps me understand what I&#039;m testing for more than just the automated testing of some tool. It helps the tester understand what is going on. I would say that the making and knowing the model is often of MORE value than even reading the code for understanding what is a good way to test this, all automation aside. You can look at the model and then create tests. The &quot;what happens if&quot; scenarios start to come up. Also, you can collaborate with a model and circle one section and tell your test partner &quot;go for it in this area&quot; and they can explore a visual charter.

My point is, don&#039;t limit the model just to the automation. A visual overview has much more value than that.</description>
		<content:encoded><![CDATA[<p>This is a good summary. I read through James Bach&#8217;s slides and I agree, but I also think that I&#8217;d like to argue with him about this because it isn&#8217;t intended to cover EVERYTHING. I mean, it is a great way to cover the functional testing, but it shouldn&#8217;t be the entire test strategy. Any technique when seen as &#8220;the magic bullet&#8221; is going to fall apart. Only when we have a reasonable balanced diet of appropriate testing for the software under test is it going to be testing that can scale while assuming the right amount of risk.</p>
<p>I really LIKE model based testing because it is way smarter and more flexible than test cases. It has more value over time and as a tester it helps me understand what I&#8217;m testing for more than just the automated testing of some tool. It helps the tester understand what is going on. I would say that the making and knowing the model is often of MORE value than even reading the code for understanding what is a good way to test this, all automation aside. You can look at the model and then create tests. The &#8220;what happens if&#8221; scenarios start to come up. Also, you can collaborate with a model and circle one section and tell your test partner &#8220;go for it in this area&#8221; and they can explore a visual charter.</p>
<p>My point is, don&#8217;t limit the model just to the automation. A visual overview has much more value than that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Question about Model-Based Testing by Tim Coulter</title>
		<link>http://testingjeff.wordpress.com/2009/06/03/question-about-model-based-testing/#comment-494</link>
		<dc:creator>Tim Coulter</dc:creator>
		<pubDate>Mon, 12 Oct 2009 18:37:11 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=72#comment-494</guid>
		<description>Thanks Jeff. Exactly the writeup I was looking for! Thanks for the links and great ideas.</description>
		<content:encoded><![CDATA[<p>Thanks Jeff. Exactly the writeup I was looking for! Thanks for the links and great ideas.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Incentives for Developers and Testers by SeekingLemondade</title>
		<link>http://testingjeff.wordpress.com/2007/01/27/incentives-for-developers-and-testers/#comment-493</link>
		<dc:creator>SeekingLemondade</dc:creator>
		<pubDate>Wed, 19 Aug 2009 19:46:32 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/2007/01/27/incentives-for-developers-and-testers/#comment-493</guid>
		<description>&gt;&gt;if Bug DBs are used to evaluate employee performance, they will necessarily begin to be gamed…and before long the information that they should provide will be obscured and distorted by folks trying to protect their jobs, to save face with management, or to maximize that next bonus.

Couldn&#039;t agree more. You may remember back to the days when programmers were paid by the line.... you can guess what happened in those days.</description>
		<content:encoded><![CDATA[<p>&gt;&gt;if Bug DBs are used to evaluate employee performance, they will necessarily begin to be gamed…and before long the information that they should provide will be obscured and distorted by folks trying to protect their jobs, to save face with management, or to maximize that next bonus.</p>
<p>Couldn&#8217;t agree more. You may remember back to the days when programmers were paid by the line&#8230;. you can guess what happened in those days.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Controlled Experiments To Test For Bugs In Our Mental Models by Curious Cat Science and Engineering Blog &#187; Controlled Experiments for Software Solutions</title>
		<link>http://testingjeff.wordpress.com/2009/06/24/controlled-experiments-to-test-for-bugs-in-our-mental-models/#comment-492</link>
		<dc:creator>Curious Cat Science and Engineering Blog &#187; Controlled Experiments for Software Solutions</dc:creator>
		<pubDate>Tue, 18 Aug 2009 01:18:04 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=90#comment-492</guid>
		<description>[...] Jeff Fry linked to a great webcast in Controlled Experiments To Test For Bugs In Our Mental Models. [...]</description>
		<content:encoded><![CDATA[<p>[...] Jeff Fry linked to a great webcast in Controlled Experiments To Test For Bugs In Our Mental Models. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Controlled Experiments To Test For Bugs In Our Mental Models by Learning Using Controlled Experiments for Software Solutions &#171; Hexawise&#39;s Blog</title>
		<link>http://testingjeff.wordpress.com/2009/06/24/controlled-experiments-to-test-for-bugs-in-our-mental-models/#comment-491</link>
		<dc:creator>Learning Using Controlled Experiments for Software Solutions &#171; Hexawise&#39;s Blog</dc:creator>
		<pubDate>Tue, 18 Aug 2009 01:01:41 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=90#comment-491</guid>
		<description>[...] Jeff Fry linked to a great webcast in Controlled Experiments To Test For Bugs In Our Mental Models. [...]</description>
		<content:encoded><![CDATA[<p>[...] Jeff Fry linked to a great webcast in Controlled Experiments To Test For Bugs In Our Mental Models. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Controlled Experiments To Test For Bugs In Our Mental Models by testingjeff</title>
		<link>http://testingjeff.wordpress.com/2009/06/24/controlled-experiments-to-test-for-bugs-in-our-mental-models/#comment-486</link>
		<dc:creator>testingjeff</dc:creator>
		<pubDate>Thu, 25 Jun 2009 18:31:31 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=90#comment-486</guid>
		<description>Justin, thanks for your comments, and for adding your notes! I&#039;ll have a look at Hexwise as well.</description>
		<content:encoded><![CDATA[<p>Justin, thanks for your comments, and for adding your notes! I&#8217;ll have a look at Hexwise as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Controlled Experiments To Test For Bugs In Our Mental Models by Justin Hunter</title>
		<link>http://testingjeff.wordpress.com/2009/06/24/controlled-experiments-to-test-for-bugs-in-our-mental-models/#comment-485</link>
		<dc:creator>Justin Hunter</dc:creator>
		<pubDate>Thu, 25 Jun 2009 13:36:02 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=90#comment-485</guid>
		<description>Jeff,

I LOVED listening to that presentation.  So much in fact, that (a) I&#039;ll try to track down the presenter for a phone call and (b) I was motivated to document a quick summary of his talk, included below.

I firmly believe that applied statistics-based experiments are under-appreciated by businesses (and, for that matter, business schools).  Few people who understand them are as articulate and concise as Kohavi.  Admittedly, I could be accused of being biased as: (a) I am the son of a prominent applied statistician and (b) I am the founder of a software testing tools company that uses applied statistics-based methods and algorithms to make our tool work.  Thank you for posting it.  I&#039;ll also bring it to the attention of my brother, whose blog http://management.curiouscatblog.net/ focuses on similar topics.


- Justin 

------------
Justin Hunter
Founder and CEO
Hexawise
&quot;More coverage.  Fewer tests.&quot;

Ron Kohavi, Microsoft Research

1:00 Amazon: in 2000, Greg Linden wanted to add recommendations in shopping cards during the check out process.  The &quot;HiPPO&quot; (meaning the Highest Paid Person&#039;s Opinion) was against it on the grounds that it would be a bad idea; recommendations would confuse and/or distract people.  Amazon, a company with a good culture of experimentation, decided to run a small experiment anyway, &quot;just to get the data&quot; - It was wildly successful and is in widespread use today at Amazon and other firms.

3:00 Dr. Footcare example:  Including a coupon code above the total price to be paid had a dramatic impact on abandonment rates.

4:00 &quot;Was this answer useful?&quot;  Dramatic differences occur when  Y/N is replaced with 5 Stars and whether an empty text box is initially shown with either (or whether it is triggered only after a user clicks to give their initial response) 

6:00 Sewing machines: experimenting with a sales promotion strategy led to extremely counter-intuitive pricing choice

7:00 &quot;We are really, really bad at understanding what is going to work with customers...&quot;

7:30 &quot;DATA TRUMPS INTUITION&quot;  {especially on novel ideas}.  Get valuable data through quick, cheap experimentation.  &quot;The less the data, the stronger the opinions.&quot;

8:00 Overall Evaluation Criteria: &quot;OEC&quot; What will you measure?  What are you trying to optimize?  (Optimizing for the &quot;customer lifetime value&quot;)

9:00 Analyzing data / looking under the hood is often useful to get meaningful answers as to what really happened and why

10:30 A/B tests are good; more sophisticated multi-variate testing methods are often better 

12:00 Some problems: OEC is hard culturally.  People won&#039;t agree.  If there are 10 changes per page, you will need to break things down into smaller experiments.

14:00 Many people are afraid of multiple experiments [e.g., multi-variate experiments] more than they should be.  

16:00 People do a very bad job at understanding natural variation and are often too quick to jump to conclusions.

17:00 eBay does A/B testing and makes the control group ~1%.  Ron Kohavi, the presenter, suggests starting small then quickly ramping up to 50/50 (e.g., 50% of viewers will see version A, 50% will see version B).

19:00 Beware of launching experiments than &quot;do not hurt,&quot; there are feature maintenance cost

20: 00 Drive to a data-driven culture.  &quot;It makes a huge difference.  People who have worked in a data-driven culture really, really love it... At Amazon... we built an optimization system that replaced all the debates that used to happen on Fridays about what gets on the home page with something that is automated.&quot;

21:00 Microsoft will be releasing its controlled experiments on the web platform at some point in the future, probably not in the next year

21:00 Summary
Listen to your customers because our intuition at assessing new ideas is poor 
Don&#039;t let the HiPPO  drive decisions; they are likely to be wrong/ let the customer data do it
Experiment often
Create a trustworthy system to accelerate innovation</description>
		<content:encoded><![CDATA[<p>Jeff,</p>
<p>I LOVED listening to that presentation.  So much in fact, that (a) I&#8217;ll try to track down the presenter for a phone call and (b) I was motivated to document a quick summary of his talk, included below.</p>
<p>I firmly believe that applied statistics-based experiments are under-appreciated by businesses (and, for that matter, business schools).  Few people who understand them are as articulate and concise as Kohavi.  Admittedly, I could be accused of being biased as: (a) I am the son of a prominent applied statistician and (b) I am the founder of a software testing tools company that uses applied statistics-based methods and algorithms to make our tool work.  Thank you for posting it.  I&#8217;ll also bring it to the attention of my brother, whose blog <a href="http://management.curiouscatblog.net/" rel="nofollow">http://management.curiouscatblog.net/</a> focuses on similar topics.</p>
<p>- Justin </p>
<p>&#8212;&#8212;&#8212;&#8212;<br />
Justin Hunter<br />
Founder and CEO<br />
Hexawise<br />
&#8220;More coverage.  Fewer tests.&#8221;</p>
<p>Ron Kohavi, Microsoft Research</p>
<p>1:00 Amazon: in 2000, Greg Linden wanted to add recommendations in shopping cards during the check out process.  The &#8220;HiPPO&#8221; (meaning the Highest Paid Person&#8217;s Opinion) was against it on the grounds that it would be a bad idea; recommendations would confuse and/or distract people.  Amazon, a company with a good culture of experimentation, decided to run a small experiment anyway, &#8220;just to get the data&#8221; &#8211; It was wildly successful and is in widespread use today at Amazon and other firms.</p>
<p>3:00 Dr. Footcare example:  Including a coupon code above the total price to be paid had a dramatic impact on abandonment rates.</p>
<p>4:00 &#8220;Was this answer useful?&#8221;  Dramatic differences occur when  Y/N is replaced with 5 Stars and whether an empty text box is initially shown with either (or whether it is triggered only after a user clicks to give their initial response) </p>
<p>6:00 Sewing machines: experimenting with a sales promotion strategy led to extremely counter-intuitive pricing choice</p>
<p>7:00 &#8220;We are really, really bad at understanding what is going to work with customers&#8230;&#8221;</p>
<p>7:30 &#8220;DATA TRUMPS INTUITION&#8221;  {especially on novel ideas}.  Get valuable data through quick, cheap experimentation.  &#8220;The less the data, the stronger the opinions.&#8221;</p>
<p>8:00 Overall Evaluation Criteria: &#8220;OEC&#8221; What will you measure?  What are you trying to optimize?  (Optimizing for the &#8220;customer lifetime value&#8221;)</p>
<p>9:00 Analyzing data / looking under the hood is often useful to get meaningful answers as to what really happened and why</p>
<p>10:30 A/B tests are good; more sophisticated multi-variate testing methods are often better </p>
<p>12:00 Some problems: OEC is hard culturally.  People won&#8217;t agree.  If there are 10 changes per page, you will need to break things down into smaller experiments.</p>
<p>14:00 Many people are afraid of multiple experiments [e.g., multi-variate experiments] more than they should be.  </p>
<p>16:00 People do a very bad job at understanding natural variation and are often too quick to jump to conclusions.</p>
<p>17:00 eBay does A/B testing and makes the control group ~1%.  Ron Kohavi, the presenter, suggests starting small then quickly ramping up to 50/50 (e.g., 50% of viewers will see version A, 50% will see version B).</p>
<p>19:00 Beware of launching experiments than &#8220;do not hurt,&#8221; there are feature maintenance cost</p>
<p>20: 00 Drive to a data-driven culture.  &#8220;It makes a huge difference.  People who have worked in a data-driven culture really, really love it&#8230; At Amazon&#8230; we built an optimization system that replaced all the debates that used to happen on Fridays about what gets on the home page with something that is automated.&#8221;</p>
<p>21:00 Microsoft will be releasing its controlled experiments on the web platform at some point in the future, probably not in the next year</p>
<p>21:00 Summary<br />
Listen to your customers because our intuition at assessing new ideas is poor<br />
Don&#8217;t let the HiPPO  drive decisions; they are likely to be wrong/ let the customer data do it<br />
Experiment often<br />
Create a trustworthy system to accelerate innovation</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Are Ladders Useful? by Jeff Fry</title>
		<link>http://testingjeff.wordpress.com/2009/04/06/are-ladders-useful/#comment-479</link>
		<dc:creator>Jeff Fry</dc:creator>
		<pubDate>Wed, 08 Apr 2009 06:07:58 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=64#comment-479</guid>
		<description>Hey Adam, I like where you&#039;re going with languages. Perhaps -- to keep extending the metaphor -- a scripting language a tool set for building custom ladders.</description>
		<content:encoded><![CDATA[<p>Hey Adam, I like where you&#8217;re going with languages. Perhaps &#8212; to keep extending the metaphor &#8212; a scripting language a tool set for building custom ladders.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Are Ladders Useful? by Adam Goucher</title>
		<link>http://testingjeff.wordpress.com/2009/04/06/are-ladders-useful/#comment-478</link>
		<dc:creator>Adam Goucher</dc:creator>
		<pubDate>Tue, 07 Apr 2009 23:01:16 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=64#comment-478</guid>
		<description>To follow the ladder analogy, it is often quite useful to have a multi-ladder which can act as a variety of types of fixed ladders. In software / testing terms, I would consider python / ruby / perl a multi-ladder.

-adam</description>
		<content:encoded><![CDATA[<p>To follow the ladder analogy, it is often quite useful to have a multi-ladder which can act as a variety of types of fixed ladders. In software / testing terms, I would consider python / ruby / perl a multi-ladder.</p>
<p>-adam</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why Do You Use Watir? by Are Ladders Useful? &#171; Jeff Fry on Testing</title>
		<link>http://testingjeff.wordpress.com/2008/04/15/why-do-you-use-watir/#comment-477</link>
		<dc:creator>Are Ladders Useful? &#171; Jeff Fry on Testing</dc:creator>
		<pubDate>Mon, 06 Apr 2009 18:56:11 +0000</pubDate>
		<guid isPermaLink="false">http://testingjeff.wordpress.com/?p=27#comment-477</guid>
		<description>[...] for some concrete examples of problems where Watir has been useful for me, see my post about a few of the most compelling cases where I&#8217;ve used Watir over the past five [...]</description>
		<content:encoded><![CDATA[<p>[...] for some concrete examples of problems where Watir has been useful for me, see my post about a few of the most compelling cases where I&#8217;ve used Watir over the past five [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>