ML-Based Shadow Testing for Software Change Anomaly Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software development methods require significant manual effort and cannot effectively test production changes without impacting end users, failing to simulate production-like traffic patterns and leading to potential performance degradation.

Innovation Solution

A system utilizing machine learning, specifically deep reinforcement learning models, creates isolated environments to test new application versions, analyzing baseline and candidate instances for anomalies, generating reports without user impact, and providing insights early in the development process.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual testing is performed by developers to test proposed changes, then potential performance degradation can be detected, but significant manual effort and time are required

Engineering Contradiction:
Improvedetection of performance degradationVSAvoidmanual testing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system enables self-service automated testing where the testing framework automatically executes tests, analyzes results, and generates reports without requiring developer intervention. The system autonomously manages the entire testing lifecycle including test case execution, anomaly detection, and report generation, freeing developers from manual testing tasks while maintaining reliable performance degradation detection.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces the mechanical manual testing process with an automated computer-based testing system. The system uses automated test execution engines, machine learning models for anomaly detection, and automated report generation to substitute the manual mechanical actions of developers performing tests, thereby eliminating time consumption while preserving detection capability.

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

2Reliability

If trial deployment is performed to test new features, then real-world performance can be evaluated, but user requests are sacrificed when issues are detected

Engineering Contradiction:
Improveevaluation of real-world performanceVSAvoiduser request failures
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The system creates a shadow or copy of the production environment where testing can be performed without affecting real users. By replicating production traffic patterns and system configurations in a test environment, the system enables real-world performance evaluation while isolating test subjects from actual user requests, thus eliminating harmful failures.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The system performs preliminary testing in a controlled environment before changes are deployed to production. By conducting automated tests that simulate production conditions in advance, the system identifies potential issues before they reach real users, preventing user request failures while still enabling real-world performance evaluation through realistic test scenarios.

Inventive Principle:
Principle #10Preliminary action

3Loss of time

If existing testing systems are used to test production changes, then changes can be tested earlier in the development process, but production-like traffic patterns cannot be simulated

Engineering Contradiction:
Improvetesting stage timingVSAvoidsimulation of production traffic patterns
Core Design Contradiction:
Loss of timeVSAdaptability or versatility

Solution Approach 1:

The system dynamically adapts test configurations to match production traffic patterns. Rather than using static test scenarios, the system continuously adjusts test parameters, load patterns, and data characteristics to reflect actual production conditions. This dynamic adaptation enables early testing while maintaining versatility in simulating various production traffic scenarios.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes key parameters such as traffic volume, request patterns, data distributions, and system load to accurately replicate production environments. By systematically varying these parameters to match production characteristics, the system achieves both early testing capability and accurate production-like simulation, overcoming the limitations of existing static testing systems.

Inventive Principle:
Principle #35Parameter changes

4Productivity

If automated testing systems are implemented, then manual effort is reduced, but complexity of the testing system increases

Engineering Contradiction:
Improveautomation of testing processVSAvoidtesting system complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system achieves high productivity through a unified automated testing platform that performs multiple functions including test case management, execution, anomaly detection, and report generation. By consolidating these diverse testing activities into a single multi-functional system, the patent reduces the need for multiple separate tools and processes, thereby managing complexity while maximizing automation benefits.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS20260044434A1Systems and methods for automatically testing changes to a software application using machine learning
Publication Date: 2026.02.12 WALMART APOLLO LLC
  • US20260044434A1 patent drawing
  • US20260044434A1 patent drawing
  • US20260044434A1 patent drawing

AI summary

Systems and methods for automatically testing changes to a software application using machine learning are disclosed. In some embodiments, a disclosed method includes: obtaining, from a computing device, a request for a proposed change to an application; generating at least one baseline instance running an existing version of the application before the proposed change; generating a candidate instance running a new version of the application based on the proposed change; performing an analysis on the at least one baseline instance and the candidate instance to determine, using at least one machine learning model, whether an anomaly exists in the candidate instance; generating a report for the proposed change based on the analysis; and transmitting the report to the computing device.