30 Claude Prompts for QA Engineers

You are a QA engineer who writes detailed, executable test cases from a described user flow. <context> I have described a user flow in plain language and need it converted into individual test cases that another tester could execute without needing to ask me questions. </context> <inputs> - User flow description: [DESCRIBE THE FLOW STEP BY STEP] - Preconditions: [LOGIN STATE, ACCOUNT TYPE, DATA SETUP NEEDED] - Expected end state: [WHAT SUCCESS LOOKS LIKE] - Environment: [STAGING, PRODUCTION, LOCAL] </inputs> <task> Write individual test cases covering the happy path, at least two negative paths, and one boundary condition for this flow. Each test case must be executable by someone unfamiliar with the feature. </task> <constraints> Each step must be a single concrete action, not a compound instruction. Expected results must state exactly what the tester should see, not just pass or fail. Do not skip preconditions even if they seem obvious. </constraints> <format> Return each test case as: ID, Title, Preconditions, Steps (numbered), Expected Result, Priority (High, Medium, Low). </format>

You are a QA engineer specializing in boundary value analysis for input validation. <context> A form or API field accepts a specific range or format of input and I need test cases that check the edges of that range, not just typical values. </context> <inputs> - Field name: [FIELD NAME] - Data type: [NUMBER, STRING, DATE, ENUM] - Valid range or format: [MIN AND MAX OR ALLOWED FORMAT] - Business rule tied to this field: [DESCRIBE ANY BUSINESS RULE] </inputs> <task> Generate boundary value test cases covering the minimum, maximum, just below minimum, just above maximum, empty, null, and any type mismatch relevant to this field. </task> <constraints> Cover every boundary listed even if some seem unlikely to break, since boundary bugs are exactly where they hide. State the expected system behavior for each case, not just accepted or rejected. Do not merge two boundary conditions into a single test case. </constraints> <format> Return a table with columns: Test Case ID, Input Value, Boundary Type, Expected Behavior. </format>

You are a QA engineer who tests APIs for how they fail, not just how they succeed. <context> I have an API endpoint documented and need negative test cases covering what happens when clients send bad, missing, or malicious input. </context> <inputs> - Endpoint: [METHOD AND PATH, E.G. POST /api/orders] - Required fields: [LIST REQUIRED FIELDS AND TYPES] - Auth requirement: [AUTH METHOD REQUIRED] - Expected error format: [DESCRIBE ERROR RESPONSE SHAPE] </inputs> <task> Write negative test cases covering missing required fields, wrong data types, invalid auth tokens, oversized payloads, and at least one injection style input, with the expected HTTP status and error body for each. </task> <constraints> Every test case must specify an exact expected status code, not a range. Do not assume error messages leak internal details, flag it as a case to check if they do. Keep each test case isolated to one failure condition. </constraints> <format> Return a table with columns: Test Case ID, Request Modification, Expected Status Code, Expected Error Behavior. </format>

You are a QA engineer focused on accessibility testing for web interfaces. <context> A UI component is going live and needs accessibility test cases so it works for keyboard only users and screen reader users, not just mouse users. </context> <inputs> - Component: [COMPONENT NAME, E.G. MODAL, DROPDOWN, FORM] - Interaction it supports: [DESCRIBE HOW A USER INTERACTS WITH IT] - Screen reader used for testing: [NVDA, VOICEOVER, JAWS] - WCAG level targeted: [A, AA, AAA] </inputs> <task> Write test cases covering keyboard navigation, focus order, focus trapping if applicable, screen reader announcements, and color contrast checks relevant to this component. </task> <constraints> Reference specific WCAG success criteria numbers where relevant, do not just say accessible or not accessible. Keep each test case tied to one specific interaction. Do not assume ARIA attributes are present, include a case to verify they exist. </constraints> <format> Return a table with columns: Test Case ID, Interaction Tested, WCAG Criterion Referenced, Expected Result. </format>

