SDET Portfolio — Soma Sai Dinesh Cheviti | Playwright + MCP + API Testing

Interactive Concept Explorer

How MCP Works

Model Context Protocol — the architecture behind AI-assisted testing

🧑‍💻

You

QA Lead

natural language

✦
Claude Desktop
LLM + MCP Client

tool calls

🎭

Playwright MCP

MCP Server

browser control

🌐

VWO Login

Live Page

✦
Claude Desktop
LLM + MCP Client

tool calls

📋

JIRA MCP

MCP Server

creates tickets

🐛

KAN-1

Bug Ticket

Key insight: MCP is a standardised protocol. The AI does not hardcode API calls — it discovers available tools at runtime and decides which to call based on your natural language instruction. This is what makes it an Agent, not just a chatbot.

3 Components MCP

Host — Claude Desktop, the application running the LLM

MCP Client — built into Claude Desktop, manages server connections

MCP Server — Playwright or JIRA, exposes tools the AI can call

Tools Available Live

browser_navigate — go to any URL

browser_snapshot — extract full DOM accessibility tree

browser_click, browser_fill — interact with elements

createJiraIssue — log bugs directly to JIRA board

LLM vs AI Agent

What changes when you connect an LLM to tools

LLM only text in → text out

Answers questions about Playwright

Generates test case templates

Explains STLC concepts

Cannot navigate a real browser

Cannot create a real JIRA ticket

Cannot read live DOM structure

AI Agent (LLM + MCP) acts in the world
Navigates to app.vwo.com/#/login
Extracts 43 real elements from live DOM
Creates KAN-1 bug ticket in JIRA
Generates locators from actual page structure
Runs STLC phases using real tool calls
Decides which tool to call based on intent

The formula: Agent = LLM + Tools + Decision loop.
MCP is the standard that makes connecting tools to LLMs reliable and scalable. Without MCP, each tool integration required custom code. With MCP, any compatible tool connects through the same protocol.

// Without MCP — you write this
const response = await fetch('https://api.atlassian.com/jira/issues', {
method: 'POST', headers: { Authorization: 'Bearer token' },
body: JSON.stringify({ fields: { summary: '...' } })
});

// With MCP — Claude decides and calls
// You just say: "Create a bug for the password validation issue"
// Claude calls: createJiraIssue({ cloudId, projectKey, summary, ... })

REST API vs MCP

Two ways to connect software — fundamentally different philosophies

REST API code-to-service

Your code calls a specific endpoint

You must know the exact URL and parameters

Response format is fixed — JSON or XML

You write the integration logic

Each service has different auth patterns

Error handling is your responsibility

MCP AI-to-tool
AI discovers available tools at runtime
AI decides which tool to call from intent
Standardised protocol across all tools
AI writes the integration logic dynamically
Single connection pattern for any MCP server
AI handles sequencing of multiple calls

Analogy: REST API is like calling a specific department by dialling their direct number — you need to know the number. MCP is like telling a smart assistant "arrange a meeting" — it figures out which departments to call, in what order, and handles the back-and-forth.

JIRA via REST

# Step 1 — get project ID
GET /rest/api/3/project

# Step 2 — get issue type ID
GET /rest/api/3/issuetype

# Step 3 — create issue
POST /rest/api/3/issue
{ fields: { project, issuetype... } }

JIRA via MCP

# You say:

"Create a High priority bug in VWO Login

 STLC project — password accepts abc"

# Claude calls in sequence:

getAccessibleAtlassianResources()

getVisibleJiraProjects(...)

getJiraProjectIssueTypesMetadata(...)

createJiraIssue(...)

Manual vs MCP — Side by Side

Same STLC. Same project. Measured difference.

Manual (Block A)

MCP-Assisted

Req. Analysis

30 min · 8 elements

2 min · 43 elements

Test Planning

20 min

5 min

Test Case Design

30 min · 5 TCs

10 min · 8 TCs

Bug Reporting

10 min · manual JIRA

1 min · JIRA MCP

Total

~90 min

~20 min · 4.5× faster

The important caveat: MCP found 43 elements vs 8 in the PRD — including 4 hidden forms the documentation never mentioned. But you cannot validate these findings without understanding what good test cases look like. Manual first. MCP second. Always.

