Freigeben über

Exploratory testing - introduction

  • Artikel

I have been meaning to put together a series of blog posts on exploratory testing - how exploratory testing can help make your testing more lightweight, illustrate some of our own experiments with doing exploratory testing on my team and of course, write about the exploratory testing tools we are building in Visual Studio as well :) So here is part one:

What is exploratory testing?

James Bach defines it succinctly as simultaneous test definition and execution. Of course, exploratory testing has been very popular and most testers do exploratory testing, perhaps calling it by another name or not calling it anything at all ;-) What pops in your mind as you think about exploratory testing?

So, why care about exploratory testing?

There are many reasons why exploratory testing might be interesting to testers in today’s world:

  • Find bugs fast and early without test overhead – exploratory testing is lightweight and reasonably good test hunches will let you find defects quick and early without the documentation time overhead
  • Centered on customer value rather than spec compliance – Tester is an end user proxy on the team and is key to the product being useful to the end user. Exploratory testing is done on working software and focused on customer value.
  • Crucial component of Agile testing – Everyone tests on an Agile team : the developers, Product owner, SCRUM master. The iterations are typically short and defects need to be found and fixed to deliver optimal customer value within a short turnaround time. This is an ideal situation to use a lightweight and effective style of testing like exploratory testing

So, despite so many advantages, why do many people still have reservations with exploratory testing? In the next part, we look at some of the myths surrounding exploratory testing and do some mythbusting. Stay tuned…

Comments

  • Anonymous
    October 20, 2011
    Good Stuff Anu!The only fear I have is, that this might become a replacement for 'script and test' where the tester puts more thought building test cases from requirements & documents. But having said that, this works great for my team where we have 2 weeks of sprint cycle.
  • Anonymous
    May 15, 2013
    Good ArticleWant to know few of the best practices whih need to be followed for Exploratory testing