Frontend and UI testing

How to generate UI test cases from design specs and wireframes with AI?

Design specs and wireframes are rich with test-case-worthy information that most QA teams under-exploit. A Figma file, a Zeplin export, or even a hand-off PDF contains component states, spacing rules, interaction patterns, and copy strings — all of which map directly to testable assertions. The challenge is the translation gap: designers write specs in design language, engineers build in component language, and QA needs to close both sides.

AI bridges this gap far faster than manual analysis, but it requires you to feed it the right artifacts.

What to extract from design specs before prompting

Before prompting, export or collect:

• Component inventory: A list of all components on the screen with their possible states (default, hover, focused, disabled, error, loading, empty)
• Interaction specs: Tap/click targets, form validation rules, transition triggers
• Content specs: Exact copy strings, character limits, placeholder text, error messages
• Layout constraints: Breakpoints, min/max widths, grid columns, spacing tokens
• Accessibility annotations: If the design file has accessibility notes (role annotations, tab order, contrast ratios), include them

If your team uses Figma, you can export a JSON representation of the component tree (via the Figma REST API) and paste it alongside the prompt. Alternatively, export a written summary of the component's specification.

Prompt: Generate test cases from a component spec

You are a senior QA engineer. I'm providing you with the specification for a 
checkout form component. Generate a comprehensive test case suite covering:

1. Functional correctness (all fields, validation, submission)
2. UI state coverage (default, focused, error, disabled, loading states)
3. Boundary and edge cases (character limits, special characters, empty inputs)
4. User interaction flows (tab order, keyboard navigation, paste behavior)

Use the following format for each test case:
- Test ID: TC-CHECKOUT-###
- Test Title: [Short descriptive name]
- Preconditions: [Setup needed]
- Steps: [Numbered action steps]
- Expected Result: [Specific, verifiable assertion]
- Priority: [High/Medium/Low]

Component spec:
---
Component: Checkout Payment Form
Fields: Card Number (16 digits, Luhn check), Expiry (MM/YY, future dates only), 
CVV (3-4 digits), Cardholder Name (2-26 chars, alpha + space + hyphen only)
Submission: Async — shows loading spinner, then success/error state
Errors: Inline per field on blur; global banner on submission failure
States: Default, field-focused, field-error, form-loading, form-success, form-error
Design tokens: min-width 320px, max-width 480px, stacks to single column below 375px
---

This prompt will typically generate 25–40 test cases covering scenarios most engineers miss in manual analysis — things like the Luhn check failure case, the expiry-in-the-past error, and the "exactly 26 character name" boundary condition.

Generating from wireframes as images

When you have wireframe images (not structured spec text), use a multimodal AI model (Claude, GPT-4o). Attach the image and use a prompt like:

I'm attaching a wireframe for [feature name]. Based on the UI you can see:

1. Identify all interactive elements (buttons, inputs, dropdowns, links)
2. For each element, list the possible states
3. Generate test cases for the primary user flow and 3 alternative flows
4. Flag any ambiguities in the wireframe that need clarification before testing

Format output as a markdown table: | ID | Scenario | Element | Action | Expected |

Turning component documentation into test suites

If your team has a design system with documented components (Storybook, component library docs), use the documentation as the spec source:

I'm providing the documentation for our Button component from our design system.
Generate a test suite covering all documented states and interactions.
Include: visual state tests (for visual regression baseline capture), 
functional tests (click handlers, disabled behavior), 
and accessibility tests (keyboard focus, ARIA attributes, screen reader announcement).

Button component docs:
---
[paste component documentation here]
---

Learning Tip: The quality of AI-generated test cases from design specs is directly proportional to the specificity of the spec you provide. Vague specs produce vague test cases. If your design handoffs are thin, spend 10 minutes writing out the component states and validation rules before prompting — that 10 minutes of spec work produces hours of test case value.

How does AI-assisted visual regression testing work and how do you interpret diffs?

Visual regression testing catches the class of bugs that functional tests entirely miss: unintended layout shifts, text truncation, color changes, z-index stacking issues, and component overlap. AI doesn't replace the tooling here — you still need a visual regression tool — but it fundamentally changes how you analyze, triage, and act on diffs.

The visual regression workflow

The standard visual regression pipeline has three stages:

1. Baseline capture: Run your test suite against a known-good build, capturing screenshots of every component/page state as baseline images
2. Comparison run: Run the same suite against the new build; the tool diffs new screenshots against baselines
3. Triage: Review flagged diffs and decide: intentional change (approve new baseline) or regression (file bug)

Stage 3 is where engineers spend most of their time — and where AI delivers the most leverage.

