A button can look perfect while doing nothing. A form can work on a developer's laptop and become interpretive dance on a phone. A modal can be technically visible but unreachable by keyboard. Interfaces fail in ways that screenshots, tickets, and confident demos conveniently hide.
AI UI testing prompts can help turn verified requirements and designs into a useful test plan. They can organize states, propose scenarios, expose missing questions, draft accessibility checks, and summarize sanitized observations. They cannot see or operate your interface unless explicitly connected to approved tools, know what the designer intended, verify behavior across real devices, judge whether friction is acceptable, or approve a release.
AI can draft the test map. A human still has to use the interface, observe what happened, and decide whether it is good enough.
If you need broader strategy first, start with AI test plan prompts. For requirement-level coverage, use AI test case prompts. UI testing needs both. A huge generated checklist is not proof that a customer can complete the flow.
What good UI testing actually checks
UI testing is not clicking the happy path once and announcing victory. A useful test examines what the user sees, what they can operate, what state the system enters, and what happens when reality refuses to cooperate.
Depending on the feature, that can include:
- content, hierarchy, controls, labels, and instructions;
- layout across supported viewport sizes and zoom levels;
- keyboard navigation, focus order, and visible focus;
- screen-reader names, roles, states, and announcements;
- valid, invalid, incomplete, and unexpectedly long input;
- loading, empty, success, warning, offline, and error states;
- permissions, account states, and role-specific views;
- browser, operating-system, device, and input-method coverage;
- navigation history, refresh, deep links, and interrupted flows;
- visual changes against an approved baseline;
- state changes and downstream outcomes behind the interface;
- evidence, cleanup, severity criteria, and human ownership.
The exact coverage comes from the real requirement and the risk. A decorative preference toggle is not the same as a payment confirmation. A public marketing form is not the same as an employee health-data workflow. The model should arrange verified facts, not flatten every screen into the same generic checklist.
A test also needs an oracle: the source used to decide whether behavior is correct. That may be approved acceptance criteria, a current design, a content specification, an accessibility standard adopted by the organization, a browser-support policy, or a confirmed product decision. “The model thought this looked wrong” is not an oracle. It is autocomplete wearing a tiny QA badge.
The reusable AI UI testing prompt formula
Use this foundation, then add one of the specialized prompts below:
“Act as a UI testing planning assistant. I am testing [named user flow] for [user role] in [approved environment]. Use only the supplied requirements, approved design, supported browsers and devices, accessibility expectations, known risks, and sanitized examples. Produce [requested artifact] with setup, actions, expected results traced to a source, observable evidence, state changes, cleanup, and unanswered questions. Separate confirmed requirements from hypotheses. Do not invent behavior, test results, accessibility compliance, browser support, or release decisions.”
That last sentence matters. Models complete patterns. If the design shows a familiar date picker, a model may assume it supports arrow keys, date formatting, and range selection exactly like another component. Familiar is not verified.
Never paste credentials, customer PII, production screenshots, private logs, payment details, health data, HR records, unreleased strategy, vulnerability details, regulated data, or confidential client material into an unapproved AI tool. Use approved test environments, synthetic records, redacted screenshots, placeholder secrets, and human privacy and security review.
What to collect before prompting
“Test the settings page” produces generic sludge. Gather the smallest safe set of verified context first.
| Input | Why it matters | Human check |
|---|---|---|
| Named flow and user goal | Defines what success means | Product owner confirms scope |
| Current requirement and design | Supplies expected behavior | Resolve conflicts and stale versions |
| User roles and account states | Exposes permission differences | Confirm approved test accounts |
| Supported browsers and devices | Bounds compatibility coverage | Check current support policy |
| Viewports, zoom, and input methods | Shapes responsive and access checks | Include keyboard and touch where relevant |
| Content and validation rules | Makes form expectations precise | Confirm source and localization needs |
| Loading, empty, and error behavior | Covers non-happy paths | Identify safe failure simulations |
| Synthetic fixtures | Enables repeatable testing | Privacy review and cleanup plan |
| Evidence and severity rules | Turns findings into useful defects | Name owners and storage location |
Keep unknowns visible. If nobody has decided what happens when a title wraps to four lines, ask the model to create a clarification question. Do not let it invent a truncation rule because ellipses feel professional.
This came from a book.
Don't Replace Me
200+ pages. 24 chapters. The honest version of what AI means for your career, written by someone who actually builds this stuff.
Get the Book →10 AI UI testing prompts
Replace bracketed text with verified, non-sensitive information. Every output is a draft artifact, not proof of execution.
1. Turn requirements and designs into a UI test matrix
“Review this verified requirement, approved design, content specification, user role, and risk note: [paste]. Create a test matrix covering the happy path, alternate paths, key states, navigation, validation, accessibility, responsive behavior, persistence, and cleanup. For each expected result, cite the supplied source or label it ‘needs human confirmation.’ Do not invent interactions.”
This is the useful first pass when truth is scattered across a ticket, a design file, and three messages everybody pretends are not part of the specification.
Ask for traceability. Each row should connect to a requirement, design annotation, content rule, or risk. Rows without a source are questions. A designer, product owner, and tester should review the matrix before generated breadth becomes fake certainty.
2. Test responsive layouts without worshipping screenshots
“Using these supported viewports, zoom levels, content constraints, breakpoints, and approved designs: [paste], draft responsive UI checks. Cover narrow and wide screens, orientation changes, long text, localization expansion, zoom, scrolling, sticky elements, overlays, touch targets, clipped content, and preserved task completion. Mark unspecified behavior as a question.”
Responsive testing is about usability, not merely matching pixels. Check whether controls remain reachable, text stays readable, content order still makes sense, and the user can finish the task. A card shifting by two pixels matters less than a submit button escaping below an unscrollable modal.
Use real supported devices or trustworthy emulation for execution. The model can suggest a matrix; it cannot prove what Safari, a mobile keyboard, or a high-zoom desktop actually renders.
3. Challenge forms and validation
“From these verified field rules, formats, dependencies, and submission outcomes: [paste], create tests for blank required fields, optional fields, whitespace, minimum and maximum lengths, invalid formats, pasted content, autofill, duplicate submission, server rejection, corrected input, and preserved values. Include exact expected messages only when supplied.”
Forms are tiny bureaucracies. They fail by rejecting valid names, deleting input after one mistake, placing an error where nobody can find it, or showing “Something went wrong” after the submission actually succeeded.
Test both client and server outcomes. Confirm focus moves sensibly, errors are associated with fields, summaries link to problems where applicable, and resubmission does not create duplicates. Use synthetic data. Do not feed a general chatbot real customer records for the noble purpose of checking a dropdown.
4. Review keyboard navigation and focus
“Using this verified interaction design and component inventory: [paste], draft keyboard tests for entry focus, logical tab order, visible focus, native controls, custom widgets, menus, dialogs, escape behavior, focus trapping, focus restoration, skip links, and completion without a pointer. Cite supplied requirements and flag uncertain key behavior.”
A flow is not keyboard-accessible because pressing Tab eventually reaches something. Focus must be visible, ordered sensibly, and managed when content appears or disappears. Dialogs should not strand focus behind themselves or fling it to the top of the page when closed.
Run these checks with an actual keyboard. Component semantics and behavior need human observation, particularly when a custom widget imitates a native control but forgets half the contract.
5. Plan screen-reader and accessibility checks
“From these approved accessibility requirements, semantic structure, component states, labels, error rules, and supported assistive-technology combinations: [paste], create a manual review plan. Cover page title, landmarks, headings, accessible names, roles, values, status announcements, errors, instructions, dynamic updates, reading order, and task completion. Do not claim conformance from supplied text.”
AI can help organize an accessibility review. It cannot certify accessibility. Automated checks also catch only part of the problem. A button may have a name and still be confusing; a heading structure may pass a rule and still misrepresent the page.
Use qualified human review, real assistive technology, and the organization’s adopted standard. Treat generated suggestions as preparation, not a compliance statement. False confidence is particularly rotten when it excludes people.
6. Cover loading, empty, error, and interrupted states
“Using this flow, dependency map, approved state designs, retry rules, and safe simulation methods: [paste], draft tests for initial loading, slow loading, empty results, partial data, offline behavior, timeout, permission failure, server error, retry, refresh, back navigation, interrupted submission, and recovery. Include evidence and stop conditions.”
Teams lovingly design the populated state and leave everything else to chance. Users spend plenty of time in everything else.
Check whether loading indicators explain what is happening, empty states distinguish “nothing exists” from “nothing loaded,” retries are safe, and error recovery preserves work. Confirm the underlying state. A spinner disappearing does not prove a save succeeded.
7. Test permissions and role-specific views
“Using this verified role-permission matrix, account states, ownership rules, and flow requirements: [paste], create UI tests for allowed actions, hidden or disabled controls, direct navigation, stale sessions, changed roles, cross-owner records, and useful denial messages. Include the service-side outcome to verify. Do not treat hidden UI as authorization.”
The interface should communicate permissions clearly, but hiding a button is not security. A user may still navigate directly or call the underlying service. Coordinate with API and security testing where risk warrants it.
Use approved synthetic accounts. Never paste live session cookies, tokens, customer identities, or screenshots containing private records into the prompt. Humans verify both the visible experience and the actual authorization response.
8. Build a sensible cross-browser and device matrix
“Given this current browser-support policy, usage data, feature risk, device constraints, input methods, and test budget: [paste], propose a prioritized compatibility matrix. Map high-risk flows to browser, operating system, viewport, touch or pointer, keyboard, and assistive-technology combinations. Explain prioritization without inventing market-share data.”
Testing every combination is impossible. Testing only the developer’s favorite browser is lazy. Use policy, audience evidence, technical risk, and change scope to choose coverage.
AI can structure the decision. Humans must confirm the support data and execute on real engines. “Chromium worked” does not prove Safari worked, no matter how strongly the generated table believes in web standards.
9. Review visual-regression differences
“Compare these approved baseline notes and sanitized visual-difference observations: [paste]. Classify differences for human review by affected component, viewport, content, likely intentionality, task impact, and evidence needed. Separate cosmetic differences from possible functional or accessibility problems. Do not approve or reject changes.”
Visual regression tools produce differences, not decisions. Font rendering, dynamic content, animation, timestamps, and operating-system behavior can create noise. Meanwhile, a small shift can hide a checkbox or change reading order.
Have a human compare against the approved change, inspect the live interaction, and update baselines only after review. Otherwise visual testing becomes an elaborate machine for blessing whatever appeared most recently.
10. Turn observations into a reproducible UI bug report
“Turn these sanitized observations into a draft UI bug report: [paste]. Include environment and build, browser or device, viewport and zoom, user role, safe setup, exact steps, actual behavior, expected result traced to a source, reproducibility, task impact questions, redacted evidence, cleanup, and missing information. Do not assign severity or claim a root cause.”
“Button broken on mobile” is not a report. The reader needs the starting state, exact environment, action, outcome, expectation, and evidence needed to reproduce it.
Use AI bug report prompts for more reporting patterns. A human still confirms the defect, strips sensitive information, judges impact, routes ownership, and decides whether it blocks release.
A practical workflow that avoids checklist theater
Use these prompts inside a human-owned process:
- Confirm the source of truth. Resolve stale designs and conflicting requirements.
- Name the user and goal. Test a real flow, not an abstract collection of screens.
- Define risk and coverage. Choose browsers, devices, roles, and access needs deliberately.
- Sanitize the input. Replace secrets and personal data with safe fixtures.
- Generate a draft artifact. Require traceability and explicit unknowns.
- Review before execution. Product, design, engineering, QA, and accessibility owners correct assumptions.
- Run real tests. Use approved environments, accounts, browsers, devices, and assistive technology.
- Inspect actual state. Verify persistence and service outcomes, not just visible messages.
- Capture evidence. Record versions, settings, steps, redacted media, and timestamps.
- Triage with humans. Confirm defects, severity, ownership, and release impact.
For less scripted discovery, use AI exploratory testing prompts. For change-focused coverage, use AI regression testing prompts. AI organizes possibilities. It does not create evidence by describing what evidence might look like.
Common mistakes
Treating the design file as the whole product
A design may omit delays, long content, permission failures, browser behavior, validation details, and state persistence. Pair it with verified requirements and the running system.
Letting AI invent expected behavior
A plausible interaction is still fiction. Expected results need a source. Unknown behavior should become a question, not an assertion with excellent formatting.
Checking only appearance
Inspect keyboard operation, semantics, state changes, history, service outcomes, and recovery. A polished screen can conceal a failed transaction.
Pasting production screenshots into a chatbot
Do not. Screenshots can contain names, messages, account numbers, internal URLs, or unreleased work. Redact them or use approved synthetic environments.
Confusing generated checks with executed tests
A model can write “verify that focus returns to the trigger.” It has not verified anything. Observed results belong to humans and authorized test systems.
Automating unstable assumptions
Review generated checks before placing them in CI. An invented expectation becomes a dependable false alarm, which is a very efficient way to teach a team to ignore testing.
Frequently asked questions
Can ChatGPT test a user interface for me?
It can help design tests and draft automation from supplied requirements. Unless it has an explicitly configured, authorized browser connection, it cannot operate the interface or observe results. Even with tools, humans must control access, evidence, coverage, and release decisions.
Can AI replace manual UI testing?
No. It can accelerate planning, variation, documentation, and code drafts. Humans still evaluate clarity, usability, accessibility, visual intent, unexpected behavior, and business impact on real systems.
Should AI generate UI automation code?
It can create a useful first draft. Review selectors, assertions, waits, fixtures, privacy, cleanup, and failure messages. Run the code in a controlled environment and keep human ownership of what the test proves.
How do I stop AI from inventing interface behavior?
Supply current requirements and designs, require each expectation to cite a source, instruct the model to label unknowns, and reject claims that cannot be traced. Then conduct a human review.
Can AI certify accessibility compliance?
No. It can organize checks and explain supplied criteria. Conformance requires the appropriate standard, qualified review, real assistive-technology testing, and organizational accountability.
What is the best first UI testing prompt?
Start by turning one important user flow into a traceable matrix of roles, states, interactions, expected outcomes, accessibility checks, responsive coverage, and unknowns. Narrow, reviewed scope beats a generic hundred-item checklist.
Can AI decide whether a UI bug blocks release?
No. It can summarize supplied evidence and identify missing questions. Product, design, engineering, QA, accessibility, security, and business owners judge severity and release risk.
How should I use UI prompts in an existing QA process?
Use them to accelerate preparation, gap review, documentation, and reporting. Keep execution, evidence collection, defect confirmation, and sign-off in the existing human-owned process. For the wider boundary, read what AI can and cannot do.
The bottom line
AI UI testing prompts are useful when they turn verified context into sharper questions and executable drafts. They are dangerous when polished output is mistaken for a requirement, a test run, an accessibility judgment, or a release decision.
Give the model safe facts. Demand traceability. Keep unknowns unknown. Then operate the interface, inspect the real outcomes, and make the decision with humans who understand the users and consequences.
That is the wider point of Don’t Replace Me: use AI for speed and structure without handing it facts, access, taste, judgment, or accountability it does not possess. A fast assistant can improve UI testing. It cannot own whether your interface works.
