Browse Prior Art Database

Defect Event Visualizer Disclosure Number: IPCOM000235868D
Publication Date: 2014-Mar-28
Document File: 3 page(s) / 44K

Publishing Venue

The Prior Art Database


As an example let us consider a simple example. During the release time, it is very important for the stakeholders to monitor the defects very closely. For analyzing the defects, current defect tracking systems (including Rational) does not allow stakeholders to get the overall view of the defect without going through the notes (comments) made by participants (testers, developers etc.). Same discussion can be applied to L3 teams (while PMR handling they might move across different queues), Project Line Items. As an example, it is very difficult to get the answers for the queries below: How much time spent by developer for the defect? How much time spent by tester for the defect? What is the time being spent by different teams (especially if the defect moves around different teams)? What is the age of the defect? What comments made by developer before returning? Export the comments made by either developer or tester Mail the developer or tester directly from defect What is the contact of developer (or tester): Contact, First Line manager, Second Line mgr etc? How much time spent by build team for making the defect to verify state?

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 73% of the total text.

Page 01 of 3

Defect Event Visualizer

This document tries to resolve the queries mentioned above. The objective of this proposal is to make the defect tracking easy with visual elements.

The diagram below describes the idea visually and here are the important points which need special attention:

 The horizontal top line indicates the numbers of days (time) spent by participants of the defect. The left hand side is the time spent by developers and right hand side the time spent by testers. Also, note that the time scale (number of days in this case) should be configurable and auto changeable depending on the time spent by participants.

 The visual elements should be configurable by the administrator. They can select any symbols to match their need. In the example we have used some sample symbols but these are not fixed.


Page 02 of 3

 In some cases, the state change will not change the owner and in that case we continue in the timeline of same owner. For example, before changing the state to verify the defect continues to be in developer timeline.

 We can add many other features like:
o With mouse hover on comment, we can create a pop-up with the comment (note) made by the participant.

o With mouse hover on state, we can create a pop-up with the state help information or any other useful information.

o With mouse hover on participant, we can create a popup with the participant information (contact, mail ID, manager ID, second line manager ID etc.).

o With mouse cli...