Browse Prior Art Database

Method to Expedite Defect Resolution Via A Learning System That Leverages Expertise Of The Function Owner

IP.com Disclosure Number: IPCOM000238976D
Publication Date: 2014-Sep-29
Document File: 5 page(s) / 82K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method to expedite defect resolution via a learning system that leverages expertise of the function owner is disclosed.

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

Page 01 of 5

Method to Expedite Defect Resolution Via A Learning System That Leverages Expertise Of The Function Owner

Disclosed is a method to expedite defect resolution via a learning system that leverages expertise of the function owner.

Hardware and Software development involves architecture, design, assembly/build or coding followed by test prior to product release. Testing entails various phases starting

with unit testing, followed by functional and then system level testing. The test approaches may differ a bit depending on the development model in use. One may have test phases that focuses on verifying the function from a customer perspective. If the function doesn't perform as expected, defects are opened which describe the test environment, operation being performed, expected behavior versus observed behavior. Since testing in later phases may be done by personnel not intimately familiar with the internal design of the function, the defect originator makes an educated guess on the likely problem subsystem or component. The assigned subsystem/component owner (usually a screen team) reviews the defect and the included data. If necessary the initial screeners collect and include additional debug data in the defect before assigning it to a lower level component. This process of data collection and component assignment continues until (a) sufficient relevant (debug, traces, First Failure Data Capture (FFDC) logs, etc.) data is collected to ascertain problem component and (b) for the final component owner to determine root cause. Thereafter the final component owner is able to provide a fix for the noted issue.

Current approach to address problem: Test personnel are instructed to collect specific debug data based on the suspected problem sub-system/component. The screen teams of these subsystems request additional debug data if the captured information proves insufficient to isolate root cause. Unless the system is at fail state (which is typically not the case) the problem must be recreated. The process repeats as the screen team assigns the defect to sub components within the subsystem. The current approach relies on the experience of test personnel to know the type of debug information that needs to be collected based on the suspected subsystem/component. Since test personnel don't have intimate knowledge of the internal design of the function being tested, they go through a learning process before they can collect the right information needed for specific components.

Current approach problems:

The current defect resolution is often very time consuming.

In many cases, multiple recreates are required as the defect is transferred between components owners who require additional debug data to first isolate problem area and then root cause.

The current approach mandates learning and expertise of test personnel to collect necessary debug data for a wide range of system components. This is impractical and at best is limited to a few highly s...