Risk-Based Root Cause Identification for Software Test Failures

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In modern software development, especially for cloud-based applications, identifying the root cause of test failures among multiple changes in source code is time-consuming and resource-intensive due to the large number of test cases and complexity of the code, making it difficult to determine which specific change caused a test failure.

Innovation Solution

A risk-based analysis method is employed, where a risk score is assigned to each change based on its characteristics, allowing for the identification of the most likely root cause of a test failure. This involves a risk calculation model that calculates a score for each change, and by iteratively re-executing tests with modified updates that include only the highest risk changes, the probable root cause is isolated without the need for exhaustive search algorithms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If automated software testing is used to verify code correctness, then testing coverage and reliability are improved, but the time and computational resources required to identify root causes increase

Engineering Contradiction:
Improvetesting coverageVSAvoidtime to identify root cause
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the source code into multiple changes and assigns risk scores to each change based on characteristics such as code complexity, test coverage, and change magnitude. This segmentation allows the system to identify and focus on the most likely root cause changes rather than examining all changes equally, thereby reducing the time required to identify root causes while maintaining comprehensive testing coverage.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces risk scoring as a new parameter to prioritize changes during root cause analysis. By calculating risk scores based on multiple characteristics (code metrics, test results, change patterns), the system transforms the root cause identification process from a brute-force approach to a targeted approach, significantly reducing analysis time while preserving testing reliability.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If comprehensive automated tests are executed against multiple code changes, then code quality is improved, but computational resources and processing time increase

Engineering Contradiction:
Improvecode qualityVSAvoidcomputational resources
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent segments the set of all code changes into individual changes with calculated risk scores. By processing changes in order of descending risk score, the system can often identify the root cause after analyzing only the highest-risk changes, avoiding the need to exhaustively process all changes. This segmentation strategy maintains code quality assurance while reducing computational resource consumption.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies partial action by executing test analysis on only the necessary subset of changes (those with highest risk scores) rather than all changes. The system determines when sufficient information has been gathered to identify the root cause and stops further analysis, thereby conserving computational resources while maintaining code quality verification.

Inventive Principle:
Principle #16Partial or excessive action

3Measurement precision

If iterative search algorithms are used to identify test failure causes, then accuracy in root cause identification is improved, but productivity and development velocity decrease

Engineering Contradiction:
Improveroot cause identification accuracyVSAvoiddevelopment velocity
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent performs preliminary action by calculating risk scores for all changes before the actual root cause identification process. This pre-calculation of risk metrics allows the system to immediately prioritize changes without requiring iterative search during the analysis phase, thereby maintaining high identification accuracy while significantly improving development velocity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent substitutes the mechanical iterative search algorithm with a risk-based prioritization system. Instead of repeatedly executing tests with different change combinations to converge on the root cause, the system uses pre-calculated risk scores to directly identify the most likely culprits, replacing the iterative mechanical process with a more efficient calculation-based approach that maintains accuracy while boosting productivity.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS11836072B2Risk-based root cause identification methods and related autobuild systems
Publication Date: 2023.12.05 SALESFORCE INC
  • US11836072B2 patent drawing
  • US11836072B2 patent drawing
  • US11836072B2 patent drawing

AI summary

Database systems and methods are provided for identifying a change associated with an update to executable code resulting in test failure. One method involves calculating risk scores for different changes associated with the update based on change characteristics associated with the respective changes, identifying a change from among the different changes associated with the update based on the risk scores associated with the respective changes, generating a modified update to the executable code that includes the identified change and excludes remaining changes of the update from the modified update, and initiate execution of one or more tests with respect to a compiled version of the modified update to the executable code. When execution of the one or more tests against the modified update results in a test failure, the change is identified as a potential root cause of the test failure associated with the update.