STLC — 6 Phases Applied to VWO Login

Each phase produces a real artifact. Each artifact is traceable.

PHASE 01

Requirement Analysis

→ 43 elements via MCP snapshot

PHASE 02

Test Planning

→ Scope, risks, entry/exit criteria

PHASE 03

Test Case Design

→ 8 TCs with exact locators

PHASE 04

Test Execution

→ POM + 13 Playwright tests

PHASE 05

Defect Reporting

→ KAN-1 via JIRA MCP

PHASE 06

Test Closure

→ Report + comparison

What makes this different: Block A ran all phases manually using the VWO PRD. The STLC MCP Project ran the same phases using live MCP tools. Both are documented side by side in the GitHub repo — making the comparison concrete and verifiable.

# The complete pipeline
PRD Read (Manual)
  → Live DOM Snapshot (Playwright MCP)
    → Test Plan → 8 Test Cases → POM Spec
      → Bug KAN-1 (JIRA MCP)
        → Closure Report → GitHub ✓

The Portfolio Repository

github.com/somasaic/sdet-stlc-portfolio

Block_A_Manual/ Traditional

01_Requirement_Analysis.md

02_Test_Plan.md

03_Test_Cases.md

04_Bug_Report.md

05_Severity_Priority.md

06_Regression_Retesting.md

docs/Block_B_Automation.md

STLC_MCP_Project/ AI-Assisted
01_Requirement_Analysis/vwo_live_elements.md
02_Test_Plan/test_plan.md
03_Test_Cases/test_cases.md
04_Test_Execution/pages/LoginPage.ts
04_Test_Execution/tests/vwo_login.spec.ts
05_Defect_Reports/BUG_Login_PWD001.md
06_Test_Closure/closure_report.md

⬡

somasaic/sdet-stlc-portfolio

STLC applied to real projects — Manual QA + Playwright MCP + JIRA MCP

Playwright

TypeScript

MCP

JIRA

CI/CD

11

commits

13

playwright tests

5

browsers

⬡ GitHub Repo ↗ in LinkedIn ↗ 🐛 KAN-1 JIRA ↗

5 Approaches — Side by Side

Same VWO login. Same 6 STLC phases. Completely different execution. Each approach adds a skill the previous couldn't demonstrate.

APPROACH 1

Block_A_Manual

PRD read — 8 elements found

Test cases hand-written

Bug report in Word doc

~90 min total

No CI/CD pipeline

Skill: QA process thinking

APPROACH 2

STLC_MCP_Project

Live DOM — 43 elements

AI writes test cases

KAN-1 via JIRA MCP

~20 min · 4.5× faster

5-browser CI pipeline

Skill: AI agent orchestration

APPROACH 3

Standard CLI

POM — getByRole locators

18/18 — 3 browsers

codegen for selectors

GitHub Actions CI green

HTML report artifact

Skill: pure engineering

APPROACH 4

Playwright CLI

UI + API in one project

request fixture — no browser

testData.ts — typed inputs

20/20 · 14× API speed

KAN-2 via JIRA MCP

Skill: framework depth + API

LATEST

APPROACH 5

AI Agents

Planner → Generator → Healer

AI plans + writes tests

Self-healing on failure

3/3 visual regression

seed.spec.ts bootstrap

Skill: autonomous AI testing

Dimension	Manual	MCP	Standard CLI	Playwright CLI	AI Agents
Tool	None	Claude + MCP servers	npx playwright	npx playwright + request	planner + generator + healer
Test types	None	UI	UI	UI + API	UI + Visual Regression
Speed	~90 min	~20 min	~90s CI run	3.9s API · 54s UI	48s visual · auto-generated
Bugs logged	Word doc	KAN-1 via JIRA MCP	KAN-1 reference	KAN-2 via JIRA MCP	KAN-3 healer-caught
Who writes tests	You (manually)	You (with AI assist)	You (pure code)	You (framework)	AI agents (autonomous)
New skill added	Process	AI orchestration	POM + CI/CD	API testing + edge cases	Autonomous gen + visual reg

