InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Regression defects and impact prediction based on recorded events.

IP.com Disclosure Number: IPCOM000240484D
Publication Date: 2015-Feb-03
Document File: 2 page(s) / 42K

Publishing Venue

The IP.com Prior Art Database


Huge product deployments produces tones of information such as: log files. Not all entries (logged errors) represent functionality failures. There are also so called 'expected" errors (false positive), for example: when some prerequisites are not found. The problem is: - how to determine real functionality break basing on information included in product (mostly logs) - how to estimate issue/error impact to customers Such information is key decision maker before new product release (is error entry indicating stop ship issue or is minor failure). It is also very important in context of mass/heavy tests (scale, longrun, system). Such data analysis will allow to reduce costs of maintenance.

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

Page 01 of 2

Regression defects and impact prediction based on recorded events .

To solve problem described in abstract section one need to adopt pattern learning algorithm. As a training set defects created and solved in the past can be used. Each defect record contains description and set of logs. Such logs and defect description can be used as learning pattern. If similar pattern is found in current build the correlation

with failed feature and impact is being made automatically.

1. First step is to create knowledge database (getting information from defects repository ) with links between historical reported issues and events logs attached to

work item. We want to extract information such as:
- stack traces (content gives us information about part of product corrupted) - order
- and time frame of them.

In defect repository work item (defect) there are also names of corrupted classes from change sets delivered during fix process.

2. Second step is to use runtime product information, for example: logs to "match" with database and find potential issue (with some probability). Matching input data to one of output classes will be provided by pattern recognition algorithms. In our case those output classes are RTC, work items. As a result we predict (with some probability) description of issue and importance based on current sequence of specific events. Importance of issue is also estimated basing on correlated defects severity + priority + odc_impact.

This solution will significantly reduce costs of high level tests maintenance by pointing failure affected product areas/components without need of functional testing. Nowadays, such mai...