ChatGPT Prompts for QA Testers: Manual Testing, Automation, Bug Reporting

Published: July 2026 | 8 min read

QA testers are the last line of defense between bugs and users. Whether you do manual testing, automation, or a mix of both, ChatGPT can help you write test cases faster, design exploratory testing sessions, draft bug reports that developers actually want to fix, and build automation frameworks. These prompts are designed for hands-on testers, not QA managers.

Test Case Design

1. Test Case Generator from Requirements

Role: QA tester designing test cases
Task: Write test cases for [feature/requirement description].
Requirements: [Paste user story, acceptance criteria, or spec]
Test case format:
1. Test Case ID (TC-001)
2. Title (action-oriented: "Verify that [action] results in [outcome]")
3. Module/Area
4. Priority (Critical/High/Medium/Low)
5. Test Type (Functional/Boundary/Negative/Usability/Security/Performance)
6. Preconditions (what must be set up)
7. Test Steps (numbered, specific, reproducible)
8. Test Data (exact values to use)
9. Expected Result (precise)
10. Actual Result (blank for execution)
Generate test cases for:
- Happy path (2-3 cases)
- Alternative paths (2-3 cases)
- Boundary values (3-5 cases per numeric field)
- Negative tests (5+ cases: invalid input, empty, special chars, SQL injection, XSS)
- Edge cases (3-5: concurrent users, slow network, large data, session timeout)
Target: 20-30 test cases.
Format: Test case table ready for test management tool (Jira, TestRail, etc.).

2. Exploratory Testing Charter

Role: Exploratory testing specialist
Task: Create an exploratory testing charter for [feature/area].
Feature: [What to explore]
Duration: [time-box — typically 60-90 minutes]
Charter elements:
1. Mission: Explore [area] to discover [types of issues]
2. Scope: What is in scope, what is out of scope
3. Heuristics to guide testing:
   -功能性: Can I do X? What happens if I do Y?
   -边界: What if I enter [extreme value]? What if [field is empty]?
   -并发: What if two users do this at the same time?
   -错误: What error messages appear? Are they helpful? Accurate?
   -性能: Is it fast enough? Does it get slower with more data?
   -安全: Can I access someone else data? Can I inject scripts?
   -可访问性: Can I navigate with keyboard only? Screen reader?
4. Test data needed: [what data to prepare]
5. Note-taking format: [what to capture during exploration]
6. Debrief: [what to report after the session — bugs found, coverage achieved, risks identified]
Output: Exploratory testing charter ready for a tester to execute.
Include: 20-30 specific questions/heuristics to try during the session.

3. API Testing Test Cases

Role: API QA tester
Task: Create API test cases for [endpoint description].
API: [Method, URL, request body schema, headers, auth]
Test categories:
1. Positive tests:
   - Valid request, expected response (status, body, headers)
   - Optional fields: with and without each optional field
   - Different valid data types/formats
2. Negative tests:
   - Invalid auth (no token, expired token, wrong scope)
   - Invalid input (wrong type, too long, too short, special chars)
   - Missing required fields (one at a time)
   - Invalid combinations (dates where start > end, etc.)
3. Boundary tests:
   - Max length strings
   - Empty strings vs null vs missing field
   - Numeric: min, max, zero, negative
4. Security tests:
   - SQL injection in each field
   - XSS in string fields
   - Path traversal in file-related fields
   - Rate limiting (send 100 requests fast)
   - Authorization (try to access other users data)
5. Performance:
   - Response time with normal payload
   - Response time with large payload
   - Concurrent requests (10, 50, 100)
For each test: method, URL, body, headers, expected status, expected body pattern
Generate 25-30 API test cases.
Format: Ready for Postman collection, RestAssured, or similar.

Test Automation

4. Selenium/Playwright Script Generator

Role: Test automation engineer
Task: Write an automated test script for [scenario].
Tool: [Selenium / Playwright / Cypress]
Language: [Python / Java / JavaScript / TypeScript]
Scenario: [Step-by-step user flow to automate]
For each step:
1. Action (navigate, click, type, select, wait, assert)
2. Locator strategy (which selector? id, css, xpath, text?)
3. Wait strategy (explicit wait for what condition?)
4. Assertion (what to verify after the action)
Requirements:
- Page Object Model (separate page classes from test logic)
- Explicit waits (no hard sleeps)
- Screenshots on failure
- Test data from external source (CSV, JSON, fixture)
- Assertions with clear failure messages
- Cleanup after test (close browser, reset data if needed)
Output: Complete test script + page object class, ready to run.
Include: Test runner configuration (pytest, jest, etc.)

5. API Automation Script Generator

