explaining exploratory testing

explaining exploratory testing | Coded Style

explaining exploratory testing | Coded Style — Fri, 09 Jan 2009 02:06:27 GMT

PingBack from http://www.codedstyle.com/explaining-exploratory-testing/

re: explaining exploratory testing

mark.spiteri — Fri, 09 Jan 2009 10:03:21 GMT

That is a great explanation. I have been having this debate continuously for the past couple of weeks and have not yet managed to get anywhere.

I will try using your same line of thought, and see if it works ;)

Mark

re: explaining exploratory testing

anutthara — Fri, 09 Jan 2009 10:31:55 GMT

I don't think I understand why there is a contest between structural and exploratory testing methods at all. You need a balance of both to test the product to a meaningful level.

I know that traditionally at Microsoft, we begin with a structured test plan, but rely a whole lot on exploratory testing to find bugs as the product cycle progresses. I don't think I would choose one over the other, but quite simply a mix of the 2. Wouldn't you agree that's common sense?

re: explaining exploratory testing

manndras — Fri, 09 Jan 2009 20:03:21 GMT

I guess the biggest question for me is what would lead a tester to taking an exploratory approach vs. say, an planned API level approach? Obviously, they're not mutually exclusive, nor can the tester not use them both to feed each other.

It really comes down to a practical problem of time and investment. The more I read your blog the more I realize that there are so many "schools" of testing that you will find many testers are drawn to one (or at best two). The best testers can employ any technique necessary to get the job done. Approproateness of methodology is what (in my my view) makes the best testers - and that requires an agile and broad set of perspectives and varied skills.

For exploratory testing, what I struggle with is that it could be applied to any kind of testing task. Should it be? Or are there times when it's too costly and a more statistical approach (if possible) is the better bet.

re: explaining exploratory testing

Toddsa — Sat, 10 Jan 2009 06:45:49 GMT

A good STE can put even a senior SDET to shame on bug counts most of the time. You lose easy reproducibly with a manual approach but you find bugs sooner in the product and you find more interesting bugs often.

It is hard to find good testers and it is even harder to find good SDET's. Companies don't hire STE's and train them, they mostly hire SDET's out of college.

In most cases I would rather higher a high school kid with some programming experience instead of college graduate for a test job.

re: explaining exploratory testing

James Whittaker — Sun, 11 Jan 2009 04:41:58 GMT

It's not a contest. It's a debate. A good and healthy debate. And if this debate ends with a better understand of when planning is superior and when doing is superior and how to find the optimal mix, then everyone wins.

But I can't help my competitive nature ... I am an explorer and I will use every chance I have to promote it.

re: explaining exploratory testing

phuuo — Mon, 12 Jan 2009 20:29:27 GMT

I agree strongly with anutthara. Proponents of exploratory testing will always cite something along the lines of the argument you have given, and then use this as evidence of the superiority of the technique. But the reality is that ET is just one of many approaches that should be employed during testing, depending on the sdlc and restraints in the scenario.

Too many times have I seen sloppy testing being defended as being "exploratory".

I think it always makes sense to produce planning before hand when the necessary information is available - e.g. functional specs, prototypes etc. Exploratory approaches can then be applied when the product goes into test in order to build on this initial planning.

What Gives? Exploratory Testing

Guy kolbis — Mon, 12 Jan 2009 21:26:32 GMT

James Whittaker say that testing is Hard and I quote: “Software testing is complicated by an overload

re: explaining exploratory testing

calkelpdiver — Fri, 16 Jan 2009 20:17:12 GMT

I have to agree with the people who say you need a mix of both. Both have their place and pros/cons in the project. For me I like to plan ahead and have some direction to go on. BUT, I will take the time to go and explore when the opportunity arises. To me this is a process of continous refinement of what I'm trying to test.

Also, because of doing the structured approach I get ideas of where and when to go "off the beaten path". And then again this will be folded back into my structured methodology to re-use later on.

It comes down to proving something is working the way intended (and if not then why), and then trying to see if does funny things when not used the way intended. Having a hard sciences background (BS in Zoology) my thought process is to use Scientific Methodology first and then experimental methods next. We need to do both the defined structural tests and the "What If" tests to determine if the SUT is really going to be sound.

Finally, I think this all speaks to the context of the situation at hand. Which method will work best for you at that time.

A szoftver minőségbiztosítási eszközök valós lehetőségei és korlátai

Termékinformációk fejlesztőknek — Wed, 04 Feb 2009 08:11:50 GMT

[Nacsa Sándor, 2009. január 13. – február 3.]  A minőségbiztosítás kérdésköre szinte alig ismert

Visual Studio Team System 2008 Test Edition with MSDN Premium Subscription

Termékinformációk fejlesztőknek — Fri, 06 Feb 2009 15:02:59 GMT

[ Nacsa Sándor , 2009. február 6.] Ez a Team System változat a webalkalmazások és –szolgáltatások teszteléséhez