Your developer can never say "no repro" to your bug ever again!

You have already used the bug tracking system (WIT) in TFS before. So, we integrated this bug tracking system with MTR so that you can file bugs with a single click from the runner itself. What's the big deal about this you might ask?

Well, the big deal is that we not just create a bug for you from the runner itself, we also populate it with the test case that you have just been executing when you opened the bug. And that too in this neat little repro steps control with a tab of its own in the bug form. (Yes, we modified the MSF template to include some extra tabs in the default bug) So, all comments that the tester has written, notes she has taken, attachments that she has made are all uploaded automatically to the bug from the first step to the last failed step.

 

Now, how often have you hit a bug during testing that would just repro on your test machine but simply would not repro on the dev machine. And how often has it turned out that it was a configuration related issue - different service packs, different CPU usage, different memories, the list is endless. To ensure that the developer gets a complete picture of the environment where the bug was actually produced, we fill in system information about the test machine automatically into the newly created bug. Check out the "system info" tab within the bug form:

 

Now, even with all of these, what if the developer still cannot repro the bug? Perhaps it was a domain expert that filed the bug and not a technical tester. He/she may not have noticed subtleties that might have affected the system and caused the bug. Or the bug repro steps or description maybe woefully inadequate for the developer to produce a reasonable repro. In such cases, the video recording that the runner makes in the background during all test execution, will be considerably useful. Playing back the video will give the developer a very detailed and accurate picture of the exact steps leading up to the bug. This video is filed as an attachment to the bug

What if the test itself took 10 long minutes. Now, the failure is in the last step perhaps. The developer may want to look at only the failed step instead of the whole long video. Video markers are the way to go for that. Each time the tester marks a test step in the test case, a video marker is inserted with that timestamp in the video file. These markers are then populated against the test steps in the repro steps of a bug filed via the runner. When I click on these markers, I can play back from the point where the previous step was marked. This gives the developer finer control over what portions of the video file may be useful.

 

So, how do you like our actionable bug? Are there any other ways we could help developers get the maximum effective amount of information from the bugs?

Comments

• Anonymous
  December 05, 2007
  PingBack from http://www.absolutely-people-search.info/?p=3443

• Anonymous
  December 06, 2007
  The comment has been removed

• Anonymous
  February 28, 2008
  I had a session with a customer where they wanted to know a bit on what is coming in Rosario and 1 or

• Anonymous
  March 25, 2008
  very interested in the model you present here. The saliva without the pleasure ? Is there any way you can provide a download link to the special Work item bug presented here ? Thanks a lot.BenJee.

• Anonymous
  August 13, 2008
  I like this new development of bug reporting functionality. Automatic upload of the relevant supporting information should cut down the tester's effort in reporting a bug. Though the amount of data collected is large, this will certainly help in minimizing non-reproductions of recent bug reports (developers might still be unable to reproduce older bug reports due to a number of changes in the application e.g. missing functionality to reach the point after which the test steps can be executed to repro the bug).

• Anonymous
  December 07, 2008
  I am sure the things you have done are really beneficial. What else you can do depends on what resources you have. For eg: In QTP9.2, you have this feature in which you can make a video of what's happenig in your software when u run a particular test which I find very interesting. For a complete manual test,you either need to have developer by ur side before filing the issue or you must check it on machines with different configurations before going ahead with filing.

• Anonymous
  December 21, 2008
  Hi folks - sorry for delayed responses...hope you will read this response at some point of time.Ahmed and Benjee - watch out for this space, I'll soon post a link to bits you can try out for thisInder - thanks for your comments. Do try out our CTP bits and tell me what you thinkJaanvi - great blog, looking forward to hearing more from you on test runner