Browse Prior Art Database

Continuous integration between source code repository, static code analysis tools, bug tracking system and code review tools.

IP.com Disclosure Number: IPCOM000238236D
Publication Date: 2014-Aug-12
Document File: 3 page(s) / 84K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes the continuous integration between source code repository, static code analysis tools, bug tracking system and code review tools. By integrating source code repositories, static code analysis tools, bug tracking systems and code review tools, developers can be told of previous bugs and the code that caused the defect in the component they are about to work on, testers can be informed of what components are changing, previous bugs in these components and the test cases that found them.

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

Page 01 of 3

Continuous integration between source code repository, static code analysis tools, bug tracking system and code review tools.

Defects/bugs filed on prediction of possible errors based on ranking and complexity of code being written by a developer.

Tool to identify where the bugs are going to be and what the bugs are likely to be. Intelligently advising of possible outcomes based on trends of developer and code, Component, team current code.

Automatically kicking developer off code!

    Currently when a developer starts to write code they are not aware of previous issues in the code unless the code is well commented, the source code history contains detailed check-in comments or they look up the bugs database, previous defects by the developer on other components can also be shown.

    By knowing what the previous issues were the developer is unlikely to create them again.

    When the developer makes a change to some code, the tester (e.g. RQM) can be informed of relevant interfaces effected and the test cases that will need to be run for this change.

    When testers start to test a component they tend to focus on the test cases to be run with little regard for old defects against the component and with no knowledge for the developers previous defects.

    By knowing the previous defects of the component they are about to test and defects by the developer, new test cases can be created to reduce the risk of similar issues reoccurring.

    When a defect is found the tester can be informed of the developer that made the change and other areas the developer worked on, this can help find defects caused by cut and paste coding.

    In code reviews the reviewers can be informed of likely issues based on the track record of the developer(s) making the changes to the code being reviewed. Software Defects Classification Prediction Based On Mining Software Repository http://uu.diva-portal.org/sma...