The key insight: The STLC phases never change — Requirement Analysis, Test Planning, Test Design, Execution, Bug Reporting, Closure. What changes is the execution mode. Manual tests your judgment. MCP tests your process. Standard CLI tests your engineering. Playwright CLI tests your framework depth. AI Agents tests whether you can let the AI work and know when to intervene. An SDET needs to operate fluently in all five.

API Testing — From Zero to SDET Level

What it is, why it matters, and how Playwright handles it natively

UI Test browser required

Playwright opens a real browser (Chromium)

Loads app.vwo.com in that browser

Finds DOM elements, clicks, fills

Asserts on what the user sees

5 to 30 seconds per test

Fragile to CSS/DOM changes

API Test no browser at all
request fixture — direct HTTP to server
No browser launched, no page loaded
Sends HTTP request, reads JSON response
Asserts on status code + body + schema
200 to 500ms per test — 14× faster
Stable — tests API contract not visuals

THREE ASSERTION LEVELS — every API test needs all three

LEVEL 1 — Status Code (always)

expect(response.status()).toBe(200);

LEVEL 2 — Body Fields (always)

const body = await response.json();
expect(body.token).toBeDefined();

LEVEL 3 — Schema / Types (2yr level)

expect(typeof body.data.id).toBe('number');
expect(Array.isArray(body.data)).toBe(true);

CRITICAL — 204 DELETE RULE

204 No Content = no body. Never call response.json() on DELETE. It throws because the body is empty.

expect(response.status()).toBe(204);
// do NOT call response.json() here

STATUS CODE RANGES

                2xx — success (200 OK, 201 Created, 204 No Content)

                4xx — client error YOUR fault (400, 401, 403, 404)

                5xx — server error THEIR fault (500, 502, 503)

                404 as PASS — negative tests assert 404 intentionally

Why API testing is the market gap: 80% of SDET job descriptions ask for API testing. Most candidates with 1-2 years experience only have UI automation. The request fixture in Week 2 closes this gap entirely — same Playwright framework, same TypeScript, same CI pipeline. One project that proves both.

page fixture vs request fixture

The most important Playwright distinction for SDET interviews

🧪
test()
Playwright runner

injects

📄

{ page }

browser opens

→ DOM

🌐

VWO Login

~5-30s per test

— OR —

🧪
test()
Playwright runner

injects

📡

{ request }

NO browser at all

HTTP direct

⚡

reqres.in API

~200-500ms per test

{ page } fixture UI layer

Opens real Chromium/Firefox/WebKit browser

Navigates to URL, waits for DOM ready

Interacts: fill(), click(), hover()

Asserts: toBeVisible(), toHaveText()

Slower — 5-30s · sensitive to UI changes

test('login smoke', async ({ page }) => {
await page.goto('/#/login');
await expect(emailInput).toBeVisible();
});

{ request } fixture API layer
No browser. Zero. Nothing launched.
Sends HTTP directly: GET POST PUT DELETE
request.get() · request.post({ data })
Asserts: status() · json() · body fields
14× faster · stable · environment-agnostic

test('login API', async ({ request }) => {

  const res = await request.post('/api/login',

    { data: apiData.validLogin });

  expect(res.status()).toBe(200);

});
          

testData.ts — why no hardcoded strings in tests

// Week 1 — hardcoded, fragile
await loginPage.login('test@wingify.com', 'wrongpass');

// Week 2 — testData.ts, typed, DRY
import { apiData, uiData } from '../../data/testData';
await request.post(endpoints.login, { data: apiData.validLogin });
// One file change updates every test that uses this credential

Interview answer: "page fixture opens a real browser and tests the DOM layer — what users see and interact with. request fixture makes direct HTTP calls with no browser — it tests the API contract: status codes, response schemas, and error handling. API tests run 14× faster. I use both in the same project because they test different layers of the same feature."

Three CLI Tools — npx playwright vs MCP vs @playwright/cli

Playwright has three distinct execution modes — each serves a different purpose

TOOL 1 · STANDARD

npx playwright

Ships with @playwright/test

Test runner — runs spec files

codegen — record interactions

show-report, show-trace

--grep --project --debug --ui

