The Never Ending War of Software Constructors and Software Destructors



How many times we as developers curse about the fact that, the defect raised by a tester doesn’t have enough information to reproduce it in the local environment?! I guess, the answer is quite often. If we are dealing with a responsible tester, he/she will provide us with detailed steps, if they are also kind enough, we will in addition get some logs and screen shots, and there ends the matter.

Then, we struggle to reproduce it most of the time and would sometimes retort with the most common statement, “Hey! It works in my environment.”, and reject the defect. Sometimes the ball endlessly moves to and fro between the 2 courts.

Why are we still living in the era of our great grandfathers, when it comes to debugging defects? I know, most of us are aware of the tools like IntelliTrace that are available to deal with this exact problem. But, I rarely see even developers making use of this tool, to reduce their debugging effort locally, leave aside testers to provide it as part of MTM to collect IntelliTrace data, that can be furnished for developer assistance, to reload it in his/her environment. When you are pushing someone off a cliff, why not at least show some mercy by giving the person a rope, so that he/she would have some chance of getting up there again?!

Most of the organizations use QC and QTP as their testing framework. I know, they are great in their own right, but from a developer point of view, they are very inferior compared to MTM. I perceive, quality as a combined effort of every stakeholder of a team. The problem I see with them is that, they eliminate developers out of the quality equation, by treating them as second class citizens, without any great aids provided to them.

I know, it is a far cry to justify people to migrate from QC/QTP to MTM, leaving aside lot of other benefits that these tools provide compared to MTM, along with additional cost that it incurs for migration, infrastructure and software procurement, though it highly benefits developers, and the clean integration that it brings to the table, especially when there are suite of apps built around .NET in an enterprise.

With Visual Studio 2010, the MTM gives testers the ability to author, manage and execute both manual and automated tests and also offers them the ability to have diagnostic information collected in the background while a test is executing. They  can also automatically collect things like a video recording of the test being executed, so the developer can see exactly what the tester saw, collect system information and Event Logs from the box being tested on, etc.

After a long story, I am finally coming to my main intention of writing these musings i.e., to let all the developers know about this great tool, called IntelliTrace, that will benefit us highly, in local debugging.  Wouldn’t it be great if we could just break into the process, after the error occurred, and get a history of what happened in the application from Visual Studio? While you’re debugging, IntelliTrace collects data about various events that occur in a managed application, in the background. These IntelliTrace events allow the developer to see what has previously occurred during execution, and to “step back in time” to see prior states of the application without having to restart the debugger.

When you break into the debugger, you are presented with a sequential list of the IntelliTrace events that were collected, along with all debugger windows, such as the Call Stack and Watch, that show data relative to the event itself, so it’s like you were debugging the instant that exception was thrown. In addition, just like walking up a call stack, the editor will open the appropriate source file and highlight the line of code corresponding to the event in orange to represent IntelliTrace.

PFB the link that provides a great explanation about using IntelliTrace for developer debugging, and also talks briefly about collecting trace data as part of MTM –
http://msdn.microsoft.com/en-us/magazine/ee336126.aspx

Comments

Post a Comment

Popular posts from this blog

Chrome Extension - Tab Keeper

Opening too many tabs is one of the biggest memory hogs for the Chrome browser. In my search to find the most elegant solution to this problem, I stumbled upon Jacob Singh's Tab Wrangler extension. It is perfect for my needs, except for the fact that it doesn't store tabs in a feel secure way and sync across all my computers. I didn't find a better way to achieve this, except using chrome Bookmarks. I have modified the code to support this feature, so users can now optionally save all the closed tabs in Other bookmarks  folder in chrome. Recent items are stored in Current folder, and older items are archived based on max tabs setting, to  History folder within different timestamp folders, each containing previous sets of archived tabs.
Read more

The life of a software developer, who can never write a program as efficiently as his manager wants it, for the first time.

During one of my friendly conversations with my father, who is a layman in terms of software development, he asked me, why I had been working almost for a year to develop a simple application called Payroll, which he had always paid from his pocket directly. He felt that, I must work on improving my efficiency as a programmer, as my manager tells me all the time. My blood was boiled, and I felt like opening the 100s of pages specs documents that undergo 10s of revisions, or the long spread sheets containing 100s of earnings and deductions to explain the complexity. But the fact of the matter is, he doesn’t understand most of them, and I also don’t know everything in them. So I thought, why wouldn’t I explain him through a simple story, why it takes so much time to develop a simple software, in general, and why there is a need to change it quite often? Once upon a time there was a product manager, who found an intriguing opportunity and a huge market potential, to develop an ap
Read more