How I Build Cypress Automation & AI Agent QA

The most common mistake in Cypress is targeting elements by class names or CSS selectors that change when a designer updates the UI. Instead, I attach a unique id attribute to every interactive element:

Then in tests:

When the styling changes, the test doesn't break. The ID stays the same.

Every test reads from a single source of truth — app-constants.json — which stores all element IDs, API endpoints, and test values:

If an ID changes, you update it in one place and all tests stay in sync.

One of the more interesting behaviors is how the Tester Agent communicates back to other agents when it finds problems.

All inter-agent communication goes through a single file: .claude/agents/signals/pending-signals.md. It's a structured inbox — every agent checks it at kickoff and resolves pending signals before starting new work.

When the Tester Agent audits a component and finds a missing data-testid:

When the Tester Agent finds an endpoint missing an edge case:

The signal sits in pending-signals.md as [PENDING]. The Frontend or Backend Agent picks it up at their next kickoff, makes the fix, and marks it [RESOLVED: YYYY-MM-DD].

This creates a tight feedback loop that would normally require a Jira ticket, a Slack message, and two meetings.

I always run tests in headed mode — meaning you can watch the browser do exactly what the test does:

npx cypress run --headed --browser chrome --spec "cypress/e2e/inventory/**"

No black-box magic. You see every click, every form fill, every assertion. This makes debugging fast and gives clients confidence that the tests are real.

What Cypress catches

A regular QA engineer reads code, thinks about what could go wrong, and writes tests. An AI Agent does the same thing — but it has read every file in your codebase, understands your product requirements, and never gets tired.

In my workflow, I use a Tester Agent built on top of Claude (Anthropic's AI model). It's not just a chatbot — it's a specialized agent with a defined role, specific tools, and strict rules about what it can and cannot do.

Before the agent writes a single line of test code, it reads:

• The PRD (Product Requirements Document) — what the feature is supposed to do
• The GitHub issue — the exact acceptance criteria
• The backend API routes — what endpoints exist and what they return
• The frontend components — what UI elements are on the page
• The existing Cypress fixtures — what IDs and endpoints are already registered

This is what separates an AI agent from a simple autocomplete tool. It has context.

The agent is required to write its test plan in the GitHub issue first — before creating any files:

Tester

• Test item creation — happy path
• Test item creation — missing required fields
• Test item creation — duplicate item name
• Test item list loads correctly
• Test delete item — confirm dialog appears
• Test delete item — item disappears from list after confirm

This plan is visible to the developer and the client. It's a contract — the agent commits to exactly what it will test.

Once the plan is approved, the agent generates the spec file — following the same structure, naming conventions, and selector patterns described in Part 1.

It knows the rules:

• Use id selectors, not class names
• One spec file per page
• Happy path + error handling + edge cases
• Register new IDs in app-constants.json

The agent runs the tests itself using the Bash tool:

npx cypress run --headed --browser chrome --spec "cypress/e2e/inventory/inventory-items.cy.js"

If a test fails, it reads the error, diagnoses whether it's a test bug or an app bug, fixes it, and reruns. It loops until everything is green

After all tests pass, the agent updates three QA tracking files:

• Feature coverage report — which features have tests
• Pass/fail history — when tests last ran and their results
• Spec file registry — which file covers which feature

Alongside the Tester, I use a Code Reviewer Agent and a Security Reviewer Agent — both read-only agents that inspect the code before tests are written.

Code Reviewer looks for:

• Logic bugs (wrong condition, off-by-one errors)
• Missing validation (what if the input is empty? what if the API call fails?)
• Code that's harder to maintain than it needs to be

Security Reviewer looks for:

• Unauthorized access (can User A see User B's data?)
• Exposed secrets (API keys in client-side code)
• SQL injection, XSS, and other OWASP vulnerabilities

Both agents produce a structured report with severity levels:

• CRITICAL — must fix before merge
• WARNING — should fix, has risk
• SUGGESTION — optional improvement

Only after all CRITICALs are resolved does the Tester Agent begin.

Here's how all the pieces connect in a real feature delivery:

1. PM writes requirements → GitHub issue created
2. Developer writes the code (Backend + Frontend)
3. Code Reviewer reviews the PR → flags issues
4. Security Reviewer checks for vulnerabilities
5. Developer fixes all CRITICAL issues
6. Tester Agent reads the issue + code
7. Tester Agent writes plan → writes tests → runs until 100% pass
8. Feature ships to production

Every step is tracked in the same GitHub issue. Every agent leaves a trace — what it planned, what it found, what it fixed.