Reproducing a bug ….the eternal quest

There are some really cliched problems which software testers and consqeuently software developers face as part of their job. Reproducing a bug comes right there among the top of that list. Recently,  I faced one such instance where I was at my wits end to reproduce a bug – needless to say, it wasted precious man-hours.

I was testing a MS Excel add-on and was unable to get it to work when requests where send through a proxy. I did what most software testers would normally do. But let me tell you the software that I was using – Windows Vista, MS Excel 2007, Squid Proxy 2.7.

To start with, I just repeated the same steps again and again hoping that a miracle would happen. Then I took the next step – Google.  I entered the error being thrown and got a lot of results. Not successful at getting an instant answer I faced away from Google. Let me tell you that during this time I had contacted the developer and he was using a different version of Office and a different OS Win XP .

I tried to test with Windows XP and the Office version used by the developer but still no luck.

Then I started doing what most software testers SHOULD do. I checked the squid proxy log and saw the error details. But could not make much headway. Tried again and then saw that there was some issues with the Squid Proxy version that I was using. I tried with an earlier version and lo behold it worked. So, what is the big deal. I think with a better approach we, the software testers and developers can save a considerable amount of time and avoid some frustrating moments.

Some bugs/issues do not need elaborate processes to reproduce because the problem lies entirely with the software you are testing.  E.g. If I try to login and the login code allows everyone to pass through, it will behave the same from any browser/platform.

However, in some other cases, the problem is caused by the software and components that it uses. What can be the dependent componets, JDK version, Platform (which platform? which version (including special packs), permissions), Firewall, Proxy (including authentication types), Databases (if being used).

A few instances that I can think of is:

1. database configuration – we were using mysql as the database backend and for some particular dataset the operation just failed. The logs and further Googling revealed that a setting on the mysql server and client side defines the maximum size of the packet that can transferred. The default value is 1 MB and it was failing when the packet size exceeded the default value.

2. jdk version – okay, this is specific to java based applications. In many cases, there are issues of jdk version mismatch – wherein the software is expecting one version but is forced to use another – which cause the operation to fail. If you are lucky, a simple change in classpath may do the trick in this case.

3. software quirks: We are trying to use the latest STABLE  version of a component your software depends on ,taking backward compatibility of the software for granted. This may not always be the case. Do remember, however, that if the software fails in this case the culprit could be the component or your own software. Let us say the standards have been updated and one of them does not conform to the latest.

It is very important for a tracking mechanism to ensure that such issues are searchable. Helps in creating test cases/scenarios not just for the issue under focus but for related areas too.