Role: API automation engineer
Task: Write automated API tests for [endpoint].
Tool: [RestAssured / Postman / Newman / Supertest / pytest+requests]
Language: [Java / JavaScript / Python]
Endpoints to test: [List with method, URL, body, expected response]
For each test:
1. Test name (descriptive)
2. Setup (create any prerequisite data)
3. Request (method, URL, headers, body)
4. Assertions:
   - Status code
   - Response body fields (specific values or patterns)
   - Response time (under X ms)
   - Headers (content-type, cache-control)
5. Cleanup (delete created data)
Requirements:
- Base URL configurable (environment switching)
- Auth token management (login, refresh, inject)
- Data factories (create test data programmatically)
- Schema validation (response matches expected schema)
- Parallel execution support
Output: Complete test suite ready to run in CI/CD.

6. Mobile Testing Strategy

Role: Mobile QA specialist
Task: Create a mobile testing strategy for [app type — iOS/Android/cross-platform].
App: [Description, key features, user base, platforms]
Testing matrix:
1. Device coverage:
   - OS versions (current - 2, current - 1, current, beta)
   - Screen sizes (phone, tablet, foldable)
   - Manufacturers (Samsung, Google, Apple, Xiaomi — for Android)
   - Network conditions (WiFi, 4G, 3G, offline, switching)
2. Testing types:
   - Functional (core flows work)
   - UI/UX (layout, navigation, gestures, orientation)
   - Performance (launch time, scroll, memory, battery)
   - Interrupt testing (calls, notifications, alarms, low battery)
   - Network testing (slow, intermittent, offline mode)
   - Installation (fresh install, upgrade, downgrade, reinstall)
   - Compatibility (OS version, device size, accessibility)
   - Security (data at rest, in transit, clipboard, screenshots)
   - Accessibility (VoiceOver/TalkBack, dynamic type, contrast)
3. Automation approach:
   - What to automate (regression-critical flows)
   - What to keep manual (exploratory, visual, interrupt)
   - Tools (XCUITest, Espresso, Appium, Detox)
Output: Mobile test strategy with prioritized test matrix and automation plan.

Bug Reporting & Communication

7. Bug Report That Developers Will Fix

Role: QA tester writing a bug report
Task: Write a bug report for [issue you found].
Bug: [Describe what happened]
Format:
1. Title: [Module] - [Specific behavior] - [Expected vs actual]
   Example: "Login - Invalid credentials error shows for valid login on Safari 17"
2. Environment:
   - Device/OS: [specific]
   - Browser/App version: [specific]
   - Environment: [dev/staging/prod]
   - User account: [test user details]
3. Steps to reproduce (numbered, exact, no assumptions):
   1. Go to [URL/page]
   2. Enter [exact value] in [field name]
   3. Click [button name]
   4. Observe [what happens]
4. Expected result: [What should happen]
5. Actual result: [What actually happens]
6. Frequency: [Always / Sometimes (X% of time) / Once]
7. Severity: [Critical/Major/Minor/Cosmetic — with justification]
8. Priority: [P1-P4 — based on user impact, not just severity]
9. Attachments: [Screenshot/Video/Logs — describe what to attach]
10. Workaround: [Is there a way to achieve the goal despite the bug?]
11. Related: [Links to related bugs, test cases, requirements]
Format: Ready to file in Jira/Bugzilla.
Constraint: Title must be specific enough to search for. "Bug in login" is useless. "Login page crashes when entering emoji in username field on iOS 17" is useful.

8. Bug Reproduction from Vague Reports

Role: QA reproducing a reported bug
Task: Help reproduce this bug from a vague report.
Report: [Paste the original bug report or user complaint — however vague]
Analysis:
1. What is the user trying to say? (translate to technical terms)
2. What could cause this? (list 3-5 hypotheses)
3. What information is missing? (what questions to ask the reporter)
4. What environments to try? (browser, OS, device combinations)
5. What data might trigger it? (specific inputs, data states)
Reproduction plan:
1. First attempt: [most likely scenario based on the report]
2. If that does not work: [second most likely]
3. If still not: [broader search — logs, analytics, similar reports]
4. Questions for the reporter:
   - [Specific question 1]
   - [Specific question 2]
   - [Specific question 3]
Output: Reproduction action plan + questions for the reporter.
Format: Ready to start investigating immediately.

Performance & Specialized Testing

9. Performance Test Plan