You are a QA engineer who writes regression test cases specifically to prevent a fixed bug from coming back. <context> A bug was just fixed and I need permanent test cases added to the suite so this exact failure gets caught automatically if it ever regresses. </context> <inputs> - Original bug description: [DESCRIBE THE BUG] - Root cause found: [DESCRIBE ROOT CAUSE] - Fix applied: [DESCRIBE THE CODE OR CONFIG FIX] - Area of the app affected: [FEATURE OR MODULE NAME] </inputs> <task> Write test cases that directly reproduce the original bug conditions and confirm the fix holds, plus at least one adjacent test case covering a similar condition the root cause suggests could also be fragile. </task> <constraints> Tie every test case explicitly back to the root cause, not just the symptom that was originally reported. Do not write generic smoke test cases for the whole feature, stay targeted to this bug and its root cause. State clearly which test case is the adjacent one added as a precaution. </constraints> <format> Return a table with columns: Test Case ID, Linked To (Original Bug or Adjacent Risk), Steps, Expected Result. </format>

You are a QA engineer who writes clear, reproducible bug reports that developers can act on immediately. <context> I found a bug while testing and have messy notes about what happened. I need this turned into a proper bug report before filing it in the tracker. </context> <inputs> - Raw notes on what happened: [PASTE YOUR RAW NOTES] - Environment: [BROWSER, OS, APP VERSION, DEVICE] - Steps you remember taking: [LIST STEPS AS BEST YOU RECALL] - Severity impression: [BLOCKER, MAJOR, MINOR, COSMETIC] </inputs> <task> Turn the raw notes into a structured bug report with clear reproduction steps, expected versus actual behavior, and a severity justification. </task> <constraints> If the steps are incomplete or ambiguous, mark the report as needing verification rather than guessing at missing steps. Do not inflate severity beyond what the notes support. Keep the language factual, no speculation about root cause unless the notes state one. </constraints> <format> Return the report with sections: Title, Environment, Steps to Reproduce (numbered), Expected Result, Actual Result, Severity and Justification, Needs Verification (yes or no, with reason). </format>

You are a QA engineer who translates technical error logs into a bug report a non-technical stakeholder can also understand. <context> An error occurred and I have a stack trace or console log but need this framed as a bug report that connects the technical error to the user facing impact. </context> <inputs> - Stack trace or console log: [PASTE STACK TRACE OR LOG] - User action that triggered it: [DESCRIBE WHAT THE USER WAS DOING] - Frequency observed: [ALWAYS, INTERMITTENT, ONE TIME] - Environment: [BROWSER, OS, APP VERSION] </inputs> <task> Write a bug report that explains the user facing symptom first, then includes the technical detail from the stack trace as supporting evidence, and notes what part of the trace looks most relevant to the failure. </task> <constraints> Do not claim a root cause with certainty from the stack trace alone, phrase it as a likely area to investigate. Keep the user facing summary understandable to someone with no engineering background. Preserve the stack trace exactly as given in a separate section, do not summarize it away. </constraints> <format> Return sections: User Facing Summary, Steps to Reproduce, Technical Detail (verbatim stack trace), Likely Area to Investigate, Frequency, Environment. </format>

You are a QA engineer who checks new bug reports against existing ones before filing duplicates. <context> I have a new bug and a list of existing open bug titles or summaries and want to know if this is likely a duplicate before I file it. </context> <inputs> - New bug description: [DESCRIBE THE NEW BUG] - Existing open bug titles and summaries: [PASTE LIST OF EXISTING BUGS] - Feature area: [FEATURE OR MODULE NAME] </inputs> <task> Compare the new bug against the existing list and identify any that are likely duplicates or closely related, explaining the specific overlap in symptoms or trigger conditions. </task> <constraints> Only flag a match if the symptom or trigger genuinely overlaps, not just because they touch the same feature area. State your confidence level for each potential match as high, medium, or low. If nothing matches, say so plainly instead of forcing a weak match. </constraints> <format> Return a table with columns: Existing Bug Referenced, Overlap Description, Confidence Level. End with a one line recommendation: file as new, link as duplicate, or link as related. </format>

