UAT test cases help business users confirm whether a feature works in the real workflow. ChatGPT can draft a first pass from requirements, but the prompt needs to make every case clear enough for a non-technical tester to run and trace back to an acceptance criterion.

Best use cases

  • Turning acceptance criteria into business-language test cases.
  • Mapping each test case to a requirement, user story, or acceptance criterion.
  • Finding missing negative scenarios, role limits, and edge cases.
  • Preparing realistic test data and expected results.
  • Defining who runs tests, answers questions, records evidence, and signs off before release.

Copy this prompt

Create UAT test cases from these requirements. Feature: [feature name] User story or requirement: [paste requirement] Acceptance criteria: [paste criteria] Business workflow: [describe the real user journey this feature supports] User roles: [who will use or approve this feature] UAT responsibility: [who will run tests, answer product questions, fix defects, and approve sign-off] Open defect rule: [whether minor defects can pass with documented approval, or must block release] Known risks: [edge cases, permissions, data rules, integrations] Return a table with: Test case ID Linked requirement or acceptance criterion Scenario Tester or approver role Preconditions Test data needed Steps Expected result Priority Pass/fail evidence the tester should record Sign-off or defect note Notes for the tester Rules: - Write steps in plain business language, not technical language. - Cover the main workflow, negative cases, permission limits, and realistic data problems. - Separate who runs each test, who answers unclear business questions, and who approves sign-off. - Do not invent requirements or acceptance criteria. - If a rule is unclear, list it as a question for the product owner before UAT starts.

Test input

Feature: guest checkout Requirement: A shopper can buy without creating an account. Acceptance criteria: - Shopper can enter email, shipping address, payment details, and place order. - Order confirmation is sent by email. - Existing account holders are prompted to sign in but can continue as guest. Business workflow: shopper finds a product, adds it to cart, checks out as guest, receives confirmation, and support can find the order later. User roles: guest shopper, existing account holder, support agent checking order status. UAT responsibility: ecommerce manager runs checkout tests, support lead reviews order lookup cases, product owner answers unclear rules, engineering lead fixes defects, operations manager signs off. Open defect rule: payment, tax, shipping, and confirmation email failures block sign-off; minor wording issues can pass only if the operations manager approves the release note. Known risks: invalid email, failed payment, missing shipping fields, duplicate email already tied to account, mobile checkout, tax/shipping calculation, confirmation email delay.

What good output should include

  • A clear link between each test case and the acceptance criterion it proves.
  • Plain steps a business tester can follow without developer knowledge.
  • Realistic test data, including invalid inputs and role-based scenarios.
  • Observable expected results, not vague phrases like "works correctly."
  • Clear tester, reviewer, support, and sign-off roles so approval is not vague.
  • A short list of open questions or unresolved defects that block confident sign-off.

Stronger prompt

Create UAT test cases for business users. Do not only cover the happy path. Feature: [feature name] Requirement: [paste requirement] Acceptance criteria: [paste criteria] Known risks: [permissions, validation, edge cases, integrations, mobile, reporting] UAT entry criteria: [what must be true before testers start] UAT responsibility: [business tester, product owner, QA or developer support, defect owner, sign-off owner] UAT sign-off owner: [person or role approving the release] Sign-off standard: [which failures block release, and which minor issues can pass with written approval] Return: 1. A short test strategy 2. A role map for who creates, runs, supports, fixes, and approves UAT 3. A traceability map from acceptance criteria to test cases 4. A table with test case ID, scenario, tester or approver role, preconditions, test data, steps, expected result, priority, pass/fail evidence, defect note, and tester notes 5. At least 3 negative test cases 6. At least 2 role or permission cases 7. At least 2 edge cases 8. Questions to ask the product owner before UAT starts 9. A short sign-off checklist that names any unresolved defects that need written approval

What to review

Check whether ChatGPT missed permissions, error states, empty states, edge cases, and real user behavior. UAT should prove the workflow works, not just the happy path.

Fix weak UAT test cases

Review these UAT test cases before I give them to business users. Check for: 1. Steps that use technical language a business tester may not understand 2. Missing links to acceptance criteria 3. Expected results that are not observable 4. Missing test data 5. Missing negative, permission, or edge cases 6. Missing tester, approver, defect owner, or sign-off standard 7. Any test that is really a QA/system test instead of a user acceptance test Rewrite only the weak cases and list any questions that must be answered before sign-off.

Related guides

Project status reportsSOPs with ChatGPTReport summaries