One of the common answers a developer gives when s/he notices a bug is that “it works in my machine”. This was so common and always boils down to the configuration difference between the testing environments and development environments. It is not so easy to keep the development and testing environments very similar but lots of those could be scripted and made automated such that it is an executable document. There are also lots of development hygiene practices that needs to be strictly adhered to avoid these kind of bugs.

Where could things go wrong?

There are many things that could go wrong, here are some of them in no particular order.

1. Poor version control – Either the code is not checked in(sometimes extra files locally modified for debugging) or the branching/merging is mismanaged.
2. Incorrect dependencies and libraries – The dependencies/libraries are manually copied to the servers. Example – copying some jar files to tomcat, could easily go out of version between different machines.
3. Testing only in debugging mode – When testing at the developer’s machine, developers have a tendency to run in debug, breakpoints in the code will give ample time for the application so that synchronous issues do not crop up during developer’s testing.
4. Not testing at all – This sounds silly, but when the pressure is high chances are that the code is committed without tests and then bugs have to appear to give time to finish the coding.
5. Incorrect environments and test data – Large projects have a tough time managing test data and environments, developers could be pointing to an outdated external environment or using only a narrow set of test data.

“Image courtesy of Grant Cochrane / FreeDigitalPhotos.net”.