Eggplant DAI: What Is Digital Automation Intelligence and How Does It Work?

Eggplant DAI — Digital Automation Intelligence — is Keysight's attempt to add intelligence to what was historically a script-based, image-matching test automation platform. It's the layer that sits above Eggplant Functional and makes the whole platform more than just VNC-based UI automation.

Understanding DAI means understanding two things: what problems it was designed to solve, and how its architecture actually delivers on those promises.

The Problem DAI Was Built to Solve

Traditional Eggplant Functional testing is script-centric. You write SenseTalk scripts, each covering specific test scenarios. As applications grow in complexity, you accumulate hundreds or thousands of scripts. Several problems emerge:

Coverage blindness: You don't know what you're not testing. Scripts cover the paths someone thought to write. Untested paths are invisible until a bug surfaces in production.

Coverage redundancy: Different teams write tests that overlap significantly, wasting execution time on duplicate paths while leaving other areas untested.

Maintenance debt: When applications change, you need to identify and update all affected scripts. With hundreds of scripts, this is slow and error-prone.

No risk visibility: Not all test failures are equally important. Without a model of the application, you can't distinguish between a critical failure in the checkout flow and a cosmetic bug in the settings page.

DAI was designed to address all four of these problems through model-based testing, AI-driven coverage optimization, analytics, and risk modeling.

DAI Architecture

DAI has a layered architecture that separates test modeling from test execution.

The DAI Server

The core of DAI is a server application (runs on Linux, typically containerized) that manages:

• Behavioral models — the state machine representations of your applications
• Test cases — generated from models, linked to Eggplant Functional scripts
• Execution history — results from every test run, stored and analyzed
• Analytics engine — coverage analysis, risk modeling, trend tracking
• Coverage optimizer — AI that generates and prioritizes test cases

The DAI server exposes a web UI for model management and analytics, plus a REST API for CI/CD integration.

Connection to Eggplant Functional

DAI manages tests; Eggplant Functional executes them. The connection works like this:

1. DAI selects test cases to run based on coverage goals and risk model
2. DAI calls Eggplant Functional (via API or test runner) to execute the selected tests
3. Eggplant Functional connects to SUTs, runs image-based test scripts, and reports results
4. DAI collects results, updates execution history, and recalculates coverage

You can also run DAI without Eggplant Functional by integrating with other execution engines (Selenium, Appium, etc.) through DAI's connector framework — though Eggplant Functional remains the primary execution engine.

The Behavioral Model

The behavioral model is a directed graph stored in DAI:

• Nodes = states (application screens or conditions)
• Edges = actions (transitions between states)
• Labels = coverage requirements, risk weights, and conditions

Building the model is a human task. DAI provides a visual model editor where you create states, define transitions, and annotate with metadata. The model doesn't auto-generate from your application — you build it based on your knowledge of the application's behavior.

This is DAI's most significant implementation effort. A thorough model for a complex application takes weeks to build correctly.

Model Coverage Types

DAI supports several standard test coverage criteria:

State coverage: Every state in the model is visited at least once. Minimum viable coverage — proves the application can reach every screen.

Transition coverage: Every transition is traversed at least once. Stronger than state coverage; proves every action can be performed.

State-transition coverage (n-switch): Every sequence of n transitions is exercised. Catches bugs that only appear when actions are performed in combination.

Round-trip coverage: Every state can be entered and exited completely. Verifies the application can complete full use cases.

For most applications, transition coverage is the practical minimum for meaningful regression testing. Deeper coverage criteria are applied to high-risk areas.

The Coverage Optimization Engine

Given a model with hundreds of states and transitions, and a coverage goal (e.g., "achieve full transition coverage"), DAI's optimizer generates a minimum test suite — the smallest number of test cases that achieves the coverage goal.

The mathematical foundation is graph theory: finding minimum path covers in directed graphs. DAI solves variants of this problem with additional constraints:

• Some transitions have preconditions (you can only reach checkout if you have items in cart)
• Some paths are computationally expensive and should be minimized
• Some states require specific application setup before they can be reached
• Risk weights influence which paths get prioritized when trade-offs are needed

The optimizer runs as a background service, regenerating the recommended test suite as the model changes or as execution data updates the risk model.

In practice: For an application with 200 states and 800 transitions, the optimizer might recommend 50 test cases that achieve full transition coverage, compared to 800 individual scripts you'd write manually for the same coverage.

Risk Modeling and Defect Prediction

DAI's risk model accumulates over time as test execution data is collected. For each state and transition in the model, DAI tracks:

• Historical failure rate
• Time since last execution
• Rate of change (how often this area of the app is modified)
• Test stability (flakiness rate)
• Coverage density (how many tests exercise this area)

From these signals, DAI calculates a risk score for each model element. High risk scores indicate areas that:

