Browse Prior Art Database

System and method to gather bug data and analyze for duplicates Disclosure Number: IPCOM000198744D
Publication Date: 2010-Aug-13
Document File: 4 page(s) / 56K

Publishing Venue

The Prior Art Database


Disclosed is a system and method to handle opening, tracking, and managing defects in order to enable awareness of potential duplicate defects.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 4

System and method to gather bug data and analyze for duplicates

Disclosed is a process to handle opening, tracking, and managing defects enabling awareness of

  otential duplicate defects. The disclosed process provides a capability for defect discovery, reporting, and duplicate identification that is automated and dynamic. When a tester is testing a system, actions will be "recorded" by the disclosed process that runs in the background to track actions of the implementing system and environment. The disclosed process enables logging of artifacts such as, but not limited to, threads, screenshots, log state, environment state, and


                       . Once a defect is identified, a tester informs a program of the disclosed process to make a snapshot of the current state including the mentioned artifacts. The disclosed process analyzes the artifacts and the "recording" along with the artifacts and "recording" of other defects to determine a percentage of intersections in logic paths and to determine likelihood of duplicate defects. The disclosed process typically catches most duplicates opened in the system by analyzing the artifacts and state of the system in each defect.

The disclosed process, depicted in Figure 1, enables awareness of potential duplicate defects. As the user is interacting with a program, the disclosed process logs data about what actions the user has taken in the program and corresponding effects on the system. When a user is performing an action and recognizes a defect, the user will notify the disclosed process. The notification may be as simple as clicking a "track bug" button in a browser when using a web application. Upon initiating bug tracking, the user may be prompted to enter additional information such as, but not limited to, keywords, detailed description, and classification. Entering values for these fields will be optional; however, not completing these fields will degrade the accuracy of duplicate



 rojection. Upon submitting the defect, user initiated data and logged data is packaged and sent to the bug tracking system. Logged data may consist of operating system information, any environment information including a screenshot, action history, running processes, memory/CPU consumption, and any other information that may be tracked and made available. Upon receiving the package of defect information, a defect is automatically spawned and the packaged data is associated with the defect. At this point, the bug tracking system inspects information from the packaged data to identify duplicates or other related defects.

A duplicate or related defect is identified by comparison of the packaged data with data associated with existing defects. Examples of data that may be compared to identify similarities and determine whether a threshold level for duplicate flagging has been met or exceeded include a list of actions used to recreate a scenario, a product/version/build number, environment and settings (for example, browser...