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'

Risk Based Testing

Recently I came across a colleague of mine who was working on an assignment for a client of his on implementing the ‘Risk Based Testing’ methodology for their clients. The concept sounded very interesting to me and so I asked him to explain it to me further. So this is a brief of what they were implementing for their clients – the objective was to reduce the regression testing cycle by reducing the number of test cases to be executed and hence the amount of time taken to execute one regression test cycle.

          The methodology they used was very simple – traverse through all the test cases and assign a factor of ‘Priority’ to each test case which denotes the significance of the test case from the business standpoint and also assigning a factor of ‘Risk’ to the test case denoting the probability of the test case failing. Now the product of these two factors is taken and based on a predetermined baseline, only those test cases are executed which meet the baseline. Now all this may sound simple but what is very important here to note is the dependence on people who have a thorough understanding of the product or application on which RBT (Risk Based Testing) methodology is being implemented.

          The above approach is purely a mathematical / formula based approach to RBT, another approach to go about RBT is using the following heuristics for testing of the product / application under test – 

·         Losing the Confidence of Customers

·         Loss of Money

·         Loss of Life

·         Loss of Effort / Time

·         Loss of Business

·         Loss of Image / Brand

·         Losing Customers to Competitors

·         Losing Data

·         Not Adapting Quickly