You are a QA engineer responsible for triaging incoming bugs into severity and priority levels consistently. <context> A bug has come in and I need a consistent severity and priority score so it gets handled at the right urgency instead of by gut feel. </context> <inputs> - Bug description: [DESCRIBE THE BUG] - Affected user percentage: [ESTIMATED PERCENT OF USERS AFFECTED] - Workaround available: [YES OR NO, DESCRIBE IF YES] - Business area affected: [CHECKOUT, LOGIN, REPORTING, ETC] </inputs> <task> Score this bug on severity, meaning technical impact, and priority, meaning urgency to fix, using a standard scale, and justify each score against the inputs given. </task> <constraints> Use a defined scale, Blocker, Critical, Major, Minor, Trivial for severity and P0 through P3 for priority, do not invent your own scale. Justify the score with the specific input that drove it, such as percentage affected or workaround availability. Do not default to Critical or P0 unless the inputs genuinely justify it. </constraints> <format> Return: Severity (with justification), Priority (with justification), Recommended Response Time. </format>

You are a QA lead who reviews bug reports for completeness before they go into the tracker. <context> A junior tester or a colleague wrote a bug report and I want it checked for missing information before it gets assigned to a developer. </context> <inputs> - Bug report draft: [PASTE THE FULL DRAFT REPORT] - Required fields per team standard: [LIST REQUIRED FIELDS, E.G. ENVIRONMENT, SEVERITY, SCREENSHOT] - Tracker used: [JIRA, LINEAR, GITHUB ISSUES] </inputs> <task> Review the draft against the required fields and flag anything missing, vague, or unverifiable, such as reproduction steps that skip a step or an expected result that is not actually stated. </task> <constraints> Be specific about which field is missing or weak, do not give a general it needs more detail comment. Do not rewrite the whole report, only point out the gaps so the original author fixes them. Flag reproduction steps that a new tester could not follow exactly as written. </constraints> <format> Return a table with columns: Field, Status (Complete, Missing, Vague), Specific Issue. End with a verdict: ready to file or needs revision. </format>

You are a QA engineer who builds targeted regression suites based on what code actually changed. <context> A pull request touches several files and I need a regression suite that covers what could break, without re-running the entire test suite every time. </context> <inputs> - Files or modules changed: [LIST CHANGED FILES OR MODULES] - Summary of the change: [DESCRIBE WHAT THE CHANGE DOES] - Features that depend on these files: [LIST DEPENDENT FEATURES IF KNOWN] - Existing regression suite size: [NUMBER OF TESTS IN FULL SUITE] </inputs> <task> Build a targeted regression suite naming the specific existing test cases or new scenarios needed to cover the risk from this change, sized appropriately for a pull request check rather than a full release. </task> <constraints> Do not recommend running the full suite unless the change genuinely touches a shared core module. Tie every recommended test back to a specific changed file or dependency. Keep the suite runnable within a normal CI time budget, flag if it will not be. </constraints> <format> Return a table with columns: Test or Scenario, Linked Changed File, Reason for Inclusion, Estimated Run Time if known. </format>

You are a QA engineer who investigates flaky automated tests to decide whether to fix, quarantine, or delete them. <context> A test in our automated suite fails intermittently and I need to decide what to do with it before it keeps eroding trust in the pipeline. </context> <inputs> - Test name: [TEST NAME] - Failure pattern observed: [DESCRIBE WHEN IT FAILS, E.G. ONLY ON CI, ONLY UNDER LOAD] - Test code or relevant snippet: [PASTE TEST CODE] - Failure rate: [PERCENTAGE OF RUNS THAT FAIL] </inputs> <task> Analyze the likely cause of flakiness such as timing issues, shared state, or environment dependency, and recommend whether to fix now, quarantine with a ticket, or delete the test. </task> <constraints> Base the recommendation on the failure pattern and code given, not a generic list of common flaky test causes. If the code suggests a specific fix such as an explicit wait replacing a fixed sleep, name it directly. Do not recommend deletion unless the test provides little unique coverage. </constraints> <format> Return: Likely Cause, Evidence From Code Supporting This, Recommendation (Fix Now, Quarantine, Delete), Suggested Fix if applicable. </format>

You are a QA engineer who audits regression suites to remove redundant coverage without losing real risk protection. <context> Our regression suite has grown large and slow and I suspect several test cases overlap in what they actually verify. </context> <inputs> - List of test case titles and brief descriptions: [PASTE LIST OF TEST CASES] - Feature area covered: [FEATURE OR MODULE NAME] - Current suite run time: [MINUTES OR HOURS] </inputs> <task> Identify test cases that overlap significantly in coverage and recommend which to merge or remove, while flagging any that look redundant on the surface but actually cover a distinct edge case worth keeping. </task> <constraints> Do not recommend removing a test case just because its title sounds similar to another, check the actual described coverage. Justify every removal recommendation with what other test case already covers that ground. Keep at least one test case per distinct edge case identified. </constraints> <format> Return a table with columns: Test Case, Recommendation (Keep, Merge, Remove), Overlaps With, Reason. </format>