Tools and integration points

Applitools Eyes is the most AI-sophisticated option. Its Visual AI uses a neural model to distinguish cosmetically irrelevant differences (antialiasing, font rendering) from meaningful visual regressions. This dramatically reduces false positives compared to pixel-diff tools.

Percy (BrowserStack) uses perceptual diffs and provides a review UI. Less AI-driven than Applitools but integrates cleanly into most Playwright/Cypress pipelines.

Lost Pixel is the open-source option — pixel-level diff with no AI noise reduction, so expect higher false positive rates.

Integrating AI triage into your visual diff workflow

When your visual regression tool flags a diff, you typically see a side-by-side baseline/new screenshot with a highlighted diff mask. The challenge: if you have 200 flagged diffs after a CSS refactor, reviewing each one manually takes hours.

Use AI to accelerate triage by describing the diff in structured terms and asking for classification:

I'm triaging visual regression diffs after a CSS variable refactor. I'll describe 
each diff — classify each as one of:
- INTENTIONAL: Expected change from the refactor (approve baseline)  
- REGRESSION: Unintended visual change (file bug)
- FALSE_POSITIVE: Rendering artifact, not a real UI change
- NEEDS_REVIEW: Ambiguous, requires human review

For REGRESSION and NEEDS_REVIEW, provide a one-line description of what looks wrong.

Diff 1: Login page. Baseline shows primary button with blue background #3B82F6. 
New screenshot shows button with background #2563EB. The refactor renamed 
--color-primary from #3B82F6 to #2563EB intentionally.
→ Classify:

Diff 2: User profile page. Baseline shows avatar image centered in a 48px circle. 
New screenshot shows avatar shifted 4px to the right, partially outside the circle boundary.
→ Classify:

Diff 3: Navigation bar. Baseline shows 16px gap between nav items. New screenshot 
shows 8px gap. The refactor did not touch navigation spacing.
→ Classify:

This pattern — describing diffs in structured terms and asking for batch classification — can process 50 diffs in one prompt session, reducing 2 hours of manual triage to 20 minutes.

Writing AI-assisted visual test setup prompts

When setting up visual regression tests in Playwright + Percy or Applitools:

I'm setting up visual regression tests using Playwright + Percy for our React 
application. Generate a test file that:

1. Captures visual snapshots of the following components in all their documented states:
   - PrimaryButton: default, hover, focused, disabled, loading
   - InputField: empty, filled, error, disabled
   - Modal: default open state, with long content (scroll), with form content

2. Sets viewport to 1440px (desktop), 768px (tablet), 375px (mobile) for each snapshot
3. Waits for animations to complete before capturing (use page.waitForTimeout(300))
4. Uses meaningful snapshot names following the convention: 
   ComponentName_State_Viewport (e.g., PrimaryButton_Loading_Mobile)

Tech stack: Playwright, TypeScript, Percy (@percy/playwright)
Component location: src/components/

Interpreting AI-flagged regressions vs. intentional changes

One skill that separates strong QA engineers in visual regression work is understanding the diff metadata — not just "something changed" but what class of change it is. Build a classification taxonomy with your team:

Feed this taxonomy into your AI triage prompt to get more precise output.

Learning Tip: If you're new to visual regression testing, start with component-level snapshots (Storybook integration with Chromatic or Lost Pixel) rather than full-page E2E captures. Component snapshots are faster, more isolated, and produce fewer false positives from dynamic content. Once your component-level baseline is stable, expand to full-page captures for critical user flows.

How to run WCAG accessibility audits and get remediation suggestions with AI?

Accessibility testing sits at the intersection of regulatory compliance (ADA, EN 301 549, WCAG 2.1/2.2) and genuine user impact — and it's one of the areas where AI gives QA engineers the most leverage, because accessibility rules are well-documented, machine-interpretable, and their remediation is consistently patternable.

The three-layer accessibility testing approach

Effective accessibility testing uses three complementary layers:

1. Automated scanning (axe-core, Lighthouse, WAVE): Catches ~30–40% of WCAG issues automatically — missing alt text, color contrast failures, empty form labels
2. AI-assisted analysis (Claude, GPT-4): Analyzes component markup, ARIA usage, interaction patterns — catches issues automated scanners miss
3. Manual screen reader testing (VoiceOver, NVDA, TalkBack): Validates the actual experience — catches cognitive flow issues, announcement quality, screen reader-specific bugs

AI lives in layer 2 and significantly extends coverage beyond what automated scanners catch.

Prompt: WCAG audit of a component