CI/CD focused, one-shot per run

Used in: Week 1b + Week 2

TOOL 2 · AI AGENT

Playwright MCP

@playwright/mcp — JSON-RPC over stdio

AI calls browser_snapshot, browser_click

Snapshots injected INTO context window

~115K tokens per 30 actions

Per-call browser lifetime

Best for: live interactive exploration

Used in: Week 1a (STLC_MCP_Project)

TOOL 3 · AI EFFICIENT · NEXT

@playwright/cli

Microsoft's new AI agent CLI

playwright-cli open · snapshot · click

Snapshots saved to DISK as YAML/PNG

~25K tokens · 4.6× MCP savings

Persistent daemon via Unix socket

Best for: complex multi-step AI automation

Planned: Week 3/4 AI_Agentic project

TOKEN USAGE COMPARISON — per 30 actions

Playwright MCP

~115,000 tokens (context window)

@playwright/cli

~25,000 tokens (disk snapshots) · 4.6× saving

npx playwright

0 tokens — traditional test runner, no LLM

Why MCP burns tokens

Every browser_snapshot call injects the full page accessibility tree directly into the LLM context window. After 15+ steps, the context carries 90K+ tokens of stale snapshots from pages the agent already left. The model loses track of what is current.

Why @playwright/cli solves it
Snapshots write to disk as YAML/PNG files. The context window never sees them unless the agent explicitly reads a specific file. The model only loads what it needs right now. Persistent Unix socket sessions mean the browser stays alive between commands — no re-launch overhead.

The progression logic: Standard CLI (Week 1b) → MCP (Week 1a) → @playwright/cli (Week 3/4). Each mode has a clear use case. Real SDET teams use all three depending on context: standard CLI for CI/CD, MCP for interactive exploration, @playwright/cli for AI agent automation at scale.

# @playwright/cli — AI agent commands
playwright-cli open https://app.vwo.com/#/login
playwright-cli snapshot             # writes YAML to disk, NOT context window
playwright-cli click e15            # element ref from snapshot
playwright-cli fill e22 "test@wingify.com"
playwright-cli screenshot         # saves PNG to disk

# Token cost: ~25K vs ~115K for MCP — same task, 4.6× cheaper

LLM — What It Can and Cannot Do

Understanding the boundaries is what separates an SDET from someone who just prompts

What LLMs do well text in → text out
Understand natural language instructions precisely
Generate code, test cases, docs from a description
Reason about text — compare, summarise, classify
Pattern-match from billions of training examples
Produce structured output (JSON, Markdown, TypeScript)
Chain reasoning steps — think before answering

Hard limitations without tools

No memory — every conversation starts blank. No state between sessions.

No tools — cannot open a browser, read a file, call an API by itself

No real-time data — knowledge has a cutoff date, cannot fetch live DOM

No execution — can write code but cannot run it and see the output

No persistence — cannot save files, write to disk, modify state

Context limit — finite window. Too much input = early content dropped

THE MEMORY PROBLEM — WHY IT MATTERS IN TESTING

No short-term memory

Within one session the LLM sees everything in the context window. But it cannot "remember" what it clicked 10 steps ago unless that snapshot is still in context.

No long-term memory

Close the session, start again — zero memory. The LLM has no idea it already explored VWO login yesterday. Every run starts from scratch.

Solution: external memory

Agents compensate by writing to disk — specs/, snapshots, test files. The filesystem becomes the LLM's long-term memory. This is exactly what the planner does.

Why this matters for SDET work: An LLM alone is a text transformer. It can describe a test — it cannot run one, verify a selector exists, or confirm a button is actually clickable. The moment you add tools (MCP, browser control, file I/O), you convert the LLM from a text generator into an agent that acts on the real world. That gap between "generating test ideas" and "generating verified, runnable tests" is exactly what Playwright AI Agents bridge.

AI Agent Architecture — Think, Act, Observe

What makes something an agent rather than just an LLM call

🧠

LLM (Brain)

Receives the prompt + tool results. Reasons about what to do next. Decides which tool to call and with what arguments. Produces the plan or code output.

Claude Sonnet / GPT-4

🔧

Tools (Hands)

