The Pursuit of the Unreplicable Bug

ghostbusters.gifI’ve been recently testing a web-based application that produced a very interesting defect. It seemed that in one particular screen, a user (with the right combination key strokes and mouse clicks) could actually enter a supposedly uneditable error message field and enter text! At first i wasn’t able to repeat this behaviour but with the words from a James Bach article ringing in my ears about “…ignoring unreproducible bugs at your peril”, i logged it waiting for the right opportunity to attack it.

I had already spent time looking for this ‘bug’ but figured that i would put it to one side and come back to it with fresh eyes and clearer thoughts. Interestingly enough, the developers caught hold of this bug and attempt to replicate in their dev environments – i was even ‘challenged’ in a joking way that if i couldn’t reproduce the bug within 5 attempts then it didn’t exisit!! Oh, did the competitive urges come out then! (This was done in good spirits – we have a tremendous rapport between developers, testers and BA’s). However, it was another developer that found the key/mouse strokes that generated the bug and we discovered that it was a validation error on that web page!

So what were the lessons learnt?

  1. Exploratory testing found this bug – some may say that discovery was a ‘fluke’ but scripted testing would never have picked this bug up.
  2. Fresh eyes and a clearer head can aid tremendously in trying to replicate a bug (especially one discovered late in the day!)
  3. Having a rapport with developers helps in solving bugs – personal agendas and politics are put to one side for the greater good of the ‘team’
  4. Working alongside developers generally breaks down communication barriers (percieved and physical)
  5. Unreproducable bugs ARE best ignored at ones own peril – in this case finding this bug lead to a tightening of field validation for the application
  6. Bugs are bugs are bugs…testers find them, developers fix them, buisness decide what they want done with them – never give up on trying to replicate bugs that are difficult to reproduce!
  7. Teamwork – i honestly believe the power of many can be greater than the power of one
  8. It’s tremendously satisfying finding a bug that is difficult to find and reproduce – the testing equilivant of a three-pointer!

Software Testing and the Intercepting Fist

Master of Software Testing PhilosophyWelcome to my first blog on software testing – hopefully one of many!
Testing is an exciting intellectually stimulating discipline to be involved in. I have been in the ‘game’ now for over 8 years in Wellington, New Zealand. I have worked in both the private and public sectors and over that time, my knowledge and understanding has been shaped by the experiences i have come across and the ‘teachings’ i have absorbed from other practitioners, organisations and learned colleagues around the world (Cem Kaner, James Bach, Brian Marick, Bret Pettichord among others). The combination of these things have shaped my view and understanding of testing as i know it today.

One of the greatest, if not the greatest martial artist of the 20th Century – Bruce Lee – espoused his philosophies on martial arts through a framework called ‘Jeet Kune Do’ (JKD) or Way of the Intercepting Fist.

One of the theories of JKD is that a fighter should do whatever is necessary to defend himself, regardless of where the techniques used come from. This is like testing – should we subscribe to only ‘one way’ or one technique to test software when there is a multitude of methods that may suffice? Should we follow the ‘classical mess’ (scripted testing) or become ‘formless like water'(Exploratory testing)?

Don’t get me wrong – test scripted pre-arranged testing has its place and it works – i have no qualms about that – I’ve been there, lived that. The only voice of dissent i have is when so called Test Practitioners disregard any other way of doing it. I worked once for a bank in which i prepared a paper on the benefits of exploratory testing – especially used in a complementary way with expected mode of scripted testing. It never gained traction no matter how much i tried – the Test Manager went as far as to say “…it doesn’t work and you’ll never find anything with that.”

I beg to differ.

As you can tell, i am an exponent of the Context Driven school and Exploratory testing. However, i know and recognise the need for scripting and i am comfortable with that. The trick is seeing what you test in context of what you are doing and what you are trying to achieve.

You may be familiar with the following – its applies whether you Exploratory test or not…


1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project’s context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Have a great week testing!