Place your bets

Having recently completed reading the excellent book “The Click Moment” by  Franz Johansson (@Frans_Johansson).  I was amazed by how much of the material written in the book appears to relate to software testing.  The principles of the book are about creating opportunities in an unpredictable world and not about putting in hours and hours of practice.  The author explains that if there are fixed rules and these rules do not change too much then the 10000 hours rule of practice works  .  However the author points out we are living in a world in which the rules are always changing and unexpected (random) things can and do happen.

Some of the statements made in the book appear to have a correlation to the current state of software testing and the various “schools”.  (The scripted vs the exploratory debate).  The first thing that caused me to think was some of the comments on planning  and how this stifles opportunities for random events and for uncovering new and exciting things.  

For example Franz stated the following

…In fact, it might mean that the plan is outdated before you even start to execute it….”

I have often experienced this within companies that believe that we can plan upfront and know all we need to know to write scripts before we actually use the product.  I have seen test plans which when I start doing some testing are hopelessly out of date and then spend unnecessary time trying to retrofit what I am experiencing when testing with what the plan is saying.  Doing this makes me take my eye of the ball and miss chances to find out what could be important information.

Franz then makes a statement which could be taken directly from why we need to do exploratory testing.

“..As ironic as it may sound, it actually pays to schedule time to do something unscripted and unplanned. We need to leave enough room in our day to explore things that are not connected to our immediate goals. We need to free ourselves up to become aware of hidden opportunities and expose ourselves to significant click moments. Leave some flexibility in your schedule. Then, make sure you use the flexibility to explore something unrelated to what you are doing or to follow up on a curious idea you have been considering”

This offers so much potential for uncovering new and valuable information without the restrictions of following someone else’s thinking.  This way of testing in my world can lead to many serendipity moments.

So how can we help to make this happen in software testing?  Is there anything we can do to help create more of these moments of randomness?

Franz within the book gives 5 great tips which may encourage more serendipity.  I have listed the tips below and give a description of how this could apply to exploratory testing.

1. Place Many Bets 

Having a single exploratory testing mission which can consist of an infinite number of tests (bets) is surely much better than having a single scripted test in which you are only placing one bet.

2. Minimize the Size of the Bets

Instead of spending lots of time creating a test script based upon assumptions do the minimum required to do some actual testing and time box your testing sessions.

3. Take the Smallest Executable Step

Do the minimal amount of planning you can do to enable you to do some exploratory testing.  We need to stop thinking if we write detailed test scripts and plans before we really know anything that this will lead to us uncovering lots of information about the system.

4. Calculate Affordable Loss, Not ROI

We still believe that there is a justifiable, measurable cost in planning ahead and creating detailed test plans and scripts.  Which we then discover are outdated and very costly to maintain but we insist they are useful because someone else may use them in the future.  Instead look at creating lots of test ideals using test models and heuristics  which are cheap to create and if of no use can easily be discarded once we uncover more information when testing.  We should be looking at testing and its cost effectiveness from what can we afford to throw away if our assumptions are wrong.

5. Use Passion as Fuel

This is so important people with a passion for what they are doing are the drivers of opportunities.  This type of person is one where if they get stuck or falter they pick themselves back up, dust themselves off and look for ways around the problems.   These are innovators, the people who can radically change the market and improve what is already there.  There is a need to employ more of these passionate types of people in the world of software testing.  I am getting fed up of the 9-5 testers, the ones who have no desire to learn or improve themselves, the ones not reading this blog.

I do recommend that anyone involved in software development read this book it gives some great advice of how we can adapt what we do and how we think to improve our chances of delivering successful projects. 

PS No I am not being paid by Franz for writing this 

Sat Navs and Maps

The following blog article is based upon a lightening talk I gave at the Software Testing Club Meet Up in Winchester on the 19th Oct 2011.

I have recently been on holiday touring the Yorkshire dales, moors – covering over 1000 miles in one week. The car is fitted with a sat nav which is great when we want to get from A to B but also I have in the car a large scale map of the UK. I started to think about how we use these two ‘tools’ and how this could be used within testing to show the difference between following a set of instructions (scripts) and exploring the countryside (ET)

An example is that both have the same goal (mission) I want to get from A to B. However we use Sat Navs to show us the most direct, quickest, fastest way (some Sat Navs do now have an option for scenic route)

So I set off into the Yorkshire moors using the large scale map (my wife being the navigator), we knew where we wanted to end up, but the route we took was through the back of beyond. (In fact one the roads we ended up on did not even appear on the Sat Nav map (saying we must return to a digitized area – bug?) We explored the areas and when we noticed things that appeared interesting we took a detour and explored these areas. It was wonderful experience and we found places of interest that were outstanding in natural beauty along with all the seasons in one day (sun, rain, hail). At the end of the journey we had discovered some great things but still ended up at the place we wanted to be, yes it took more time (slightly) but we found out more.

My point is that if you stick to using the sat nav you end up at the same place but you may miss so much that is interesting. Now can we compare this to testing? Yes a script ‘may’ be useful from getting you from A to B but how much will you discover, how many surprises will you find? Yes I could repeat the same journey again since we have the map and know the route I took. Would I want to repeat the exact same route? I am sure that if I went to that area again I would be tempted to go a slightly different way since there could be things around the corner that may interest me.

Rob Lambert pointed out the following to me:

“I find the sat nav is a safety and re assurance aid also in that i can explore but then turn the sat nav on, or refer to it, to then return to a known route.”

I would question this is the sense that it could lead to a false sense of security. What happens if the map gets corrupted, or the electronics fail? I would tend to think of the paper map as the safety, reassurance rather than the sat nav which may have a tendency to fail.

With regards to the meet up in Winchester - I wish more people would have come along they missed a great evening of testing discussions with Michael Bolton being on top form. There are plans to have a regualr bi-monthly meet up in Winchester in the near future - watch out for an announcement via the software testing club soon.