Software Tester's Desk

Any time someone discusses what are the qualities which a good software tester should posses, this note certainly comes up that he needs to know coding. That's when he can identify and dig deep into code and do more deeper levels of testing. But there is one quality which is more important Troubleshooting skills. I feel good troubleshooting skills are going to take a good software tester into better levels. Skills to troubleshoot an issue would be important, as this would get to be a direct pointer into root cause analysis at times. More than anything, this would help the tester get more idea regarding the environment details (thereby environmental dependencies as well) and also expose some more scenarios which would probably be candidates to find interesting bugs.

Recently I had an experience with the same. There was an application which we had been testing for a while, and this application deals with network and also does lot of distributed transactions. The issue we faced was that the distributed transactions were failing and the error messages were not giving a clear picture on what the issue actually was. At first it misguided the team quoting performance counters' problem. Later on after doing some registry modifications, those errors vanished, still the application was not permitting normal operations which are the simplest of its functionality. The issue was escalated, a bug was created and lot many of minds went into the troubleshooting of the same. There wasn't any conclusion still on what the real issue was and my fellow colleague, working in agile, was facing the heat of his sprint coming to an end and lesser hours remaining to test the feature. It was then that we sat together to troubleshoot it in a more deeper manner.

So what we did was to go through the logs and see what the application says regarding the failure. It said "underlying transaction has failed" which implied some issue with distributed transactions getting failed. We checked the MSDTC configurations on all the machines which were part of the test bed, but the configurations were correct in all the machines, with authentication as required. We were at a road block there. Fortunately, I remembered that DTC requires to resolve the Computer Name through NetBIOS or DNS. I tried to ping the netbios name of the target machine and there lies the issue - it was giving me the ping response, but each time I pinged after flushing the dns entries, it was resolving a new IP Address instead of the correct one. It could've been an issue with our network, where the DNS server was responding in an incorrect manner. It could also be possible if there are multiple DNS servers running in the same network. With many server machines running linux, it is difficult nowadays to identify these kind of issues. Okay, now for some who are interested, how did we solve this issue? Quite simple. We made entries to map IP Address and hostnames of each of the machines in others' host file, there by by-passing the name resolution process. That's all!

How simple a solution was that, yet the time which one need to spend to solve these kind of issues, is really high. Thanks to my team, they have already documented this so that they do not get stuck the next time something like this comes up. :)

This also brings some more thoughts into my mind. If a person who possesses really good troubleshooting skills comes across this kind of a situation, he/she would have easily identified the solution fast. This would also open up a way to expand his test scope, as a new way has been exposed to him/her to break the application in this fashion. In my case, we could design test cases around with the separate authentication settings available for these kind of transactions. So every issue that come up will pave way to the tester for a better learning opportunity, provided he/she gets the hand into troubleshooting whether it is an application issue or if it is the environment!