Modern QA2026Buzzword Decoder: What People Actually Mean
Log inJoin

Course01 Agent Skills for Browser Automation⊞ Tile viewNew!

Cutting-edge · Chapter 01

Buzzword Decoder: What People Actually Mean

Updated Aug 2026

"Agentic Testing"

What they say: "We need agentic testing capabilities."

What they mean: Tests that can make decisions, not just follow scripts. The test system should be able to:

  • Explore the application (not just verify known flows)
  • Recover from unexpected states
  • Generate new test cases based on what it observes
  • Report findings in natural language

As of 2026 this is mainstream vocabulary, not hype — Playwright ships first-party test agents, and every major commercial platform markets "agentic execution."

What you should say: "Agentic testing means the test system has a reasoning loop — it observes the application state, decides what to do next, acts, and evaluates the result. In our framework, the coding agent is that loop. It reads test plans, drives the browser through the Playwright CLI skill, and reasons about whether results match expectations. Playwright's planner/generator/healer agents are the productized version of the same idea."

"Self-Healing Tests"

What they say: "Do your tests self-heal?"

What they mean: When the UI changes, do tests automatically adapt instead of breaking?

Levels of self-healing:

Level Mechanism Example
Basic Retry with fallback selectors ID → class → text → CSS path
Medium Visual matching Find element by appearance, not code
Advanced AI reasoning Agent understands page structure and finds alternative

What you should say: "Yes, in tiers. First, when an interaction fails, the agent takes a fresh snapshot and rediscovers the element by role and accessible name — cheap, handles most cases. Second, screenshot plus page-state reasoning for deeper understanding. Third, Playwright's healer agent replays and patches the failing step — and critically, it's allowed to conclude the app itself is broken rather than forcing the test green. A self-healing system without that terminal state is a bug-hiding machine. That's the question to ask any vendor selling 'self-healing AI.'"

"ReAct Pattern"

What they say: "Does your agent use the ReAct pattern?"

What they mean: The Reason + Act pattern where the agent:

  1. Observes the current state
  2. Thinks about what to do (visible reasoning)
  3. Acts on its decision
  4. Observes the result
  5. Repeats

In our framework:

Observe: playwright-cli snapshot → reads the YAML page summary
Think:   Agent reasons: "I see a login form. I need to enter credentials."
Act:     playwright-cli fill e8 "user@test.com"
Observe: playwright-cli snapshot → checks for validation errors
Think:   Agent reasons: "No errors. Submit the form."
Act:     playwright-cli press Enter

What you should say: "Coding agents naturally follow the ReAct pattern. Each CLI command is an action, and between commands the agent reasons about the output. The skill provides the vocabulary (the command surface), and the agent provides the intelligence (deciding which command to run next based on observations)."

"Shift-Left Testing"

What they say: "How does AI help us shift left?"

What they mean: Moving testing earlier in the development process — catching bugs before they reach QA.

What you should say: "AI agents can generate browser tests from requirements or PR descriptions, running them against feature branches before the code is even reviewed. A developer pushes code, the CI pipeline spins up the app, and the planner agent explores the new UI and drafts scenarios — all before a human QA engineer touches it. This catches layout bugs, broken flows, and regression issues at the PR stage instead of the QA stage."

"Test Observability"

What they say: "What's your observability strategy for tests?"

What they mean: Can you see what's happening inside your tests? Can you debug failures efficiently?

What you should say: "We capture the command log (what the agent did), snapshots and screenshots (what the page was), and the full Playwright trace — which since 1.60 includes network capture — as the single richest artifact: every action with before/after state. On failure, we add the agent's reasoning about why it thinks the test failed. This gives both human reviewers and AI agents everything they need to diagnose issues, and it doubles as the compliance answer to 'show me what the AI did.'"

"Test Maintenance Debt"

What they say: "How do you manage test maintenance debt?"

What they mean: Over time, test suites accumulate broken, slow, and flaky tests that cost more to maintain than they provide in value.

