Browse Prior Art Database

Generation of user experience capabilities diff between two baselines in a code repository Disclosure Number: IPCOM000237168D
Publication Date: 2014-Jun-06
Document File: 6 page(s) / 80K

Publishing Venue

The Prior Art Database


Disclosed is a system to help software developers identify the unexpected changes in the product behavior between changes without rebuilding and manually testing the product. The system enables the user to generate a visual diff of the behavior change of a product from two different baselines of a code base (e.g., before and after a set of changes), which makes defects easily visible.

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

Page 01 of 6

Generation of user experience capabilities diff between two baselines in a code repository

Software engineering is about evolving code in a predictable manner to introduce features without introducing defects . The complexity of many software code bases makes it very difficult to predict and quickly find unexpected side effects of code changes . Often, defects are found later in the software development cycle; thus, those defects are expensive or sometimes impossible to fix before a release. The earlier developers can find and fix a defect, the less expensive it is to fix. Once a defect is found, it can be difficult to trace through and find the code change that caused the defect . The more code changes that have occurred since the defect was introduced, the more difficult the process becomes.

To help avoid introducing the bug at all, or quickly identify bugs, code reviews are often done by a peer developer who is familiar

with that code. Sometimes the peer developer can predict the defect before it is introduced , preventing it from being introduced entirely. However, it is very difficult to know all the side effects of a code change by looking at the code change itself .

Once a defect is found, a developer typically can determine what code has changed since the defect was introduced. This can be done using existing code repository tools and comparison tools, by creating a diff of the code base from before the bug existed to the present day. This diff highlights the changed lines of code between the two baselines of code . Often, a great deal of code has been changed, which makes it difficult to determine which code caused the issue. Unless familiar enough with the code to know exactly where to look, the developer often needs to bring down the code at different times , retest the bug, and narrow down which change caused the bug. This can be time consuming because a build of the code is required every time the developer brings the code down and sets up the testcase.

Software defects are ultimately caused by an undesired change in the behavior of the product for a given set of usage scenarios . If the product behavior has not changed at all, then no defect could be introduced. If the product behavior has changed in a predictable, desired manner only, then no defect was introduced. Therefore, to easily identify which code change introduced a defect, the user simply has to be able to understand how each change in the code has changed the behavior of the product .

The solution consists of generating a state diagram describing the different actions the product allows the user to perform in each state. This diagram effectively captures the entire behavior of the product. Alone, such a diagram is overwhelmingly complex for much of the real world software solutions. Fortunately, the process only requires the parts of that diagram that have changed between two baselines of the code base. For this purpose, the invented system is able to ge...