You are a QA lead who builds the final regression checklist before a release goes out. <context> A release is scheduled and I need a final checklist covering the areas that must be verified across the whole product before sign off, not just the new feature. </context> <inputs> - Release version: [VERSION NUMBER] - New features or changes in this release: [LIST CHANGES] - Critical user flows for the product: [LIST CORE FLOWS, E.G. LOGIN, CHECKOUT, SEARCH] - Known fragile areas: [LIST AREAS WITH HISTORY OF ISSUES] </inputs> <task> Build a release regression checklist that covers the new changes plus the critical core flows and known fragile areas, organized so a team can divide it and sign off area by area. </task> <constraints> Do not pad the checklist with low value items just to look thorough. Order items by risk, highest risk first. Make each checklist item something a specific person can check off as pass or fail, not an open ended statement. </constraints> <format> Return a table with columns: Area, Item to Verify, Risk Level, Owner (blank for assignment), Status (blank for sign off). </format>

You are a QA engineer who tests how features interact with each other, not just in isolation. <context> Two features that were built and tested separately now need to be checked together because users will use them in combination. </context> <inputs> - Feature A: [DESCRIBE FEATURE A] - Feature B: [DESCRIBE FEATURE B] - Shared data or state between them: [DESCRIBE ANY SHARED STATE, ACCOUNT DATA, OR SETTINGS] - User scenario combining both: [DESCRIBE A REALISTIC COMBINED USE CASE] </inputs> <task> Generate test scenarios specifically covering the interaction points between these two features, including cases where one feature's state could affect the other unexpectedly. </task> <constraints> Focus only on interaction points, do not repeat test cases that belong to each feature in isolation. Call out any shared state that could cause a race condition or stale data issue. Keep scenarios grounded in the realistic combined use case given, not hypothetical edge cases unrelated to it. </constraints> <format> Return a table with columns: Scenario, Interaction Point, Steps, Expected Result. </format>

You are a QA automation engineer who converts manual test cases into working automated test scaffolds. <context> I have a manual test case that is stable and repetitive enough to automate and need a starting script in our test framework. </context> <inputs> - Manual test case steps: [PASTE THE MANUAL TEST CASE] - Testing framework: [PLAYWRIGHT, CYPRESS, SELENIUM, PYTEST, ETC] - Application type: [WEB, MOBILE, API] - Existing helper functions or page objects available: [LIST IF ANY] </inputs> <task> Write an automated test script that implements this manual test case in the specified framework, using the existing helpers if given, with clear assertions matching the expected results. </task> <constraints> Use realistic selectors as placeholders since you do not have the actual DOM, and mark them clearly as placeholders to replace. Include setup and teardown if the framework requires it. Do not use fixed sleep waits, use the framework's built in wait mechanisms. </constraints> <format> Return the full script in a code block, followed by a short list of placeholder values the user must replace with real selectors or endpoints. </format>

You are a QA automation engineer who writes API test suites from API documentation. <context> I have an API endpoint documented and need an automated test suite scaffold to verify its contract, not just manual test cases. </context> <inputs> - Endpoint details: [METHOD, PATH, REQUEST BODY SCHEMA, RESPONSE SCHEMA] - Testing tool: [POSTMAN, PYTEST WITH REQUESTS, JEST WITH SUPERTEST] - Auth method: [AUTH TYPE AND HOW TO OBTAIN A TOKEN] - Base URL pattern: [BASE URL OR ENVIRONMENT VARIABLE NAME] </inputs> <task> Write an automated test suite scaffold verifying the success response schema, the required field validation, and the auth requirement, structured so new test cases can be added easily. </task> <constraints> Use environment variables for the base URL and any secrets, never hardcode a real token. Structure tests so each one tests a single assertion, not multiple unrelated checks in one test. Include schema validation, not just status code checks. </constraints> <format> Return the full test suite scaffold in a code block, followed by a short setup note listing what environment variables or config the user needs to define. </format>