Browser control, file read/write, API calls, terminal commands. Tools are the only way the LLM can affect the outside world. Without tools it can only produce text.

MCP servers, browser_*, file I/O

💾

Memory (State)

Context window (short-term) + file system (long-term). The agent writes its discoveries to disk so later steps can read them. Specs, screenshots, test files are all memory.

specs/, tests/, snapshots/

THE AGENT LOOP — THINK → ACT → OBSERVE → REPEAT

STEP 1

Think

LLM reads prompt + context, decides next action

→

STEP 2

Call Tool

browser_snapshot(), browser_click(), write_file()

→

STEP 3

Observe

Tool result injected into context. LLM reads it.

→

STEP 4

Decide

Done? → Output. Not done? → back to Step 1.

Not an agent — single call

// Ask Claude to write a test — one shot
"Write a Playwright test for VWO login"
// → Claude produces text. Done.
// No browser opened, no selector verified,
// no guarantee it actually works.

Agent — tool loop

// Planner agent loop

planner_setup_page() → runs seed.spec.ts

browser_snapshot() → reads live DOM

browser_click("Forgot Password")

browser_snapshot() → reads new state

write_file("specs/plan.md", plan)

// Verified against real page. Saved to disk.

The formula: Agent = LLM + Tools + Memory + Loop. Remove any one of the four and you no longer have an agent — you have a text generator. The Playwright AI Agents (planner, generator, healer) implement all four: Claude is the LLM, MCP tools are the hands, specs/ and tests/ are the memory, and the planner → generator → healer sequence is the loop.

Playwright AI Agents — Planner, Generator, Healer

Microsoft's built-in agent system for autonomous test creation and self-healing

AGENT 1 — PLANNER

Explores → Plans

Calls planner_setup_page → runs seed.spec.ts

browser_snapshot → reads live DOM structure

Navigates all flows — login, errors, edge states

Writes human-readable Markdown test plan

            Input: seed.spec.ts + your prompt

            Output: specs/vwo_login_plan.md

AGENT 2 — GENERATOR

Plan → Code

Reads specs/vwo_login_plan.md

Calls generator_setup_page → opens browser

Verifies every selector live before writing