• Fail frequently
• Haven't been tested recently
• Are actively being developed

When generating test recommendations, DAI weights high-risk areas more heavily. The result is a test suite that allocates testing effort proportional to risk — spending more time where failures are more likely.

This is particularly valuable for release decisions. Before a release, teams can request a "risk-optimized test run" that executes the highest-risk paths first. If time pressure requires cutting the test run short, you've at least covered the areas most likely to have problems.

Exploratory Testing Mode

DAI includes an exploratory testing mode where the AI drives the application autonomously, discovering behavior without predefined scripts.

How it works:

1. Define a starting state and a time budget
2. DAI connects to the SUT via Eggplant Functional
3. The AI navigates the application, trying available actions from each state
4. It records discovered states, transitions, and any anomalies
5. Results are stored in the model for review

Exploratory mode is useful for:

• Initial model building (discovery what states exist)
• Testing areas of the application that haven't been modeled yet
• Regression checking after large changes

The AI in exploratory mode is basically reinforcement-learning-style navigation: it tries to visit unseen states, avoid dead ends, and maximize coverage within the time budget. It's not creative in the way a human exploratory tester would be — it won't intuitively test unusual edge cases — but it's systematic and tireless.

Analytics and Reporting

DAI's analytics layer provides dashboards for:

Coverage trends: How coverage has changed over time. Are you testing more or fewer states this week compared to last month?

Execution efficiency: What percentage of test execution time is spent on redundant coverage? How long does it take to achieve your coverage targets?

Risk heatmaps: Visual representation of where risk is concentrated in your application model.

Failure analysis: Which tests fail most often? Which parts of the application are most unstable?

Release readiness: Given your current test results, what's the estimated risk of releasing? DAI can generate a release readiness score based on coverage and failure data.

These analytics are genuinely useful for QA managers and engineering leaders who need to communicate testing status to stakeholders and make data-driven release decisions.

CI/CD Integration

DAI exposes a REST API for CI/CD integration. Typical pipeline integration:

# Example GitLab CI integration
test:
  stage: test
  script:
    # Trigger DAI to run the recommended test suite
    - curl -X POST "https://dai-server/api/test-runs" \
        -H "Authorization: Bearer $DAI_API_KEY" \
        -d '{"modelId": "checkout-flow", "coverageGoal": "transition", "riskWeight": "high"}'
    
    # Wait for completion and check results
    - ./scripts/await-dai-completion.sh $RUN_ID
    
    # Fail pipeline if coverage below threshold
    - ./scripts/check-coverage-threshold.sh 80

DAI can also integrate with:

• Jenkins: Official plugin available
• Azure DevOps: REST API integration
• Jira: Test result synchronization via Xray integration
• qTest: Test management integration

DAI vs. Eggplant Functional Without DAI

Many Eggplant users run Eggplant Functional alone without DAI. Here's what you're missing:

DAI adds significant value for large test estates. For small teams with a few hundred tests, the model-building overhead may not be worth it. For enterprise teams with thousands of test cases across complex applications, DAI's optimization capabilities can meaningfully reduce testing time and improve coverage quality.

DAI Pricing and Licensing

DAI is licensed separately from Eggplant Functional. Pricing is negotiated enterprise-style — Keysight doesn't publish list prices.

Rough market data suggests:

• Eggplant Functional: $15,000–$40,000/seat/year
• DAI: adds 30–100% on top of Functional licensing
• Total platform for an enterprise team: $100,000–$500,000+/year

This pricing makes DAI economically viable only for large organizations where testing failures have significant business consequences — financial services, healthcare, telecom, defense.

Getting Started with DAI

1. Prerequisites: Running Eggplant Functional instance, Linux server for DAI
2. Install DAI server: Docker-based deployment or VM installation
3. Connect to Functional: Configure API connection between DAI and Functional
4. Build initial model: Start with one application area, define 10–20 states
5. Generate first test cases: Use DAI optimizer for your modeled area
6. Run and collect data: Execute tests, let risk model start building
7. Expand coverage: Add more model areas incrementally

Keysight Professional Services typically does the initial DAI deployment and model-building for enterprise customers. It's not a tool you stand up in an afternoon.

Summary

Eggplant DAI is a sophisticated test intelligence platform built on top of Eggplant's image-based execution engine. Its model-based testing, coverage optimization, risk modeling, and analytics capabilities provide real value for large enterprise test estates.

The investment required — in tool cost, model-building effort, and operational complexity — is substantial. It pays off at scale in organizations where testing complexity and business risk justify the overhead.

For most teams building modern applications, the combination of open-source test tools and AI-powered test generation (like HelpMeTest) provides equivalent intelligence at a fraction of the cost and complexity. DAI is the right answer for the right problem — and that problem is large, complex, mixed-technology enterprise testing.