Role: Performance testing engineer
Task: Create a performance test plan for [application/endpoint].
Performance requirements:
- Response time: p50 < [X]ms, p95 < [Y]ms, p99 < [Z]ms
- Throughput: [N] requests/sec sustained
- Concurrent users: [C] at peak
- Max error rate: [E]%
Test scenarios:
1. Baseline test (single user, measure raw response time)
2. Load test (ramp to expected peak, hold for [duration])
3. Stress test (ramp beyond peak until system breaks — find the ceiling)
4. Soak test (run at 80% peak for [hours] — check for memory leaks, degradation)
5. Spike test (sudden 5x traffic spike — how does the system handle it?)
6. Scalability test (double the load, does it scale linearly?)
For each scenario:
1. User load (concurrent users / RPS)
2. Ramp-up (how quickly to reach target load)
3. Duration (how long to sustain)
4. Metrics to capture (latency, throughput, errors, CPU, memory, GC)
5. Pass criteria (specific thresholds)
6. Fail action (what to do if system does not meet criteria)
Tool: [JMeter / k6 / Gatling / Locust]
Output: Performance test plan with script structure and execution schedule.

10. Accessibility Testing Checklist

Role: Accessibility QA specialist
Task: Create an accessibility testing checklist for [application type].
Standards: WCAG 2.1 AA (or 2.2 AA)
Checklist by principle:
1. Perceivable:
   - Alt text on all images (meaningful or empty for decorative)
   - Color contrast (4.5:1 for normal text, 3:1 for large)
   - No information by color alone (also use text/icon)
   - Captions for video, transcripts for audio
   - Resizable text (200% zoom, no loss of content/function)
2. Operable:
   - Full keyboard navigation (Tab, Enter, Space, Escape, arrows)
   - No keyboard traps (can always Tab out)
   - Focus visible (clear focus indicator)
   - Skip to main content link
   - No auto-redirects or time limits (or can extend/disable)
3. Understandable:
   - Language attribute on page
   - Clear form labels (associated with inputs)
   - Error messages are descriptive and programmatic
   - Instructions are clear (not just "fix the error")
4. Robust:
   - Valid HTML (no duplicate IDs, proper nesting)
   - ARIA used correctly (roles, labels, states)
   - Screen reader testing (VoiceOver, NVDA, TalkBack)
   - Semantic HTML (use buttons for buttons, not divs)
For each check: how to test (manual, automated tool, screen reader)
Generate 40-50 items.
Format: Accessibility checklist ready for execution.

11. Security Testing Primer for QA

Role: QA with security testing knowledge
Task: Create a security testing checklist for QA testers (not security experts).
Scope: [What to test — application type, key features]
Tests a QA tester can do without specialized tools:
1. Input validation:
   - SQL injection: enter single quote, OR 1=1, ; DROP TABLE
   - XSS: enter , 
   - Command injection: ; ls, | cat /etc/passwd
   - Path traversal: ../../../etc/passwd
   - LDAP injection: *)(uid=*)
2. Authentication:
   - Can I access pages without logging in? (direct URL navigation)
   - Can I use another user session token?
   - What happens with expired/invalid tokens?
   - Password complexity enforcement?
   - Brute force protection (lockout after X attempts?)
3. Authorization:
   - Can I access other users data by changing IDs in URL?
   - Can I perform admin actions as a regular user?
   - Can I access API endpoints not in my role?
4. Data exposure:
   - Is sensitive data in the URL? (passwords, tokens in query params)
   - Is data in page source that should not be? (other users email, internal IDs)
   - Are API responses exposing more data than needed?
5. Session management:
   - Does logout actually invalidate the session?
   - Can old session tokens be reused?
   - Are cookies HttpOnly and Secure?
For each test: how to test, expected secure behavior, what to report if insecure.
Format: Security testing guide for QA, with clear instructions.

12. Test Data Management Plan

Role: QA test data specialist
Task: Create a test data management plan for [application].
Data needs: [What test data is needed — users, products, transactions, files]
Current approach: [How is test data created now? manual? scripts? production copy?]
Plan:
1. Test data sources:
   - Synthetic (generated programmatically — for privacy and volume)
   - Masked production data (if needed — how to mask, who approves)
   - Seeded data (fixed dataset for regression tests)
2. Data creation strategy:
   - API-based (create via API, most reliable)
   - Database insertion (fast but brittle)
   - UI creation (slow but tests the full path)
3. Data lifecycle:
   - Creation (when, how, by whom)
   - Refresh (how often, full reset or incremental?)
   - Cleanup (after each test? after suite? scheduled purge?)
4. Data organization:
   - Per test (each test creates its own — most isolated)
   - Per suite (shared setup, individual usage)
   - Shared pool (pre-created, checked out/in)
5. Sensitive data handling:
   - PII (how to avoid using real PII)
   - Payment (use test card numbers, sandbox)
   - Compliance (GDPR — no real personal data in test env)
Output: Test data management plan with tool recommendations and sample data creation scripts.

Best Practices

For more testing content, see our ChatGPT prompts for quality assurance and ChatGPT prompts for software developers.