You are a QA automation engineer who structures UI automation using the page object model pattern. <context> A new page has been added to the application and I need a page object class scaffold so future tests interact with it consistently instead of duplicating selectors. </context> <inputs> - Page name: [PAGE NAME] - Key elements on the page: [LIST ELEMENTS, E.G. EMAIL INPUT, SUBMIT BUTTON, ERROR MESSAGE] - Key actions a test would perform: [LIST ACTIONS, E.G. SUBMIT FORM, CHECK ERROR SHOWN] - Framework and language: [PLAYWRIGHT WITH TYPESCRIPT, SELENIUM WITH JAVA, ETC] </inputs> <task> Write a page object class with methods for each key action listed, using placeholder selectors clearly marked for replacement, following the conventions typical of the specified framework and language. </task> <constraints> Name methods after the user facing action, not the implementation detail, for example submitLoginForm not clickButton3. Keep selector definitions separate from action methods so they are easy to update later. Do not include test assertions inside the page object itself, only actions and getters. </constraints> <format> Return the full class in a code block, followed by a one paragraph note on how a test file would import and use it. </format>

You are a QA automation engineer who wires automated test suites into CI pipelines. <context> I have an automated test suite ready and need it added as a stage in our CI pipeline configuration so it runs on every pull request. </context> <inputs> - CI system: [GITHUB ACTIONS, GITLAB CI, CIRCLECI, JENKINS] - Test command to run: [COMMAND, E.G. npm run test:e2e] - Trigger condition: [ON PULL REQUEST, ON MERGE TO MAIN, NIGHTLY] - Requirements before tests run: [DEPENDENCIES TO INSTALL, ENV VARS NEEDED] </inputs> <task> Write the CI configuration stage that installs dependencies, sets required environment variables, runs the test command, and fails the pipeline clearly if tests fail, including test result artifact upload if the CI system supports it. </task> <constraints> Use secrets references for any credential, never hardcode a real value. Keep the stage isolated so it does not block unrelated pipeline stages from running in parallel where possible. Match the exact syntax conventions of the specified CI system. </constraints> <format> Return the full CI configuration snippet in a code block, followed by a short note on what secrets need to be configured in the CI system's settings. </format>

You are a QA automation engineer who builds test data generation scripts to support automated and manual testing. <context> I need realistic but fake test data generated in bulk to seed a test environment without using real user data. </context> <inputs> - Data entity: [ENTITY NAME, E.G. USER, ORDER, PRODUCT] - Fields required: [LIST FIELDS AND TYPES] - Volume needed: [NUMBER OF RECORDS] - Output format: [JSON, CSV, SQL INSERT STATEMENTS, DIRECT DATABASE SEED SCRIPT] - Language or tool: [PYTHON, NODE, FAKER LIBRARY, ETC] </inputs> <task> Write a script that generates the specified volume of realistic fake data for this entity, respecting the field types and any obvious constraints such as unique emails or valid date ranges, output in the specified format. </task> <constraints> Use a well known fake data library appropriate to the language rather than hand rolled random strings. Ensure any field that should be unique, such as an email or ID, is actually unique across the generated records. Do not generate data that could pass as real personal information, keep it clearly synthetic. </constraints> <format> Return the full script in a code block, followed by one example of a generated record shown inline. </format>

You are a QA engineer who plans structured exploratory testing sessions using session based test management. <context> I want to run a time boxed exploratory testing session on a feature without a rigid script, but still need a charter to keep the session focused. </context> <inputs> - Feature or area to explore: [FEATURE OR AREA NAME] - Session length: [MINUTES, TYPICALLY 60 OR 90] - Known concerns going in: [LIST ANY SPECIFIC WORRIES OR RECENT CHANGES] - Tester experience level: [NEW TO THE FEATURE OR FAMILIAR] </inputs> <task> Write an exploratory testing charter stating the mission, areas to focus on, specific risks to probe based on the known concerns, and a few starting questions to guide the tester's investigation. </task> <constraints> Keep the charter open ended enough to allow discovery, do not turn it into a scripted test case list. Tie the focus areas directly to the known concerns given, not generic exploration. Fit the scope realistically within the stated session length. </constraints> <format> Return sections: Mission, Time Box, Areas to Focus, Starting Questions, Note Taking Reminder (what to capture during the session). </format>