What you should say: "Agent-driven tests dramatically reduce maintenance debt because the agent adapts to UI changes. When a button ID changes from btn-submit to submit-button, traditional tests break — someone has to find the test, update the selector, verify it works, and merge the fix. Our agent re-snapshots and finds the button by role and name. We still review healing events and periodically update plans, but it's a review task, not an emergency fix."

"Page Object Model"

What they say: "Do you use the Page Object pattern?"

What they mean: A design pattern where each page/component has a corresponding class that encapsulates element selectors and interactions.

In agent-driven testing: The Page Object Model is less relevant because the agent doesn't need a class abstraction — it interacts with the page through fresh snapshots. However, the concept maps to:

What you should say: "We use a lighter version of the concept. Instead of page object classes, we have test plans with per-page hints, plus the seed-test pattern from Playwright's agents — seed.spec.ts encapsulates the shared context (auth, fixtures) every scenario inherits. It's more 'page guide' than 'page object': the agent uses hints when available and reasons from the snapshot when they're stale."

"Context Window" / "Token Budget"

What they say: "How do you manage the context window?"

What they mean: AI models have a limited context size. How do you ensure the agent has enough room for reasoning?

What you should say: "This is why we chose the CLI-skill path over MCP. MCP streams tool schemas and full accessibility trees into context on every action. The CLI writes page state to disk and returns a file path — the agent reads state on demand. Microsoft's benchmark puts it at ~27k tokens per task versus ~114k via MCP, about 4x, and up to 10x on long sessions. The nuance worth saying out loud: savings come from reading state on demand, not from never seeing state."

"Deterministic vs Non-Deterministic Testing"

What they say: "How do you handle the non-deterministic nature of AI?"

What they mean: Traditional tests produce the same result every time (deterministic). AI agents might take different paths (non-deterministic).

What you should say: "We achieve 'practical determinism' — the agent follows the same path the vast majority of the time because the SKILL.md instructions and test plans constrain its decisions. The divergence happens during error recovery, where non-determinism is actually a feature — the agent tries approaches a deterministic script can't.

We mitigate the risk through:

  1. Command logging — see exactly what the agent did
  2. Playwright traces — replayable evidence of each state, network included
  3. CI gates — pass/fail is deterministic even if the path varies
  4. Repeat-run measurement — for agentic flows we run the same scenario k times and track pass^k-style stability, not just single-run pass"

"AI-Native" / "Agent-Native"

What they say: "Is your tool AI-native?"

What they mean: Was it designed from the ground up for AI agents, or is it a traditional tool with AI bolted on?

What you should say: "The indicators of agent-native design: zero-configuration setup, CLI-first interface (agents use the shell, not SDKs), state written to files an agent can read on demand, auto-wait for element readiness (agents shouldn't hand-roll retry logic), and a SKILL.md that teaches the interface in the agent's own language — markdown. Vibium pioneered that checklist as a from-scratch AI-native tool; the 2026 twist is that Playwright — a 'traditional' framework — shipped a genuinely agent-native CLI on top of its mature engine. So the question isn't native-vs-bolted-on anymore; it's whether the agent path is first-class. For Playwright it now is."

"Composability"

What they say: "How composable is your framework?"

What they mean: Can the pieces be used independently and combined in different ways?

What you should say: "Highly composable — it's CLI-first, so every command combines with any other shell tool:

# Extract data and parse with jq
playwright-cli eval 'JSON.stringify(window.appData)' | jq '.users[].email'

# Snapshot before/after and diff the page state
playwright-cli snapshot   # → .playwright-cli/snap-before.yml
# ... perform actions ...
playwright-cli snapshot   # → .playwright-cli/snap-after.yml
diff .playwright-cli/snap-before.yml .playwright-cli/snap-after.yml

# Named sessions compose multi-actor scenarios
playwright-cli -s=admin open https://app.example.com/admin
playwright-cli -s=customer open https://app.example.com/shop

This is a Unix-philosophy advantage — small tools that compose via pipes and files. MCP tools can't be piped."