You are an accessibility specialist. Audit the following React component for 
WCAG 2.1 Level AA compliance. For each issue found:
- WCAG criterion violated (e.g., 1.4.3 Contrast Minimum)
- Severity: Critical (blocks task completion) / Major (creates significant barrier) / Minor (degrades experience)
- Affected user group (screen reader users, keyboard-only users, low vision users, etc.)
- Specific remediation: exact code change needed

Also check for:
- Keyboard navigability (focus order, trap focus in modals, escape behavior)
- ARIA usage correctness (no ARIA misuse, roles match semantic intent)
- Focus indicator visibility
- Screen reader announcement quality (not just presence of attributes)

Component:
---
[paste component code here]
---

Using axe results as AI input

The axe-core library (used by Playwright, Cypress, and browser extensions) produces machine-readable JSON results. Feed these results to AI for deeper analysis:

The following axe-core accessibility scan results were captured from our 
checkout page. For each violation:
1. Explain the user impact in plain English (what goes wrong for affected users)
2. Rate severity: Critical / High / Medium / Low
3. Provide the exact HTML/JSX fix (not a description — actual corrected markup)
4. Identify if the fix requires design changes (color contrast), 
   code changes only, or content changes

Axe results:
---
{
  "violations": [
    {
      "id": "color-contrast",
      "impact": "serious",
      "description": "Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds",
      "nodes": [
        {
          "html": "<span class=\"helper-text\">8 characters minimum</span>",
          "failureSummary": "Fix any of the following: Element has insufficient color contrast of 2.87 (foreground color: #94a3b8, background color: #1e293b, font size: 12.0pt, font weight: normal). Expected contrast ratio of 4.5:1"
        }
      ]
    },
    {
      "id": "label",
      "impact": "critical",
      "description": "Ensures every form element has a label",
      "nodes": [
        {
          "html": "<input type=\"search\" placeholder=\"Search products...\">",
          "failureSummary": "Fix any of the following: Form element does not have an implicit (wrapped) <label>; Element has no title attribute; aria-label attribute does not exist"
        }
      ]
    }
  ]
}
---

Generating WCAG-compliant remediation code

When AI identifies a violation, push it to produce actual corrected code rather than generic guidance:

The following input component fails WCAG 2.1 criteria 1.3.1 (Info and Relationships) 
and 4.1.2 (Name, Role, Value). Provide the corrected JSX with:
- Proper label association
- Required ARIA attributes
- Error state announcement (aria-describedby)
- Required field indication accessible to screen readers (not color-only)

Current broken code:
<div className="form-field">
  <span className="label">Email *</span>
  <input type="text" className={error ? 'input error' : 'input'} />
  {error && <span className="error-msg" style={{color: 'red'}}>{error}</span>}
</div>

Accessibility test case generation

Beyond auditing existing components, use AI to generate accessibility-specific test cases before components are built:

Generate a Playwright accessibility test suite for a modal dialog component 
that must meet WCAG 2.1 AA. Include tests for:

1. Focus management: focus moves to modal on open, returns to trigger on close
2. Focus trap: Tab and Shift+Tab cycle within modal only while open
3. Escape key: closes modal and returns focus
4. Screen reader: modal has role="dialog", aria-modal="true", aria-labelledby
5. Background inertness: content behind modal is not reachable by keyboard
6. Color contrast: test that contrast ratio meets 4.5:1 for normal text

Use axe-playwright for automated checks where possible.
Tech stack: Playwright, TypeScript, @axe-core/playwright

Building an accessibility regression baseline

For accessibility, regression is just as important as initial compliance. Build a test that runs axe-core on every page/component and fails the build if new violations are introduced:

Generate a Playwright test that:
1. Visits these routes: /, /checkout, /profile, /search, /product/:id
2. Injects axe-core and runs a full audit at each route
3. Filters to only WCAG 2.1 AA violations
4. Writes results to accessibility-report.json
5. Fails the test if any new violations appear compared to the baseline 
   (read baseline from accessibility-baseline.json)
6. Posts a summary to console: "X new violations found, Y resolved"

This should run in CI on every PR.

Learning Tip: Automated accessibility tools reliably catch only 30–40% of real accessibility issues. The remaining 60% requires human judgment — especially screen reader flow, cognitive load, and contextual meaning. Use AI to maximize your automated coverage and generate targeted manual test cases for screen reader verification. Never claim WCAG compliance based on automated scan passing alone.

How to generate cross-browser and responsive layout test scenarios with AI?

Cross-browser and responsive testing have a reputation for being tedious and under-systematized — most teams end up with a loose spreadsheet of "tested on Chrome/Firefox/Safari" without a principled approach to what was actually tested. AI changes this by generating systematic, risk-stratified test matrices and the test code to execute them.

