Docs/Enterprise/AI-Driven QA

AI-Driven QA with Sentience

Sentience enables self-healing, intent-driven QA for modern web applications.

Instead of brittle selectors and blind retries, Sentience verifies user-visible outcomes using structured snapshots from a live, rendered browser (post-SPA hydration).

Sentience does not parse static HTML and does not rely on vision by default.


Why traditional E2E tests flake

Most QA pipelines fail for reasons unrelated to product bugs:

This produces flaky tests, low trust, and high maintenance cost.

The core problem

Traditional tests retry actions. Sentience retries verification.


How Sentience approaches QA

Sentience treats QA as a verification problem, not a scripting problem.

Intent → Deterministic actions → Verified outcome

Key principles:


Example 1 — Eliminating flaky waits (self-healing verification)

Diagram (what happens)

┌─────────────┐
│ Test step   │
│ "Dashboard" │
└──────┬──────┘
       │
       ▼
┌─────────────────────────┐
│ Snapshot #1             │
│ confidence: 0.42        │
│ reason: dom_unstable    │
└──────┬──────────────────┘
       │ retry verification
       ▼
┌─────────────────────────┐
│ Snapshot #2             │
│ confidence: 0.78        │
│ stable                  │
└──────┬──────────────────┘
       │
       ▼
┌─────────────────────────┐
│ ASSERT PASS ✓           │
│ "Dashboard" visible     │
└─────────────────────────┘

What this replaces

Minimal example

await runtime.check(
  exists("role=heading text~'Dashboard'"),
  label="dashboard_loaded"
).eventually(
  timeout_s=10,
  min_confidence=0.7,
  max_snapshot_attempts=3
)

Sentience retries only while the page is unstable and stops deterministically.


Example 2 — State-aware QA without brittle selectors

Diagram (semantic verification)

┌─────────────────────┐
│ User expectation    │
│ "Continue is ready" │
└─────────┬───────────┘
          │
          ▼
┌──────────────────────────────┐
│ Rendered DOM snapshot        │
│ - button                     │
│ - text: "Continue"           │
│ - enabled: false → true      │
└─────────┬────────────────────┘
          │
          ▼
┌──────────────────────────────┐
│ ASSERT PASS ✓                │
│ enabled == true              │
└──────────────────────────────┘

Why this matters

QA verifies what the user sees, not how the DOM happens to be structured today.

Minimal example

runtime.assert_(is_enabled("role=button text~'Continue'"))
runtime.assert_(is_checked("role=checkbox name~'Subscribe'"))
runtime.assert_(value_contains("role=textbox name~'Email'", "@"))

If verification fails, Sentience reports:


Example 3 — Vision fallback as a last resort (auditable)

Diagram (controlled escalation)

┌────────────────────────┐
│ Snapshot attempts      │
│ confidence < threshold │
└──────────┬─────────────┘
           │ exhausted
           ▼
┌────────────────────────┐
│ Vision verifier        │
│ YES / NO question      │
└──────────┬─────────────┘
           │
           ▼
┌────────────────────────┐
│ ASSERT PASS / FAIL     │
│ (logged + auditable)   │
└────────────────────────┘

Important guarantees

Minimal example

await runtime.check(
  exists("text~'Order Complete'"),
  label="order_complete"
).eventually(
  min_confidence=0.7,
  max_snapshot_attempts=2,
  vision_provider=vision_llm
)

Auditability first

Vision is used only when structure fails. No silent recovery. No hidden AI behavior.


Optional: Deep debugging with Sentience Studio

For teams that need deeper inspection, Sentience Studio provides an optional visual layer on top of the same runtime assertions.

Studio can be used to:

Studio is optional

All QA verification works in CI without Studio. Studio is a debugging aid, not a requirement.


Where Sentience fits in an enterprise QA stack

Sentience complements existing QA tools:

Unit tests → Playwright/Cypress → Sentience verification

Why enterprises adopt Sentience for QA

Sentience turns QA from brittle scripts into verifiable contracts.