Writes TypeScript spec files with assertions

            Input: specs/vwo_login_plan.md

            Output: tests/login/*.spec.ts

AGENT 3 — HEALER

Fails → Fixes

Receives failing test name + error output

Replays failing steps in live browser

Inspects current DOM — finds correct selector

Patches the spec file and re-runs until green

            Input: failing test + error message

            Output: patched passing spec file

THE SEED FILE — MOST MISUNDERSTOOD CONCEPT

seed.spec.ts is NOT a test — it is a browser bootstrap. Before the planner or generator starts exploring, it calls planner_setup_page which runs seed.spec.ts first. This opens a browser, navigates to the target URL, and then calls page.pause() — handing the live browser session to the agent.

Without page.pause(), the browser closes as soon as the test ends. The agent has nothing to explore. The pause keeps the session alive and transfers control.

// seed.spec.ts — the handshake

test('seed', async ({ page }) => {

  await page.goto('/#/login');

  await page.waitForLoadState('networkidle');

  // confirm page is ready

  await expect(emailInput).toBeVisible();

  await page.pause();

  // ↑ agent takes control here

  // browser stays open

  // agent starts exploring

});

Why init-agents? Running npx playwright init-agents --loop=claude writes three Markdown files into .claude/agents/. These are agent definition files — they contain the system prompts and tool lists that tell Claude Code how to behave as a planner, generator, or healer. Claude Code reads them automatically when you open the project. You never edit them — regenerate when Playwright is updated.

Playwright Agents vs Playwright MCP — Why They Are Different

Both use MCP under the hood — but they solve completely different problems

Playwright MCP Week 1a — exploration

Purpose: Let an AI agent explore a live app interactively

YOU give a natural language instruction per step

Claude Desktop calls browser_snapshot, browser_click

Snapshot injected into context window each call

Output: you read the response and decide next step

~115K tokens per 30 actions — context fills fast

No structured output — conversational, ad hoc

Used for: Phase 1 requirement extraction, JIRA tickets

Playwright AI Agents Week 3/4 — autonomous
Purpose: Autonomously plan, generate, and heal tests
YOU give ONE high-level prompt — agent decides all steps
Agent orchestrates planner_setup_page + browser tools
Agent loop: Think → Tool call → Observe → Repeat
Output: structured files — specs/*.md + tests/*.spec.ts
Agent definitions in .claude/agents/ guide behaviour
Deterministic — same input → same structured output
Used for: all 6 STLC phases, fully automated

THEY BOTH USE MCP — SO WHAT'S DIFFERENT?

Playwright MCP is a server — it exposes browser control tools (browser_snapshot, browser_click, browser_fill) via the MCP protocol. Any MCP client can use it.

Playwright AI Agents are clients with structured roles. The planner agent calls planner_setup_page which internally uses the same MCP browser tools — but wraps them in a deliberate loop with a defined output format (Markdown plan). The generator similarly uses generator_setup_page to produce TypeScript files.

Analogy: MCP is electricity. The agents are appliances. The planner is a camera that uses electricity to take a structured photo. The generator is a printer that uses electricity to produce a document. Both use the same power source — but they do completely different jobs.

MCP alone

Interactive, conversational. You drive every step. Flexible but manual. Good for exploration and one-off tasks.

Agents using MCP

Autonomous, structured. Agent drives all steps. Consistent output format. Good for repeatable workflows like STLC.

Both together

Use MCP for interactive exploration (Week 1a), then agents for systematic generation (Week 3/4). Different phases of the same STLC.

The interview answer: "Playwright MCP is a browser control server — it exposes tools any AI can call. Playwright AI Agents are structured workflows built on top of MCP. The planner agent uses MCP browser tools internally but wraps them in a deliberate loop that produces a Markdown test plan. The generator converts that plan into verified TypeScript tests by checking every selector live. The healer uses the same tools to replay failures and patch broken locators. They are not alternatives — they are layers. MCP is the infrastructure. Agents are the application built on it."

Visual Regression Testing — toHaveScreenshot()

The Week 3/4 key addon — pixel-level UI verification that no previous approach covers

Functional test what it can't catch

Login button text changed from "Sign in" to "Log in"

Error message colour changed from red to orange

Input field border disappeared in a CSS deploy

Password field moved 20px to the right on mobile

VWO logo replaced with placeholder image

All functional tests still PASS despite these issues

Visual regression what it catches
Pixel-level diff — any visual change triggers failure
Baseline PNG stored in repo — version controlled
Diff image shows exactly what changed in red
Runs in CI on every push — catches regressions before merge
Clips to stable elements — excludes dynamic backgrounds
OS + browser tagged — chromium-win32.png, chromium-linux.png

TWO PHASES — HOW toHaveScreenshot() WORKS

PHASE 1 — BASELINE CREATION (first run)

No PNG exists yet. Playwright takes a screenshot and saves it to tests/visual/login_visual.spec.ts-snapshots/. Test "fails" with message "snapshot doesn't exist, writing actual". This is correct — run --update-snapshots to promote to baseline.

PHASE 2 — COMPARISON (every run after)

Baseline exists. Playwright takes a new screenshot and compares pixel by pixel against the stored PNG. If difference exceeds maxDiffPixels: 200, test FAILS with a diff image showing changed pixels highlighted in red/pink.

THE VWO ANIMATED BACKGROUND PROBLEM — AND HOW WE SOLVED IT

THE PROBLEM

VWO login has a CSS animated background that changes every render. Full-page screenshots showed 65,000–69,000 pixel diffs between runs taken seconds apart — not because the UI changed, but because the background animation was at a different frame.

THE FIX — clip to form bounding box

const form = page.locator('form').first();
const box = await form.boundingBox();
await expect(page).toHaveScreenshot({
clip: box ?? undefined,
maxDiffPixels: 200,
});

Result: only the login form is captured. The animated background is outside the clip rectangle — it never appears. 3/3 tests now pass stably across runs. This is documented engineering decision-making — not just "it works now."

TC-VR-01

Default login state

vwo-login-default-chromium-win32.png

TC-VR-02

Error state after bad login

vwo-login-error-state-chromium-win32.png

TC-VR-03

Email field filled state

vwo-login-email-filled-chromium-win32.png

Why visual regression is the right Week 3/4 addon: Week 2 closed the API testing gap. Week 3/4 closes the visual regression gap. Together: functional UI tests (Weeks 1-3), API contract tests (Week 2), visual regression (Week 3/4). That is a complete test pyramid. No previous approach in this portfolio covers what a pixel-level regression looks like — and 80% of SDET job descriptions for product companies mention it.

Portfolio Progression — 5 Approaches

WEEK 0 · APPROACH 1

Block_A_Manual

Manual STLC — all 6 phases on VWO Login PRD. No automation. Pure QA process thinking.

Manual STLC PRD

Done

WEEK 1A · APPROACH 2

STLC_MCP_Project

Playwright MCP + JIRA MCP. 43 DOM elements. 13 tests, 5 browsers. KAN-1 via MCP. 4.5× speed.

MCP JIRA AI Agent

Done

WEEK 1B · APPROACH 3

STLC_Standard_CLI

Standard Playwright CLI. POM + TypeScript. 18/18 tests, 3 browsers, GitHub Actions CI. KAN-1.

POM TypeScript CI/CD

Done

WEEK 2 · APPROACH 4

Playwright_CLI

UI + API testing. request fixture. testData.ts. Dual config. 20/20 tests. KAN-2 via JIRA MCP.

API Testing CRUD KAN-2

Done

LATEST

WEEK 3/4 · APPROACH 5

Playwright_AI_Agents

Planner + Generator + Healer agents. Visual regression. seed.spec.ts. 3/3 VR tests passing.

AI Agents Visual Reg Self-Heal

In Progress

Week 1B — STLC Standard CLI

APPROACH 3 · VWO LOGIN · PLAYWRIGHT + TYPESCRIPT

STLC_Standard_CLI/

POM · 3 Browsers · GitHub Actions · 18/18 passing

18/18

tests passed

3

browsers

KAN-1

bug logged

6

STLC phases

PHASE 01

Requirement Analysis

12 REQs from VWO login. RTM. EP + BVA test design coverage mapped.

PHASE 02

Test Planning

Scope, 5 risks, entry/exit criteria. retries:1 for CI flakiness mitigation.

PHASE 03

Test Case Design

6 TC IDs — TC-01 to TC-06. EP partitions + BVA boundaries. Full format.

PHASE 04

Test Automation

POM + getByRole locators. fixture injection. beforeEach. 3 browser projects.

PHASE 05

Bug Reporting

KAN-1: password field no visibility toggle. Severity Medium, Priority Low.

PHASE 06

Test Closure

18/18 passing. Chromium + Firefox + WebKit. CI green. RTM 100% traced.

What this proves: You can build a production-grade Playwright framework from a blank folder — no generator, no plugin, no AI assistance. Every file written with full understanding of why each line exists. The RTM chain is complete: requirement → test case → automated test → HTML report row → CI green.

⬡ STLC_Standard_CLI/ ↗ 🐛 KAN-1 ↗

Week 2 — Playwright CLI (UI + API)

APPROACH 4 · VWO LOGIN UI + REQRES API · PLAYWRIGHT + TYPESCRIPT

Playwright_CLI/

request fixture · testData.ts · dual config · 20/20 passing · JIRA KAN-2

20/20

tests passed

3.9s

API suite (10 tests)

14×

API vs UI speed

KAN-2

bug via JIRA MCP

UI SUITE — tests/ui/vwo_login.spec.ts

✓ TC-UI-01 — smoke: all elements visible

✓ TC-UI-02 to 04 — EP: valid/invalid credentials

✓ TC-UI-05 to 06 — BVA: empty/partial inputs

✓ TC-UI-07 — SQL injection input (edge)

✓ TC-UI-08 — 500-char boundary string

✓ TC-UI-09 — special chars in password

✓ TC-UI-10 — whitespace-only inputs

10 tests · 53.9s · page fixture · browser

API SUITE — tests/api/ (reqres.in)

✓ TC-API-01 — POST /login valid → 200 + token

✓ TC-API-02 — POST /login missing password → 400

✓ TC-API-03 — POST /login wrong creds → 400

✓ TC-API-04 — POST /register valid → 200 + id

✓ TC-API-05 — POST /register missing pw → 400

✓ TC-API-06/07 — GET users list + single

✓ TC-API-08/09/10 — 404 · PUT · DELETE 204

10 tests · 3.9s · request fixture · no browser

NEW CONCEPTS IN WEEK 2 (vs Week 1)

request fixture GET POST PUT DELETE testData.ts interfaces extraHTTPHeaders dual project config dotenv + GitHub Secrets 3-level assertions 204 no-content rule schema validation KAN-2 via JIRA MCP

KAN-2 — logged via JIRA MCP: POST /api/register returns 200 instead of 201. Per RFC 7231, resource creation should return 201 Created. The bug test intentionally FAILS — that is the correct result. It proves the bug exists. The companion test PASSES and documents actual behaviour. Same JIRA MCP approach used for KAN-1 in Week 1.

// page fixture — browser opens, tests DOM
test('TC-UI-01', async ({ page }) => {
  await loginPage.navigate();
  await expect(loginPage.emailInput).toBeVisible();
});

// request fixture — NO browser, direct HTTP
test('TC-API-01', async ({ request }) => {
  const response = await request.post('/api/login', {
    data: apiData.validLogin
  });
  expect(response.status()).toBe(200);          // Level 1
  expect(body.token).toBeDefined();              // Level 2
  expect(typeof body.token).toBe('string');      // Level 3 schema
});

⬡ Playwright_CLI/ ↗ 🐛 KAN-2 ↗ ⬡ Full Portfolio ↗

Week 3/4 — Playwright AI Agents + Visual Regression

APPROACH 5 · VWO LOGIN · PLANNER + GENERATOR + HEALER + VISUAL REGRESSION

Playwright_AI_Agents/

Built-in AI agents · toHaveScreenshot() · seed.spec.ts · self-healing loop

3/3

visual tests

3

AI agents

PNG

baselines committed

TBD

agent-gen tests

AGENT 1

Planner

Navigates live DOM via planner_setup_page. Runs seed.spec.ts first. Writes Markdown test plan to specs/.

Input: seed + prompt → Output: vwo_login_plan.md

AGENT 2

Generator

Reads plan, opens browser via generator_setup_page. Verifies selectors live. Writes TypeScript spec files.

Input: vwo_login_plan.md → Output: tests/login/*.spec.ts

AGENT 3

Healer

Replays failing steps. Inspects current DOM. Patches locator or assertion. Re-runs until passing. Self-healing automation.

Input: failing test → Output: patched passing test

seed.spec.ts is not a regular test. Before the planner or generator explores the browser, it runs seed.spec.ts via the planner_setup_page and generator_setup_page tools. The seed navigates to the target and calls page.pause() — keeping the browser alive and handing the session to the agent to explore. Without pause() the browser closes immediately.

VISUAL REGRESSION — toHaveScreenshot() — KEY ADDON

TC-VR-01

Default page state — form clipped baseline

vwo-login-default-chromium-win32.png

TC-VR-02

Error state after invalid login — form baseline

vwo-login-error-state-chromium-win32.png

TC-VR-03

Email field filled — form baseline

vwo-login-email-filled-chromium-win32.png

VWO has a dynamic animated background — clipping to form bounding box gives stable baselines. 3/3 passing. PNG files committed to repo. CI compares on every push.

# How visual regression works — two phases

# Phase 1 — create baselines (first run)
npx playwright test tests/visual/ --update-snapshots
# → saves vwo-login-default-chromium-win32.png to snapshots/

# Phase 2 — comparison (every run after)
npx playwright test tests/visual/
# → compares pixel-by-pixel against baseline
# → fails with diff image if VWO changes their UI

# seed.spec.ts — hands browser to agent
test('seed', async ({ page }) => {
  await page.goto('/#/login');
  await page.waitForLoadState('networkidle');
  await page.pause(); ← agent takes control here
});

⬡ Playwright_AI_Agents/ ↗ ↗ Playwright Agents Docs