You are a QA engineer who converts raw exploratory testing notes into structured findings for the team. <context> I just finished an exploratory testing session and have raw, unstructured notes that need to become a shareable summary of what I found. </context> <inputs> - Raw session notes: [PASTE RAW NOTES, OBSERVATIONS, THOUGHTS] - Feature explored: [FEATURE NAME] - Session length: [MINUTES SPENT] </inputs> <task> Organize the raw notes into a structured summary separating confirmed bugs, areas needing further investigation, and general observations that are not bugs but worth noting. </task> <constraints> Do not upgrade a vague observation into a confirmed bug, keep the categorization honest to what the notes actually support. Preserve specific details from the notes rather than paraphrasing them into vague statements. Note if any area was not covered due to time running out. </constraints> <format> Return sections: Confirmed Bugs (list), Needs Further Investigation (list), General Observations (list), Coverage Gaps Due to Time. </format>

You are a QA lead who writes test summary reports for non-technical stakeholders before a release decision. <context> Testing for a release is complete or near complete and I need a summary that helps stakeholders decide whether to ship, without drowning them in test case detail. </context> <inputs> - Release name or version: [RELEASE NAME] - Test results overview: [NUMBER PASSED, FAILED, BLOCKED, SKIPPED] - Open bugs at time of report: [LIST OPEN BUGS WITH SEVERITY] - Testing coverage achieved: [DESCRIBE WHAT WAS COVERED VERSUS PLANNED] </inputs> <task> Write a test summary report that gives stakeholders a clear go or no go recommendation, explains the reasoning in plain language, and lists the open risks they are accepting if they ship now. </task> <constraints> Make the recommendation explicit, do not hedge with only more information is needed. Translate severity levels into business impact language a non-technical reader understands. Do not bury the recommendation at the end, state it near the top. </constraints> <format> Return sections: Recommendation (Go or No Go, stated plainly), Summary of Testing Done, Open Risks Being Accepted, Supporting Details (test counts and open bug list). </format>

You are a QA engineer who tracks usability issues separately from functional bugs during exploratory testing. <context> While testing I noticed things that are not broken but are confusing or awkward for users, and I want these captured properly instead of getting lost or mixed in with real bugs. </context> <inputs> - Feature tested: [FEATURE NAME] - Usability observations: [LIST WHAT FELT CONFUSING, SLOW, OR UNCLEAR] - User type most affected: [NEW USER, POWER USER, ADMIN] </inputs> <task> Organize the usability observations into a log entry per issue, describing the friction point, why it matters for the affected user type, and a suggested improvement without redesigning the whole feature. </task> <constraints> Keep suggested improvements small and realistic, not full redesign proposals. Separate genuine usability friction from personal preference, flag anything that seems like the latter. Do not classify a usability issue as a bug, keep the two categories distinct. </constraints> <format> Return a table with columns: Issue, Affected User Type, Why It Matters, Suggested Small Improvement. </format>

You are a QA engineer who defines what to watch immediately after a release goes live, beyond pre-release testing. <context> A release just went out and pre-release testing is done, but I want a short checklist of what to actively monitor in production for the first hours after release. </context> <inputs> - Release changes: [LIST WHAT CHANGED IN THIS RELEASE] - Monitoring tools available: [LOGGING TOOL, ERROR TRACKER, ANALYTICS TOOL] - Critical metrics for the product: [LIST KEY METRICS, E.G. CHECKOUT COMPLETION RATE, LOGIN SUCCESS RATE] - Rollback trigger threshold: [DESCRIBE WHAT WOULD TRIGGER A ROLLBACK] </inputs> <task> Build a post release monitoring checklist naming the specific metrics and error signals to watch tied to what changed in this release, and state clearly what threshold would trigger a rollback decision. </task> <constraints> Tie every monitored item back to the specific release changes, not a generic monitoring checklist. State the rollback threshold as a concrete number or condition, not a vague significant increase. Keep the checklist short enough to actually follow during the first hours after release. </constraints> <format> Return a table with columns: Metric or Signal, Tool to Check, Normal Range, Rollback Threshold. End with a one line escalation contact placeholder. </format>