Testing Gods – Part I

Whoa!!! The buzz around town was that "James Bach" was coming down to Bangalore to conduct a workshop on testing and hey guess what, he was also coming down to my company – Mindtree for a session and was scheduled to conduct a workshop for a lucky few testing folks (oh by the way, I was one of the lucky few). What I am going to deal with in this post is about the session that James took on ‘Exploratory Testing’.

One of the common misconceptions that people have about exploratory testing is that it is ‘ad – hoc’. James sought to put this misconception out by explaining to us about ‘Structured Exploratory Testing’. In order to simplify understanding, let me list down in points –

Identify what is your current scope of testing which could in itself have many layers. For example, I could currently narrow down my scope to functional testing. For greater granularity, I could also limit my scope to listing down which of the specific functionalities / features I would be testing on


Identify tools that can possibly make your job easier, MS Excel is one awesome tool where the scope for using the tool is limitless. If you are testing on a web application, there are various ‘add – ons’ that you could install to make your browser work for you


Now, we can get started on our testing –


Note the date and time when you start testing, this could come in useful when you are verifying log files


Make notes of whatever actions you do (if possible with the date and time too) and the observations that you make


A good tip is to note down all the defects and then log them in your defect tracking tool, so that you can optimize time


Session based exploratory testing (where you predetermine the test duration and scope) would be a great approach


Creating a Mind Map for each of your sessions on exploratory testing is very powerful and helps you a great deal on making notes, creating reports, traceability and many more


Pair testing with a peer tester is a great approach where you would notice that two brains work better than one


Pair testing with a developer is an even better approach, that way you won’t be wasting precious time in reproducing defects to your developer while also gaining developer confidence and respect

Note – the above list is obviously not exhaustive and is based on a number of assumptions (for more on assumptions, keep following this blog) like the tester knows what the requirements / functionalities of the product / application are, he knows which environment and platform he should be testing on and many more.

Some of the interesting questions that came up during the session were –

Q. How do you estimate testing effort without first getting your hands dirty on the product / application?
Ans. It is possible to estimate testing effort, if it is possible to estimate the number of bugs that are expected to be injected. In other words, just like it is not possible to estimate the number of bugs that can be injected, the same way it is not possible to estimate testing effort without getting your hands dirty first.

Q. Can we do Exploratory Automation Testing?

Ans. We can use Automation tools / browser add – ons, load generators, etc. to optimize Exploratory Testing

Q. Is Exploratory Testing sufficient for my software testing project?

Ans. It is best to have a good balance between Scripted Testing and Exploratory Testing and incorporate the findings (defects) from your Exploratory Testing sessions in to your formal Test Scripts

PS - follow this blog for more stuff on 'Testing Gods'