Building a cross-browser test matrix with AI

The key insight is that cross-browser testing isn't "test everything everywhere" — it's "test the right things in the right browsers based on risk." AI helps you generate a risk-stratified matrix:

I'm building a cross-browser test strategy for our web application. 
Our analytics show the following browser distribution:
- Chrome (desktop): 54%
- Safari (desktop + iOS): 22%
- Firefox: 11%
- Chrome (Android): 9%
- Samsung Internet: 2%
- Edge: 2%

Our application has these high-risk cross-browser areas:
- CSS Grid layout (complex nested grid)
- CSS Custom Properties (CSS variables)
- Intersection Observer API (lazy loading)
- Web Crypto API (client-side encryption)
- CSS :has() selector (conditional styling)
- FileSystem Access API (file upload/export)

Generate:
1. A prioritized browser matrix (which browsers × OS × viewport combos to test)
2. For each high-risk feature, identify which browsers have known compatibility issues
3. Generate specific test scenarios for each compatibility risk
4. Recommend which tests to run in full CI vs. nightly vs. manual-only

Generating responsive layout test scenarios

Responsive tests need to cover more than "does it look okay at 375px" — they need to systematically verify layout behavior at breakpoints, content overflow, touch target sizes, and navigation patterns:

Generate a comprehensive responsive layout test suite for our web application.
Breakpoints: 320px, 375px, 414px, 768px, 1024px, 1280px, 1440px

For each breakpoint, generate test scenarios covering:
1. Navigation: How does the nav render? (hamburger at mobile, full nav at desktop)
2. Grid reflow: Column counts, content stacking order
3. Typography: Font size, line height, truncation behavior
4. Images: Aspect ratio preservation, srcset loading
5. Touch targets: Minimum 44×44px for all interactive elements at mobile
6. Form layout: Single vs. multi-column, label positioning
7. Table/data display: Scroll behavior or card transformation at mobile
8. Fixed/sticky elements: Header height, bottom nav, floating buttons

Tech stack: Playwright with responsive viewport testing
Output format: Playwright test file with parameterized viewport tests

Playwright test generation for cross-browser scenarios

Generate a Playwright test suite that runs our critical user journey 
(search → product page → add to cart → checkout) across these browsers and viewports:

Browsers: chromium, firefox, webkit
Viewports: 
  - Mobile: 375×812 (iPhone-sized)
  - Tablet: 768×1024
  - Desktop: 1440×900

For each browser × viewport combination, test:
1. Page loads without console errors
2. All interactive elements are visible and clickable
3. Forms submit correctly
4. Layout does not overflow (no horizontal scroll on mobile)
5. Critical text is not truncated unexpectedly
6. Images load and render at correct aspect ratios

Use Playwright's built-in multi-browser project configuration.
Include screenshot capture on failure for visual debugging.

Identifying browser-specific CSS edge cases with AI

Feed your actual CSS to AI for browser compatibility analysis:

Review the following CSS for potential cross-browser compatibility issues.
For each issue:
- Identify the specific property/feature
- List affected browsers and versions
- Provide the compatibility fix (prefixes, fallbacks, or feature detection)
- Rate severity: Breaks layout / Degrades gracefully / Cosmetic only

CSS to review:
---
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(min(280px, 100%), 1fr));
  gap: clamp(12px, 2vw, 24px);
  container-type: inline-size;
}

.card:has(.badge) {
  border: 2px solid var(--color-highlight, #F59E0B);
}

@container (min-width: 400px) {
  .card-content {
    display: flex;
    gap: 16px;
  }
}
---

Automated visual cross-browser diffing

Combine Playwright's multi-browser capabilities with visual snapshots to catch browser-specific rendering differences:

Generate a Playwright visual regression test that:
1. Captures screenshots of our component library pages in Storybook
2. Runs across chromium, firefox, and webkit
3. Compares screenshots between browsers (chromium as baseline)
4. Flags differences > 2% pixel change as potential browser inconsistencies
5. Generates a report with side-by-side comparisons for flagged components

Components to test: Button, Input, Modal, DataTable, DatePicker
Storybook URL: http://localhost:6006

Use Playwright's toHaveScreenshot() with custom thresholds per component.
Output a JSON report: { component, story, browser, diffPercent, screenshotPath }

Learning Tip: When AI generates a cross-browser test matrix, always validate the browser compatibility data against MDN Web Docs or Can I Use. AI can hallucinate specific browser version numbers for feature support. Use AI to generate the test structure and identify risk areas, then verify the compatibility facts independently for any feature where the answer materially affects your test strategy.