Comments on: In search of the potato… http://thetesteye.com/blog/2009/12/in-search-of-the-potato/ by rikard edgren, henrik emilsson and martin jansson - with torbjörn ryber and henrik andersson Thu, 17 May 2012 16:53:59 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Rikard Edgren http://thetesteye.com/blog/2009/12/in-search-of-the-potato/comment-page-1/#comment-345 Rikard Edgren Mon, 22 Mar 2010 12:28:45 +0000 http://thetesteye.com/blog/?p=672#comment-345 Thanks for the link, Petr; the amoeba is more beautiful, but the potato is faster to draw... There is also an important difference in content: In the amoeba model, it is seen as a bad thing that the application isn't identical to the specifications. In my model it is natural (and often good!) that the requirements don't match the aplication's reality. Thanks for the link, Petr; the amoeba is more beautiful, but the potato is faster to draw…
There is also an important difference in content:
In the amoeba model, it is seen as a bad thing that the application isn’t identical to the specifications.
In my model it is natural (and often good!) that the requirements don’t match the aplication’s reality.

]]> By: Petr Hanák http://thetesteye.com/blog/2009/12/in-search-of-the-potato/comment-page-1/#comment-344 Petr Hanák Mon, 22 Mar 2010 10:51:50 +0000 http://thetesteye.com/blog/?p=672#comment-344 Your potato is very similar to amoeba presented by Jaroslav Tulach (http://openide.netbeans.org/tutorial/test-patterns.html) - it´s about API design from developer view, but similarities can be found for testers. Your potato is very similar to amoeba presented by Jaroslav Tulach (http://openide.netbeans.org/tutorial/test-patterns.html) – it´s about API design from developer view, but similarities can be found for testers.

]]> By: Rikard Edgren http://thetesteye.com/blog/2009/12/in-search-of-the-potato/comment-page-1/#comment-232 Rikard Edgren Thu, 10 Dec 2009 13:08:46 +0000 http://thetesteye.com/blog/?p=672#comment-232 Zeger: very difficult question, since I'm not 100% sure of which definition of Exploratory Testing I want to use. But let's use the definition that Exploratory Testing is an approach. The difference is that ET is a way to think, a style of testing that can be applied to any technique, method, activity; whereas Grounded Test Design is a technique/method/activity that could be used both in Exploratory and Scripted environments. On the other hand scripted testing is often about verifying the requirements, which isn't what I am talking about. Many of the things that Exploratory Testing proponents talk about fits perfectly fine in Grounded Test Design (which don't have anything really new, except the name...) so it could very well be a part of ET, if ET embraces reviewing and light-weight documenting in advance. I will very soon explain more about Grounded Test Design. Zeger: very difficult question, since I’m not 100% sure of which definition of Exploratory Testing I want to use.
But let’s use the definition that Exploratory Testing is an approach.
The difference is that ET is a way to think, a style of testing that can be applied to any technique, method, activity; whereas Grounded Test Design is a technique/method/activity that could be used both in Exploratory and Scripted environments.
On the other hand scripted testing is often about verifying the requirements, which isn’t what I am talking about.
Many of the things that Exploratory Testing proponents talk about fits perfectly fine in Grounded Test Design (which don’t have anything really new, except the name…) so it could very well be a part of ET, if ET embraces reviewing and light-weight documenting in advance.

I will very soon explain more about Grounded Test Design.

]]> By: Zeger Van Hese http://thetesteye.com/blog/2009/12/in-search-of-the-potato/comment-page-1/#comment-230 Zeger Van Hese Thu, 10 Dec 2009 11:12:33 +0000 http://thetesteye.com/blog/?p=672#comment-230 Hi Rikard, Actually I see many analogies between grounded theory and exploratory testing. Both are about letting information emerge while using the data/product, rather than theoretisizing and designing upfront. They are about comparing the output of different tests, making assumptions and modyfing the next tests and the underlying model on-the-go. So when I hear 'grounded test design' I immediately see it as the process of letting the tests emerge from the software, by questioning the software and adapting the approach in the process. Basically, this is exactly the same as what a sapient, holistic exploratory testing process should do. What is your take on the difference between 'grounded design' and 'exploratory testing'? Regards, Zeger Hi Rikard,
Actually I see many analogies between grounded theory and exploratory testing. Both are about letting information emerge while using the data/product, rather than theoretisizing and designing upfront. They are about comparing the output of different tests, making assumptions and modyfing the next tests and the underlying model on-the-go.

So when I hear ‘grounded test design’ I immediately see it as the process of letting the tests emerge from the software, by questioning the software and adapting the approach in the process. Basically, this is exactly the same as what a sapient, holistic exploratory testing process should do.

What is your take on the difference between ‘grounded design’ and ‘exploratory testing’?

Regards,
Zeger

]]>