30 AI Prompts for SDET Engineers: Test Cases, Bug Reports, Test Data and More (2026)
Every SDET who has used ChatGPT, Gemini, or GitHub Copilot for more than five minutes has hit the same wall: the tool is clearly capable of something useful, but the output is generic, shallow, or just wrong in a way that takes longer to fix than starting from scratch. The problem is almost never the AI — it is the prompt.
This guide is a curated, battle-tested library of AI prompts for SDET engineers that actually produce useful output. Not theoretical examples, not toy prompts — specific, copy-paste prompt patterns organised by the task you are actually trying to accomplish: test case generation, bug reports, test data, API testing, Playwright automation, performance testing, accessibility, and more.
Every prompt in this guide follows the same principle: give the AI context, constraints, and a specific output format, rather than an open-ended question. That single change — from vague question to structured prompt — is what separates output you can use immediately from output you have to rewrite entirely.
These AI prompts for SDET work across ChatGPT (GPT-4o), Google Gemini, Claude, and GitHub Copilot Chat. Where a prompt works differently across tools, that is noted explicitly. The focus keyword density, outbound authority links, and format follow QAtribe’s SEO and editorial standards — this is a reference post you will bookmark, not read once and forget.
How to Use This Prompt Library
Before jumping to the prompts, three principles that apply to every single one in this guide:
Principle 1: Replace the Placeholders
Every prompt uses square-bracket placeholders like [application name], [user story], or [tech stack]. These are not decoration — they are the specific context the AI needs to produce useful output instead of generic boilerplate. Skipping the placeholders and submitting the prompt as-is is the single most common reason AI output disappoints.
Principle 2: Iterate, Do Not Accept the First Output
The prompts in this guide are starting points, not finished deliverables. Treat the AI’s first response as a rough draft — review it, identify what is missing or wrong, and refine with a follow-up prompt. A good follow-up prompt pattern that works across all the categories below:
The output above is missing [specific gap]. Add [specific addition] and ensure the format stays consistent with what you already produced.
Principle 3: Always Review with Domain Knowledge
AI does not know your application, your users, or your team’s risk priorities. The prompts in this guide will get you 70-80% of the way to a usable output — the remaining 20-30% requires a QA engineer’s judgment about what actually matters for your specific context. Treating AI output as a first draft to review, not a finished product to ship, is the defining habit of a strong AI QA Engineer.
Category 1: Test Case Generation Prompts
Test case generation is where most SDETs first try AI assistance — and where most are disappointed by vague, shallow output. The prompts below are specifically structured to produce test cases with enough detail to actually execute, covering positive, negative, edge case, and boundary conditions without you having to manually specify each one.
Prompt 1: Generate Test Cases From a User Story
When to use: When you have a Jira ticket or user story and need a comprehensive first-pass test case set quickly.
You are a senior QA engineer with 10 years of experience in [domain, e.g. e-commerce / fintech / SaaS]. Here is a user story: [Paste the full user story or Jira ticket description here] Generate a comprehensive set of test cases covering: 1. Happy path / positive scenarios 2. Negative scenarios (invalid input, boundary violations) 3. Edge cases (empty states, maximum limits, special characters) 4. Security-relevant scenarios (if applicable) 5. UI/UX scenarios (if it involves a user interface) For each test case, provide: - Test Case ID (TC_001, TC_002, etc.) - Test Case Title (one clear sentence) - Preconditions - Test Steps (numbered) - Expected Result - Priority (High / Medium / Low) - Test Type (Functional / Negative / Edge Case / Security) Format the output as a table I can paste into Excel or a test management tool. Do not include any preamble or explanation — only the table.
Why this prompt works: It specifies the domain (which anchors the AI’s reasoning in relevant terminology), defines the exact test case structure you want, requests a format you can actually use, and explicitly excludes the AI’s tendency to pad responses with explanatory paragraphs.
Sample output structure:
TC_001 | Login with valid credentials | User exists in system | 1. Navigate to /login 2. Enter valid email 3. Enter valid password 4. Click Login | User redirected to dashboard | High | Functional TC_002 | Login with invalid password | User exists in system | 1. Navigate to /login 2. Enter valid email 3. Enter wrong password 4. Click Login | Error message displayed: "Invalid credentials" | High | Negative
Prompt 2: Generate Test Cases From an API Specification
When to use: When you have a Swagger/OpenAPI spec or endpoint documentation and need test coverage for the API layer before the UI is built.
You are a senior API QA engineer. Here is the API specification for [endpoint name]: Method: [GET / POST / PUT / DELETE / PATCH] URL: [endpoint URL] Request headers: [list required headers] Request body: [paste JSON schema or example request body] Response: [paste expected response schema] Authentication: [None / Bearer token / API key / OAuth] Generate test cases covering: 1. Successful response with valid payload (all required fields present) 2. Missing required fields (one field missing per test case) 3. Invalid data types for each field 4. Boundary values for numeric and string fields 5. Authentication failure scenarios 6. Large payload / performance boundary tests For each test case provide: - Test Case ID - Scenario description - Request payload (exact JSON) - Expected HTTP status code - Expected response body or key fields to validate - Tool to use: [Postman / REST Assured / Playwright APIRequestContext]
Pro tip: If your API uses OpenAPI 3.0, you can paste the entire YAML spec block for one endpoint directly into the prompt. The AI will parse the schema and generate test cases against it without you manually summarising each field.
Prompt 3: Generate Edge Case and Negative Test Cases Only
When to use: When the happy path test cases already exist and you want to specifically stress-test boundary and error conditions — the area most manual test case writers under-cover.
You are a QA engineer specialising in boundary value analysis and equivalence partitioning. Feature under test: [feature description] Input fields and their valid ranges: - [Field 1]: [type, min, max, format e.g. "Age: integer, 18-120"] - [Field 2]: [type, min, max, format] - [Field 3]: [type, constraints] Generate ONLY negative and edge case test cases. Do not include happy path scenarios. Cover: 1. Exact boundary values (min, max, min-1, max+1) 2. Empty and null inputs for each field 3. Special characters and SQL injection patterns for text fields 4. Whitespace-only inputs 5. Maximum length + 1 for string fields 6. Decimal precision edge cases for numeric fields 7. Future and past date extremes for date fields Output format: Test Case ID | Input | Expected behaviour | Validation type
Prompt 4: Expand an Existing Test Case Into Variants
When to use: When you have one good test case and want to quickly generate all the variants for different data combinations without writing each one manually.
Here is an existing test case: [Paste your existing test case] Generate 10 variants of this test case that cover different: - Input data combinations - User roles (if applicable: [list roles]) - Browser / device combinations (if applicable: [list targets]) - Data states (fresh user, returning user, user with existing data) Keep the test steps identical in structure — only vary the data and expected results. Format as a numbered list with: Variant # | Key difference | Input data | Expected result
Prompt 5: Generate a Test Case Matrix for Combinatorial Coverage
When to use: When a feature has multiple independent variables and you need to choose a smart subset of combinations without testing every possible permutation.
You are a QA engineer applying pairwise testing (all-pairs) methodology. Feature: [feature name] Variables and their values: - Variable 1 ([name]): [value A, value B, value C] - Variable 2 ([name]): [value A, value B] - Variable 3 ([name]): [value A, value B, value C] - Variable 4 ([name]): [value A, value B] Generate a pairwise test matrix that ensures every pair of values appears in at least one test case. Minimise the total number of test cases while maximising pairwise coverage. Output as a table: Test # | Var1 | Var2 | Var3 | Var4 | Notes
Category 2: Bug Report and Defect Documentation Prompts
Writing a good bug report is one of the most underrated skills in QA — and one of the areas where AI assistance can make the biggest practical difference to a team’s velocity, since poor bug reports waste developers’ time and lead to “cannot reproduce” rejections. These AI prompts for SDET engineers are specifically designed to produce structured, complete, reproducible defect reports.
Prompt 6: Write a Complete Bug Report From a Description
When to use: When you have observed a bug and want to produce a properly structured bug report quickly without forgetting any fields.
You are a senior QA engineer writing a formal defect report for [Jira / Azure DevOps / GitHub Issues]. Bug observed: [Describe what went wrong in plain language] Environment: [Browser/OS/Device, Application version, Test environment] User type: [Anonymous / Logged in / Admin / specific role] Write a complete bug report with: 1. Summary (one sentence, format: [Component] - [What happened] - [Impact]) 2. Severity: [Critical / High / Medium / Low] — justify this choice 3. Priority: [P1 / P2 / P3 / P4] 4. Steps to Reproduce (numbered, specific, reproducible) 5. Expected Result 6. Actual Result 7. Attachments needed (list what evidence would help, e.g. screenshot, network log, console error) 8. Root cause hypothesis (optional, mark clearly as hypothesis not confirmed cause) 9. Workaround (if any) 10. Labels/Tags to apply: [list your team's standard labels] Write in clear, professional English. No jargon. A developer who has never seen this feature should be able to reproduce it from your steps alone.
Prompt 7: Improve a Poorly Written Bug Report
When to use: When a junior tester or developer has submitted a vague bug report that will likely get “cannot reproduce” and you need to fix it before it gets that response.
Here is a poorly written bug report: [Paste the original bug report] Rewrite this bug report to be: 1. Specific — remove vague language like "sometimes" or "doesn't work" and replace with precise, observable behaviour 2. Reproducible — ensure steps are ordered, numbered, and complete 3. Accurate in severity — re-evaluate and justify the severity rating 4. Free of assumptions — separate observed facts from hypotheses 5. Developer-ready — a developer should be able to reproduce it without asking any questions Highlight what was changed and why. Output the improved version in full.
Prompt 8: Generate a Bug Report From Console Logs or Error Messages
When to use: When a test fails with a stack trace or console error and you want to quickly turn raw error output into a structured defect report.
Here is a console error / stack trace from a failing test: [Paste the full error message and stack trace] Test that produced this error: [test name and file] Application: [application name and version] Environment: [staging / UAT / local] Generate a bug report containing: 1. Summary (derived from the error message — be specific about the error type) 2. Component likely affected (inferred from the stack trace) 3. Steps to reproduce (based on the test that triggered this) 4. Expected vs actual behaviour 5. Technical details section with the cleaned-up stack trace 6. Suggested investigation starting point for the developer (based on the error pattern) If the error suggests a known pattern (e.g. NullPointerException, 401 Unauthorized, CORS issue), name it explicitly and explain what typically causes it.
Prompt 9: Write a Regression Bug Report
When to use: When a feature that previously worked is now broken, and you need to clearly document the regression context for the development team.
I have found a regression in [feature name]. Previously working behaviour (version [X.X.X] or date [DD/MM/YYYY]): [Describe what used to work correctly] Current broken behaviour (version [X.X.X] or date [DD/MM/YYYY]): [Describe what is now broken] Recent changes that may be related (if known): [list recent deployments, PRs, or config changes] Write a regression bug report that: 1. Clearly labels this as a REGRESSION in the summary 2. Includes a "Previously Working" section with the version/date reference 3. States the suspected change that introduced the regression (if known) 4. Flags the severity as at least High (since it was previously working) 5. Tags it with [Regression] label 6. Requests a root cause explanation from the developer in the description
Prompt 10: Summarise Multiple Related Bugs Into a Single Root Cause Report
When to use: When you have multiple bug reports that appear to share a common root cause and need to consolidate them into a single actionable defect for the developer.
Here are [N] related bug reports that appear to share a common root cause: Bug 1: [summary and key symptoms] Bug 2: [summary and key symptoms] Bug 3: [summary and key symptoms] Analyse these bugs and: 1. Identify the common pattern or shared root cause (hypothesis) 2. Write a single consolidated bug report that encompasses all three 3. List the individual bugs as "Related Issues" with their IDs 4. Recommend whether to close the individual bugs as duplicates or keep them open as separate tracking items 5. Suggest the component or code area most likely responsible based on the pattern Be clear about what is confirmed observation versus hypothesis in your analysis.
Category 3: Test Data Generation Prompts
Test data is the hidden bottleneck in most automation suites — tests break not because the code is wrong but because the data is missing, stale, or unrealistic. These prompts help generate realistic, varied, and edge-case-aware test data at scale without manually crafting each record.
Prompt 11: Generate Realistic Test Data for a User Registration Flow
When to use: When you need varied, realistic user records for testing registration, login, or profile-related flows without using real customer data.
Generate 20 realistic test user records for a [application type, e.g. e-commerce / banking / healthcare] application. Each record must include: - First name (varied — include Indian names, international names, names with special characters) - Last name - Email (valid format, varied domains, include edge cases: + in email, subdomain email) - Password (one that meets complexity requirements: [describe your password policy]) - Phone number (Indian mobile format: +91 XXXXX XXXXX — include landline format too) - Date of birth (varied age groups: 18-25, 26-40, 41-60, 60+ — ensure at least one boundary: exactly 18) - Address (varied Indian cities: Mumbai, Bangalore, Pune, Chennai, Delhi) - PAN number format (for fintech: AAAAA9999A format) - User type: [Regular / Premium / Admin — distribute across records] Also include 5 INVALID records designed to test validation: - Invalid email format - Age below 18 - Invalid phone format - Duplicate email (same as Record 1) - Empty required field Output as a JSON array I can import directly.
Prompt 12: Generate Test Data for an E-Commerce Order Flow
Generate test data for an e-commerce order management system covering these scenarios: 1. A standard successful order (single item, domestic delivery) 2. A multi-item order with mixed product types 3. An international order (shipping to [country]) 4. An order with a discount code applied 5. An order at the maximum item quantity limit ([X] items) 6. A partially fulfilled order (some items in stock, some backordered) 7. A cancelled order (mid-processing) 8. A refunded order (fully refunded) 9. A failed payment order 10. An order with a gift message and gift wrapping For each scenario provide: - Order ID (format: ORD-[6 digit number]) - Customer ID - Items array (product ID, name, quantity, unit price) - Order total - Discount code and value (where applicable) - Payment method - Delivery address - Order status - Expected state in the database after processing Output as JSON.
Prompt 13: Generate SQL Test Data Insert Statements
When to use: When you need to seed a test database with realistic data and want SQL INSERT statements you can run directly.
Generate SQL INSERT statements to seed test data for the following database schema: Table: [table name] Columns: - [column_name]: [data type, constraints e.g. NOT NULL, UNIQUE, FK reference] - [column_name]: [data type, constraints] - [column_name]: [data type, constraints] Database: [MySQL / PostgreSQL / SQL Server / Oracle] Requirements: 1. Generate 15 INSERT statements with realistic, varied data 2. Include at least 2 records that test boundary conditions for numeric fields 3. Include records with NULL values for nullable columns 4. Ensure referential integrity for any foreign key columns 5. Use realistic data for the [domain, e.g. healthcare / banking / retail] context 6. Add SQL comments explaining the purpose of notable records Format: Standard SQL INSERT INTO syntax compatible with [database type].
Prompt 14: Generate Test Data for API Load Testing
Generate a CSV file with [500] rows of test data for load testing the following API endpoint: Endpoint: POST [endpoint URL] Required fields: - [field name]: [type, format, valid range] - [field name]: [type, format, valid range] - [field name]: [type, format, valid range] Requirements: 1. All records must be valid (no intentionally invalid data — this is for performance testing, not validation testing) 2. Vary the data realistically — avoid identical records which would be cached and skew results 3. Distribute numeric values across the full valid range, not clustered at one end 4. For string fields, vary length between minimum and maximum allowed values 5. Include realistic text content for description fields (not Lorem Ipsum) Output as CSV with header row. I will import this into [JMeter / Gatling / k6 / Locust].
Prompt 15: Generate Test Data for Edge Cases in Date and Time Fields
Generate a comprehensive set of date and time test values for a [feature name] feature. Date field validation rules: - Format accepted: [DD/MM/YYYY or YYYY-MM-DD or MM/DD/YYYY] - Minimum date: [e.g. today's date, or a fixed date] - Maximum date: [e.g. +5 years from today, or a fixed date] - Time zone: [UTC / IST / user's local time zone] Generate test values covering: 1. Valid boundary dates (min date, max date, today) 2. Invalid boundary dates (min date - 1 day, max date + 1 day) 3. Leap year dates (29 February on a leap year and a non-leap year) 4. Month-end edge cases (31st of months with 30 days, 30th of February) 5. Time zone boundary cases (midnight UTC vs midnight IST = different dates) 6. Daylight saving transition dates (if relevant to [region]) 7. Invalid format inputs (wrong separator, wrong order, letters in date) 8. Null and empty date inputs For each value: Input | Valid or Invalid | Expected system behaviour
Category 4: Playwright Automation Prompts
These are the AI prompts for SDET engineers specifically using Playwright with TypeScript — the most common modern automation stack. Each prompt is designed to produce production-quality code, not toy examples, with proper error handling, locator strategy, and configuration.
Prompt 16: Generate a Playwright Page Object Model Class
You are a senior Playwright TypeScript automation engineer. Generate a Page Object Model class for the following page: Page name: [e.g. LoginPage] URL: [page URL or route] Key elements on this page: - [Element 1]: [type e.g. input field, button, dropdown] — purpose: [what it does] - [Element 2]: [type] — purpose: [what it does] - [Element 3]: [type] — purpose: [what it does] Requirements: 1. Use getByRole, getByLabel, or getByTestId locators (in that priority order) — avoid CSS selectors and XPath 2. Include a constructor that accepts a Playwright Page object 3. Include async methods for each key user action (e.g. login(), fillForm(), submitForm()) 4. Include assertion helper methods that use expect() rather than returning locators 5. Add JSDoc comments for each method 6. Follow the single responsibility principle — this class should only know about this page 7. TypeScript strict mode compatible Tech stack: Playwright [version], TypeScript, [Jest / Playwright Test runner]
Sample output the prompt produces:
import { Page, expect } from '@playwright/test';
export class LoginPage {
private readonly page: Page;
private readonly emailInput = () => this.page.getByLabel('Email address');
private readonly passwordInput = () => this.page.getByLabel('Password');
private readonly loginButton = () => this.page.getByRole('button', { name: 'Log in' });
private readonly errorMessage = () => this.page.getByRole('alert');
constructor(page: Page) {
this.page = page;
}
async navigate(): Promise<void> {
await this.page.goto('/login');
}
async login(email: string, password: string): Promise<void> {
await this.emailInput().fill(email);
await this.passwordInput().fill(password);
await this.loginButton().click();
}
async assertErrorMessageVisible(expectedText: string): Promise<void> {
await expect(this.errorMessage()).toBeVisible();
await expect(this.errorMessage()).toHaveText(expectedText);
}
}
Prompt 17: Generate a Playwright Test Spec From a Page Object
Here is an existing Page Object Model: [Paste your POM class here] Generate a complete Playwright test spec file that: 1. Imports the POM correctly 2. Uses test.describe blocks to group related tests 3. Uses beforeEach to navigate to the page and set up any required state 4. Covers these scenarios: [list your scenarios] 5. Uses data-driven testing with test.each for scenarios that differ only in input data 6. Includes at least one test for the happy path and at least two negative scenarios 7. Uses proper expect assertions — not just that elements exist, but that they have correct content 8. Handles async operations correctly — no floating promises 9. Adds a // Test ID comment referencing the test case IDs from your test management tool: [TC_001, TC_002, etc.] Do not import anything that is not needed. Keep the spec file clean and readable.
Prompt 18: Fix a Flaky Playwright Test
When to use: When a Playwright test is failing intermittently and you want AI help diagnosing the most likely cause before manually digging through trace files. See also: the QAtribe guide on debugging flaky tests with AI for the full workflow around this prompt type.
Here is a Playwright test that is failing intermittently (flaky): [Paste the test code] Failure symptom: [e.g. "element not found: .submit-button" / "timeout exceeded waiting for navigation" / "assertion failed: expected X but got Y"] Failure frequency: [e.g. "1 in 5 runs in CI, never locally"] Analyse this test and: 1. Identify the most likely root cause category: timing / locator fragility / test isolation / network dependency / resource contention 2. Explain specifically WHY this causes intermittent failure (not just what category it is) 3. Suggest the minimal, targeted fix — not a blanket "add a longer wait" 4. Rewrite the affected section of the test with the fix applied 5. Explain what the fix does and why it addresses the root cause Do not suggest adding retries as the primary fix. If a retry is appropriate, explain why it is appropriate here specifically.
Prompt 19: Generate Playwright API Testing Code
Generate a Playwright APIRequestContext test for the following API: Endpoint: [METHOD] [URL] Base URL: [base URL stored in playwright.config.ts as baseURL] Authentication: [None / Bearer token stored in env variable BEARER_TOKEN / API key in header X-API-Key] Request: Headers: [list required headers] Body: [paste example request body as JSON] Expected responses to test: 1. Status 200 with [describe expected response fields] 2. Status 400 when [describe invalid input scenario] 3. Status 401 when authentication is missing or invalid 4. Status 404 when [describe not found scenario] Requirements: 1. Use Playwright's request fixture, not axios or node-fetch 2. Store base URL and auth tokens in environment variables, not hardcoded 3. Use expect(response.status()).toBe() for status assertions 4. Parse and assert on specific response body fields using expect(responseBody.field).toBe() 5. Include a beforeAll block for any setup (e.g. creating prerequisite data) 6. Include an afterAll block to clean up any test data created Tech stack: Playwright Test, TypeScript
Prompt 20: Generate a Playwright Configuration File
Generate a production-ready playwright.config.ts for the following project: Project type: [Web UI testing / API testing / both] Environments: [local / staging / production — multiple environments] Browsers to test: [Chromium / Firefox / WebKit / all three] Test parallelism: [number of workers for CI, number for local] Test directory structure: [describe your folder structure] Reporting needs: [HTML report / JUnit XML for CI / JSON / Allure] CI platform: [GitHub Actions / GitLab CI / Jenkins] Base URL pattern: [how URLs differ between environments, e.g. env variable] Requirements: 1. Use environment variables for base URLs (process.env.BASE_URL with a sensible default) 2. Configure trace: 'retain-on-failure' and screenshot: 'only-on-failure' 3. Set appropriate timeouts (action, navigation, expect) for your stack 4. Configure retries: 2 for CI, 0 for local 5. Set up projects for each browser 6. Add a global setup file reference if auth state needs to be shared 7. Add comments explaining non-obvious configuration choices Output the complete playwright.config.ts file.
Category 5: REST API Testing Prompts
These prompts cover REST Assured (Java) and Postman/Newman test generation — the two most common API testing tools in the Indian SDET market. For the full REST Assured reference, see the QAtribe REST Assured Tutorial.
Prompt 21: Generate REST Assured Test Cases
You are a senior Java API automation engineer using REST Assured with TestNG. Generate REST Assured test cases for the following endpoint: Method: [GET / POST / PUT / DELETE / PATCH] URL: [full URL] Headers: [list required headers] Authentication: [Basic / Bearer token / OAuth 2.0 / API key] Request body (for POST/PUT/PATCH): [paste JSON] Expected response: [describe structure and key fields] Generate test cases covering: 1. Successful response validation (status code, response body fields, response time) 2. Schema validation using JSON Schema or POJO deserialization 3. Missing required field in request body 4. Invalid authentication 5. Invalid resource ID (404 scenario) 6. Method not allowed (405 scenario) Requirements: 1. Use RestAssured.given().when().then() fluent syntax 2. Store base URI in a @BeforeClass setup method 3. Use Hamcrest matchers for assertions (equalTo, hasKey, notNullValue) 4. Validate response time is below [500] milliseconds 5. Use TestNG annotations properly (@Test, @BeforeClass, @DataProvider) 6. Add meaningful test names to @Test annotation 7. Log request and response on failure using .log().ifValidationFails() Output the complete Java test class.
Prompt 22: Generate a Postman Collection From an API Description
Generate a Postman collection in JSON format for the following API:
API name: [API name]
Base URL: [base URL — use a Postman environment variable {{base_url}}]
Authentication: [describe auth method]
Endpoints to include:
1. [Method] [path] — [purpose]
2. [Method] [path] — [purpose]
3. [Method] [path] — [purpose]
For each endpoint include:
- A request with properly configured headers and body
- Pre-request script for any dynamic data (timestamps, UUIDs)
- Tests tab with pm.test() assertions for:
- Status code
- Response time below [value]ms
- Key response body fields
- Schema validation using tv4 or ajv if needed
- At least one negative test request (separate request with invalid input)
Output valid Postman Collection v2.1 JSON I can import directly.
Prompt 23: Generate an API Test Report Summary
When to use: When you have completed an API testing cycle and need to produce a clear, non-technical summary for project managers or stakeholders.
Here are the results of an API testing cycle for [project/sprint name]: Total endpoints tested: [number] Passing: [number] Failing: [number] Blocked: [number] Key defects found: 1. [Bug ID]: [brief description] 2. [Bug ID]: [brief description] 3. [Bug ID]: [brief description] Write an API testing summary report for a non-technical stakeholder audience that includes: 1. An executive summary (3-4 sentences: what was tested, outcome, risk level) 2. Test coverage summary (presented as a percentage, not raw numbers) 3. Critical findings section (bugs that block release) 4. Risk assessment (what risk remains if we release now) 5. Recommendation (go / no-go / go with conditions) Use plain language. Avoid technical jargon. Use bullet points, not paragraphs, for findings.
Category 6: Performance and Load Testing Prompts
Prompt 24: Generate a k6 Load Test Script
You are a performance testing engineer. Generate a k6 load test script for the following scenario: Application: [application name] Endpoint under test: [URL and method] Authentication: [describe how auth tokens are passed] Target load: [e.g. 100 concurrent users, ramping over 2 minutes] Test duration: [e.g. 5 minutes sustained load] Acceptable thresholds: - 95th percentile response time below [500]ms - Error rate below [1]% - Throughput above [50] requests/second Test scenario type: [smoke test / load test / stress test / spike test / soak test] Requirements: 1. Use k6's stages configuration for gradual ramp-up 2. Define thresholds in the options block 3. Include think time between requests using sleep() 4. Parameterise test data from a CSV file (provide the file structure expected) 5. Add custom metrics using new Counter / Trend / Rate where relevant 6. Log a summary of pass/fail at the end Output the complete k6 script in JavaScript.
Prompt 25: Analyse a Performance Test Result and Write Recommendations
Here are the results from a load test run: Tool used: [k6 / JMeter / Gatling / Locust] Test scenario: [describe the test] Duration: [duration] Virtual users: [number] Key metrics: - Average response time: [value]ms - 95th percentile: [value]ms - 99th percentile: [value]ms - Error rate: [value]% - Throughput: [value] requests/second - CPU at peak: [value]% - Memory at peak: [value]MB Errors observed: [list any errors and their frequency] Bottleneck indicators: [describe any slowdowns observed, e.g. slowdown after 80 users] Analyse these results and produce: 1. A performance assessment (pass / fail against the defined thresholds) 2. Identification of the bottleneck (if any) — with reasoning 3. Root cause hypotheses (ranked by likelihood) 4. Specific, actionable recommendations for the development team 5. Recommended next test to run based on these findings Format as a performance test report section suitable for a sprint review.
Category 7: Accessibility Testing Prompts
Prompt 26: Generate an Accessibility Test Checklist
Generate a WCAG 2.1 AA accessibility test checklist for the following UI component: Component: [e.g. Modal dialog / Navigation menu / Data table / Form / Image carousel] Framework: [React / Angular / Vue / plain HTML] Target users: [general public / enterprise users / government application] Generate a checklist covering: 1. Keyboard navigation (tab order, focus indicators, keyboard traps) 2. Screen reader compatibility (ARIA labels, roles, live regions) 3. Colour contrast (text on background, interactive elements, focus indicators) 4. Text alternatives (images, icons, decorative vs informative content) 5. Error identification (form errors, error messages, error recovery) 6. Responsive design (zoom to 200%, reflow at 320px width) For each item provide: - WCAG criterion reference (e.g. 1.4.3 Contrast Minimum) - How to test it (manual step or automated tool command) - Pass criteria - Common failure pattern to watch for Also suggest: which items can be automated with axe-core or Playwright's accessibility APIs, and which require manual testing.
Prompt 27: Generate Playwright Accessibility Test Code Using axe-core
Generate Playwright TypeScript tests for accessibility validation using @axe-core/playwright. Pages to test: 1. [Page 1 URL] — [key accessibility concerns for this page] 2. [Page 2 URL] — [key accessibility concerns for this page] Requirements: 1. Install and import @axe-core/playwright correctly 2. Run a full axe scan on each page after navigation 3. Filter violations by impact level: [critical / serious / moderate / minor — choose minimum level] 4. Assert that no violations above the threshold impact level exist 5. On failure, output a readable list of violations with: rule ID, impact, description, and the failing HTML element 6. Add a separate test that checks specific WCAG criteria only: [list specific criteria e.g. 1.4.3, 2.1.1] 7. Use beforeEach to navigate to the correct page for each test 8. Skip known false positives using axe.disableRules(['rule-id']) with a comment explaining why Output the complete test file with proper imports and configuration.
Category 8: Prompt Engineering and Workflow Prompts
This final category is about prompts that help you work better with AI tools themselves — refining outputs, reviewing automation code, and building reusable prompt templates for your team. These are the AI prompts for SDET engineers who want to go beyond individual task prompts and build a sustainable AI-assisted workflow.
Prompt 28: Review Automation Code for Quality Issues
You are a senior automation engineer reviewing code for a QA team. Review the following Playwright / REST Assured / Selenium code: [Paste code here] Evaluate it against these criteria and flag any issues: 1. Locator quality — are selectors fragile (CSS class names, XPath with indexes)? Suggest stronger alternatives. 2. Wait strategy — are there hardcoded sleeps or unnecessary explicit waits? 3. Test isolation — does this test depend on state from another test or leave state behind? 4. Assertion quality — are assertions specific enough to catch real regressions? 5. Code duplication — is there logic that should be in a shared helper or POM method? 6. Error handling — does a failure leave the browser in a bad state affecting subsequent tests? 7. Naming — are test and method names descriptive enough to understand without reading the code? 8. TypeScript/Java best practices — unused imports, any types, magic strings, missing return types For each issue found: - Severity: High / Medium / Low - Location: [line number or method name] - Issue description - Recommended fix with corrected code snippet Summarise: overall code quality score (1-10), top 3 priority fixes.
Prompt 29: Create a Reusable Prompt Template for Your Team
I want to create a reusable prompt template that my QA team can use repeatedly for [specific task, e.g. generating test cases from user stories]. Our team context: - Domain: [e.g. fintech / healthcare / e-commerce] - Tech stack: [test tools, languages, frameworks] - Test management tool: [Jira / TestRail / Azure DevOps] - Output format needed: [table / JSON / markdown / specific tool format] - Common mistakes in our current output: [describe what is usually wrong or missing] Design a prompt template with: 1. A clear system role instruction at the top 2. Clearly labelled placeholder fields (in [SQUARE BRACKETS]) for the variable parts 3. Fixed instructions that enforce our team standards (format, naming conventions, coverage areas) 4. An output format specification that matches our tool's import format 5. A note on how to iterate if the first output is incomplete Also suggest: how to store this template so the team can access it consistently (GitHub repo, Confluence page, Copilot instructions file).
Prompt 30: Generate a Test Strategy for an AI-Powered Feature
When to use: When your product ships a new AI feature and you need to think through the testing approach — which is fundamentally different from testing a traditional deterministic feature. For more depth on this topic, see the QAtribe AI QA Engineer guide.
Our product is shipping a new AI-powered feature: Feature description: [describe the feature — what it does, what AI model or API it uses] User-facing behaviour: [what the user sees and interacts with] AI component type: [LLM chatbot / recommendation engine / AI search / image analysis / other] Risk level: [high — financial/medical/legal output / medium — business decisions / low — content suggestions] Generate a comprehensive test strategy for this AI feature covering: 1. Functional testing layer - Traditional functional test cases (does the UI work) - API-layer tests for the AI integration endpoint 2. AI-specific evaluation layer - Hallucination detection test cases (specific examples for this feature) - Consistency testing (same input → consistent quality output across runs) - Edge case inputs (empty input, extremely long input, adversarial prompts) - Off-topic / out-of-scope input handling 3. Bias and fairness testing (if applicable to this feature) - Specific demographic variations to test - Expected behaviour for each 4. Regression approach - How to detect if a model update or prompt change degraded quality - Recommended evaluation metrics and thresholds 5. Post-launch monitoring - What to monitor in production - Alert thresholds - How to handle quality incidents Tool recommendations: [suggest specific tools from Promptfoo, LangSmith, custom harness based on the feature type] Output as a structured test strategy document with clear sections and numbered items.
Category 9: Mobile Testing Prompts
Mobile automation brings its own set of complexities — gesture interactions, device fragmentation, network conditions, and platform-specific behaviours. These AI prompts for SDET engineers working on mobile test automation cover Appium and Playwright mobile emulation.
Prompt 31: Generate Appium Test Cases for a Mobile Feature
You are a senior mobile automation engineer using Appium with [Java / Python / JavaScript] and [TestNG / pytest / Mocha]. Generate test cases for the following mobile feature: Feature: [feature name and description] Platform: [Android / iOS / both] App type: [Native / Hybrid / PWA] Minimum OS version: [e.g. Android 10+ / iOS 15+] Device matrix to cover: - [Device 1]: [screen size, OS version] - [Device 2]: [screen size, OS version] Test scenarios to cover: 1. Core functionality on both platforms 2. Orientation change (portrait to landscape and back) 3. App backgrounding and foregrounding mid-flow 4. Low memory simulation (if testable) 5. Network interruption mid-transaction 6. Deep link handling (if applicable) For each test case provide: - Test ID - Platform - Device/OS target - Preconditions (app state, logged in/out, network condition) - Steps (include specific gestures: tap, swipe, pinch, long press) - Expected result - Known platform differences between Android and iOS for this test Output as a structured table.
Prompt 32: Generate Mobile Gesture Automation Code
Generate Appium [Java / Python] code for the following mobile gesture interactions: App: [app name] Platform: [Android / iOS] Appium version: [2.x] Gestures needed: 1. Swipe left on a card carousel to navigate to next card 2. Pull-to-refresh on a scrollable list 3. Pinch-to-zoom on an image 4. Long press on a list item to trigger context menu 5. Scroll to bottom of a dynamically loading list For each gesture: - Use the W3C Actions API (not deprecated TouchAction) - Include the element locator strategy used - Add a wait after the gesture to confirm the result before asserting - Add a comment explaining what the gesture simulates from the user's perspective Also include: a reusable GestureHelper utility class that encapsulates each gesture as a static method so tests do not repeat the gesture code inline.
Prompt 33: Generate a Mobile Test Configuration Matrix
Generate a device and OS test configuration matrix for a mobile app release. App type: [Native Android and iOS / Hybrid / React Native / Flutter] Target markets: [India / US / Global] Release type: [Major feature release / Minor update / Hotfix] Constraints: - Testing budget allows for [N] device-OS combinations maximum - Must include at least [X]% of target market's device share Generate a matrix that: 1. Lists the recommended [N] device-OS combinations with justification for each 2. Categorises each as: P1 (must pass), P2 (should pass), P3 (nice to have) 3. Identifies which test cases from the test suite must run on every device vs. which are device-specific 4. Recommends which combinations to run on physical devices vs. emulators/simulators 5. Includes a "smoke test" subset of [5-10] critical tests to run across all devices Also recommend: a cloud device farm (BrowserStack / Sauce Labs / AWS Device Farm / Firebase Test Lab) configuration for the P1 combinations.
Category 10: Security Testing Prompts
Security testing is an area many SDETs avoid because it feels outside their domain — but basic security test cases are well within QA’s remit, especially for web applications handling user data. These prompts help generate security-focused test scenarios without requiring a dedicated penetration tester.
Prompt 34: Generate OWASP Top 10 Test Cases for a Web Feature
You are a QA engineer with basic web application security testing knowledge. Generate security test cases based on the OWASP Top 10 (2021) for the following feature: Feature: [feature description — e.g. user login, file upload, payment form] Application type: [B2C web app / admin panel / API / mobile app backend] Authentication method: [session cookies / JWT / OAuth 2.0] Data handled: [describe the type of user data this feature processes] For each applicable OWASP category generate: - OWASP category and number (e.g. A01:2021 Broken Access Control) - Specific test scenario for this feature - Test input or technique to use - Expected secure behaviour (what the application SHOULD do) - Tool suggestion (OWASP ZAP / Burp Suite Community / manual browser test) Focus on the top 5 most applicable OWASP categories for this specific feature type. Mark any test that requires specialised security tooling (Burp Suite / ZAP) vs. tests executable with Playwright or Postman. Note: These are functional security verification tests, not penetration tests. Flag if any scenario requires escalation to a dedicated security team.
Prompt 35: Generate Authentication and Authorisation Test Cases
Generate comprehensive authentication and authorisation test cases for: Application: [app name] Auth method: [username/password + OTP / OAuth 2.0 / SSO / API key / JWT] User roles defined: [list all roles and their permissions] Sensitive resources: [list endpoints or UI sections that require specific roles] Test cases needed for: Authentication: 1. Valid credentials → successful login 2. Invalid password → appropriate error (no account enumeration) 3. Account lockout after [N] failed attempts 4. Session expiry after [X] minutes of inactivity 5. Concurrent session handling (login from two devices) 6. Password reset flow security (token expiry, one-time use) 7. Logout clears session correctly (token invalidation) Authorisation: 1. Each role can access only their permitted resources 2. Direct URL access to restricted resource redirects to login 3. Role escalation is not possible via request manipulation 4. Horizontal privilege escalation test (User A cannot access User B's data) For each test case: Test ID | Scenario | Input | Expected Result | Risk if this fails
Prompt 36: Generate Input Validation Security Test Cases
Generate input validation and injection security test cases for: Form or API endpoint: [name and description] Input fields: [list each field, its type, and validation rules] Generate test cases for each field covering: SQL Injection: - Classic: ' OR '1'='1 - Comment injection: admin'-- - UNION-based probes (non-destructive) XSS (Cross-Site Scripting): - Reflected XSS: - Stored XSS (if this input is displayed back to other users) - Event handler injection: Path Traversal (for file upload/download features): - ../../../etc/passwd style inputs Command Injection (for features that execute system commands): - ; ls -la | whoami style inputs For each test input provide: - Input value (exact string to use) - Expected behaviour (blocked, sanitised, error message) - Severity if this vulnerability exists: Critical / High / Medium - How to verify: what to look for in response, browser console, or server logs Important: These are verification tests to confirm protections work — run these only on test environments you are authorised to test.
Category 11: CI/CD Integration Prompts
Getting automation tests to run reliably in a CI/CD pipeline is where most automation projects eventually hit friction. These prompts help generate the pipeline configuration, reporting, and failure-handling patterns that make CI integration robust.
Prompt 37: Generate a GitHub Actions Workflow for Playwright Tests
Generate a GitHub Actions workflow file for running Playwright tests with these requirements: Project: [project name] Test type: [UI tests / API tests / both] Browsers: [Chromium only / all three: Chromium, Firefox, WebKit] Trigger: [on push to main / on PR / scheduled nightly / manual trigger] Test sharding: [yes — N shards / no] Environments: [staging / production / dynamic PR environment] Notifications: [Slack / email / GitHub PR comment on failure] Artifact retention: [N days] Generate the complete .github/workflows/playwright.yml with: 1. Correct Node.js version and caching strategy for npm dependencies 2. Playwright browser installation step (npx playwright install --with-deps) 3. Environment variable injection from GitHub Secrets (BASE_URL, AUTH_TOKEN, etc.) 4. Test sharding configuration if required 5. Upload of test-results/ folder as artifact on failure 6. HTML report upload as artifact always 7. A summary step that posts pass/fail count as a PR comment 8. Proper job dependency (install → test → report) Add comments explaining any non-obvious configuration choices.
Prompt 38: Generate a Test Failure Triage Runbook
Generate a CI test failure triage runbook for the QA team. Test suite details: - Framework: [Playwright / Selenium / REST Assured] - CI platform: [GitHub Actions / GitLab CI / Jenkins] - Test categories: [UI / API / E2E / performance] - Common failure patterns historically: [list known recurring issues] The runbook should cover: 1. First response (within 15 minutes of a failure notification) - How to access the failure report - What to check first (logs, screenshots, trace files) - How to distinguish a real regression from a flaky test 2. Triage decision tree - If test fails on re-run → [process] - If test only fails in CI, not locally → [process] - If test fails on main branch → [escalation process] - If multiple unrelated tests fail simultaneously → [process] 3. Escalation criteria - When to escalate to the developer - When to escalate to the tech lead - When to block a release 4. Resolution documentation - How to document the root cause - How to track recurring flaky tests - When to quarantine a test vs fix it immediately Format as a numbered decision guide, not prose paragraphs.
Prompt 39: Generate a Test Report for a Sprint
Generate a sprint test execution report for [Sprint name/number]. Sprint dates: [start date] to [end date] Team: [QA team size and names] Application: [app name and version tested] Test execution data: - Total test cases planned: [number] - Executed: [number] - Passed: [number] - Failed: [number] - Blocked: [number] - Not executed: [number] Automation coverage: - Total automated: [number] - New tests automated this sprint: [number] - Automation pass rate: [percentage] Defects: - New defects raised: [number] - Critical: [number] | High: [number] | Medium: [number] | Low: [number] - Defects closed this sprint: [number] - Defects carried forward: [number] Write a sprint test report containing: 1. Executive summary (4-5 sentences) 2. Test coverage summary with pass/fail metrics as percentages 3. Automation health summary 4. Top 3 risk areas based on failures and open defects 5. Defect trend (improving / stable / deteriorating vs last sprint) 6. Release recommendation with rationale 7. Action items for next sprint Tone: professional, concise, suitable for sharing with project management and development leads.
Category 12: Test Review and Documentation Prompts
Prompt 40: Write a Test Plan for a New Feature
Write a test plan for the following new feature release: Feature: [feature name] Release date: [date] Team: QA Lead: [name] | QA Engineers: [names] | Dev Lead: [name] Dependencies: [list dependent systems, APIs, or teams] Feature description: [paste the feature spec or epic description] The test plan should include: 1. Scope - In scope: what will be tested - Out of scope: what will not be tested and why 2. Test approach - Test levels: unit / integration / system / UAT - Test types: functional / regression / performance / security / accessibility - Automation strategy: what will be automated, what will be manual 3. Entry criteria (conditions that must be met before testing begins) 4. Exit criteria (conditions that define testing as complete) 5. Test environment details - Environment names and URLs - Test data requirements - Third-party dependencies and mocking strategy 6. Risk and mitigation - Top 3 risks to quality - Mitigation plan for each 7. Schedule - Test activities and estimated effort per activity - Milestones 8. Defect management - Severity classification guide - Triage process - Go/no-go defect threshold Format: Professional test plan document. Use numbered sections. Plain English.
Prompt 41: Generate Exploratory Testing Charters
Generate exploratory testing charters for the following feature: Feature: [feature name and description] Time available for exploration: [e.g. 2 hours total, 4 sessions of 30 minutes each] Tester experience level: [junior / mid / senior] Areas of highest risk: [list areas the team is most concerned about] Generate [4] exploratory testing charters following the SBTM (Session-Based Test Management) format: Each charter should include: - Mission: What is being explored (one sentence) - Areas: Specific parts of the application to focus on - Duration: Recommended session length - Design and Execution notes: What techniques to use (tour, attack, scenario) - Oracles: How to recognise a problem (what "wrong" looks like for this area) - Data: What test data is needed - Notes: What to capture during the session Make each charter distinct — cover different risk areas across the four charters rather than repeating coverage.
Prompt 42: Document an Automation Framework
Generate technical documentation for the following test automation framework: Framework name: [name] Purpose: [what the framework tests] Tech stack: [language, test runner, assertion library, reporting tool] Folder structure: [Paste or describe your actual folder structure] Key architectural decisions: - [Decision 1 and reason] - [Decision 2 and reason] Generate documentation covering: 1. Overview (what the framework does, who maintains it, where the repo is) 2. Prerequisites and setup (step-by-step installation from a fresh machine) 3. Folder structure explanation (what goes where and why) 4. How to write a new test (step-by-step with a minimal example) 5. How to run tests locally (commands for different configurations) 6. How to run tests in CI (CI command and environment variable list) 7. Troubleshooting guide (top 5 common setup issues and solutions) 8. Contribution guide (naming conventions, PR process, code review checklist) Format: Markdown, suitable for a GitHub repository README.md or Confluence page.
Category 13: Prompt Refinement and Iteration Patterns
Knowing how to refine a prompt when the first output is not quite right is as important as having good starting prompts. These are the follow-up patterns that work most reliably when AI output from the prompts above needs adjustment.
Prompt 43: Add Coverage Missing From a Generated Test Set
Here are the test cases you generated previously: [Paste AI-generated test cases] I have reviewed them against the feature requirements and found the following gaps: 1. [Gap 1 — e.g. "No test for concurrent user access to the same resource"] 2. [Gap 2 — e.g. "Missing test for the session expiry scenario"] 3. [Gap 3 — e.g. "No edge case for maximum file size upload"] Add test cases to cover these specific gaps. Keep the same format and ID numbering (continue from TC_0XX). Do not duplicate any of the test cases already in the set above.
Prompt 44: Convert Manual Test Cases to Automation-Ready Format
Here are manual test cases written for human execution: [Paste manual test cases] Convert these to automation-ready specifications that an SDET can use to write Playwright / REST Assured / Appium code: For each test case: 1. Rewrite vague steps like "navigate to the page" as precise actions: "Click on navigation menu → Select 'Products' → Verify URL is /products" 2. Replace ambiguous assertions like "verify it works" with specific observable outcomes 3. Identify the locator strategy most appropriate for each element interaction 4. Flag any step that requires manual verification (cannot be automated) with a [MANUAL] tag 5. Flag any step requiring test data that must be pre-populated with a [TEST DATA REQUIRED] tag 6. Estimate automation complexity: Easy / Medium / Hard based on the interactions involved Output: Automation-ready test case specification in the same format as the input.
Prompt 45: Translate Test Cases Between Frameworks
Translate the following test code from [source framework] to [target framework]: Source framework: [e.g. Selenium Java / Cypress JavaScript / REST Assured] Target framework: [e.g. Playwright TypeScript / REST Assured Java / Playwright Python] Source code: [Paste the source test code] Requirements for the translation: 1. Use the target framework's idiomatic patterns — do not just translate syntax literally 2. Replace deprecated or inferior patterns with the target framework's best practices
[e.g. Replace Thread.sleep() with proper Playwright waitFor methods]
[e.g. Replace CSS selectors with getByRole/getByLabel where appropriate] 3. Preserve all assertions — do not simplify or remove any existing checks 4. Add a comment where a direct translation was not possible and a workaround was used 5. Use the target framework’s async/await pattern correctly (if applicable) Output: Complete translated test file, ready to run.
A Complete Day of Using AI Prompts for SDET Tasks
To make this guide practical rather than purely reference material, here is a realistic composite of how an SDET might use a selection of these AI prompts for SDET tasks across a full working day — from sprint planning through to a CI failure triage.
Morning: Sprint Planning and Test Case Generation
A new sprint starts with three user stories to test. Instead of spending the first hour manually writing test cases from scratch, the SDET uses Prompt 1 (test cases from user story) on each of the three stories, spending about 10 minutes per story on the prompt plus review. The AI generates a first-pass test case set; the SDET reviews against their domain knowledge, finds that two edge cases specific to the application’s payment gateway are missing, and adds them manually. Total time: 45 minutes instead of 2-3 hours.
Mid-Morning: API Test Generation
A backend developer ships a new API endpoint. The SDET uses Prompt 21 (REST Assured test cases) with the Swagger spec pasted directly into the prompt. The AI generates a complete Java test class covering the happy path, all error scenarios, and schema validation. The SDET reviews the generated code against the actual endpoint behaviour in the staging environment, catches one incorrect expected status code (the API returns 422 rather than the 400 the AI assumed), fixes it, and commits. Total time: 30 minutes including code review and commit.
Afternoon: Bug Report Writing
During exploratory testing, the SDET finds a genuine regression. Instead of spending 20 minutes writing the bug report from scratch, they use Prompt 6 (complete bug report) with the observed behaviour pasted in. The AI produces a structured, complete report with a clear summary, numbered reproduction steps, and a root cause hypothesis. The SDET reviews, corrects the severity (the AI rated it Medium; the SDET knows this feature is on the critical path for the release and upgrades to High), and files it in Jira. Total time: 8 minutes.
Late Afternoon: Flaky Test Triage
CI flags a flaky test that has been failing intermittently for a week. The SDET uses Prompt 18 (fix flaky Playwright test) with the test code and the failure symptom. The AI identifies the issue as a missing wait for an animation to complete before a click event is registered, provides the fix, and explains why it addresses the root cause rather than masking it. The SDET applies the fix, runs the test 20 times locally to verify, and pushes. Total time: 20 minutes.
End of Day: Test Report
Sprint demo is tomorrow. The SDET uses Prompt 39 (sprint test report) with the test execution numbers from their test management tool. The AI produces a structured sprint report in under a minute. The SDET reviews the risk areas section, updates the release recommendation based on two open High severity defects, and shares with the team. Total time: 10 minutes.
What This Day Demonstrates
None of the AI output in this composite day was used without review. None of it was accepted blindly. In every case, the SDET’s domain knowledge added something the AI could not — a missing edge case, a wrong severity, an incorrect assumption about the API. But in every case, the AI produced a solid, structured first draft that took minutes rather than the hour it would have taken to start from scratch. That 70-80% first-draft quality, consistently, across every type of QA task — that is what a well-maintained AI prompts for SDET library actually delivers in practice.
Glossary of Terms in This Guide
- Prompt — a natural-language instruction given to an AI tool to generate a specific output
- Placeholder — a [SQUARE BRACKET] field in a prompt template that you replace with your specific context before submitting
- System role — the “You are a [role]” instruction at the start of a prompt that sets the AI’s reasoning frame
- Negative instruction — a “do not” clause in a prompt that prevents the AI from including unwanted content
- Staged prompting — breaking a complex task into multiple sequential prompts rather than asking for everything at once
- LLM-as-judge — using an AI model to evaluate the output of another AI model against a quality criterion
- Prompt regression — the degradation of a prompt’s output quality after a model update or prompt change
- Prompt library — a shared, versioned collection of tested prompt templates used consistently across a team
- AI prompts for SDET — prompt patterns specifically designed for software development engineers in test, covering QA tasks like test case generation, bug reporting, and automation code production
- POM (Page Object Model) — a Playwright/Selenium design pattern that encapsulates page interactions in a dedicated class, separating test logic from element locators
How to Build a Prompt Library for Your Team
Individual prompts are useful. A shared, maintained prompt library that your entire QA team can access consistently is a force multiplier. Here is how to build one that actually gets used rather than sitting in a document nobody opens.
Step 1: Start With the Prompts That Solve Daily Pain Points
Do not try to build a comprehensive library from day one. Start with two or three prompts that save the most time on tasks people do every day — test case generation from user stories and bug report writing are almost always the highest-impact starting points. Get those right, get the team using them consistently, then expand.
Step 2: Store Prompts Where People Already Work
A Confluence page nobody navigates to is not a prompt library — it is a graveyard. Store your team’s prompt templates where people already spend their time:
- GitHub repository: A
/promptsfolder in your test automation repo with one markdown file per prompt category. Version-controlled, PR-reviewable, and accessible from the terminal. - Copilot instructions file: Embed frequently-used prompt patterns directly in your
.github/copilot-instructions.mdfile so they apply automatically in every Copilot session without anyone having to remember to load them. - VS Code snippets: Save frequently-used prompt skeletons as VS Code user snippets so they can be triggered with a tab shortcut directly in the editor.
Step 3: Version and Iterate
A prompt that works today may produce worse output after a model update, or may need refinement after your team finds it consistently misses a specific coverage area. Treat prompts like code — version them, track changes, and update them when you find improvements. A simple commit message convention (prompts: improve test case format for API endpoints) makes the library’s evolution traceable.
Step 4: Measure Output Quality, Not Prompt Usage
The metric that matters is not “how many prompts did we use” but “did the AI-assisted output require less rework than before?” Track this informally in retrospectives — if a prompt consistently produces output that needs significant editing, the prompt needs improving, not the person using it.
Common Mistakes When Using AI Prompts for Testing
Mistake 1: Accepting the First Output Without Review
AI-generated test cases frequently miss domain-specific edge cases that an experienced QA engineer would include automatically — specific regulatory requirements, known application quirks, data combinations that are unusual in a generic context but common in your specific user base. Always review against your domain knowledge before committing AI-generated test cases to your test suite.
Mistake 2: Prompts That Are Too Vague
The single biggest quality gap between useful and useless AI output for QA tasks is prompt specificity. “Write test cases for the login page” produces generic output. “Write test cases for the login page of a fintech application using SMS OTP as the second factor, covering the OTP expiry scenario, the resend OTP flow, and the maximum failed attempt lockout” produces output that is actually testable. Every minute spent making a prompt more specific saves three minutes of reviewing and editing output.
Mistake 3: Using AI for Judgment Calls Without Human Review
AI can generate test cases, but it cannot judge whether the priority distribution across those test cases is right for your specific release risk. It can generate a bug report, but it cannot judge whether the severity is calibrated correctly against your team’s risk threshold. Keep AI in the “draft and suggest” role, not the “decide and finalise” role, especially for anything that affects release decisions.
Mistake 4: Not Updating Prompts When Output Degrades
AI models update, and prompt-output quality can shift after a model update in either direction — sometimes better, sometimes worse. If a prompt that previously worked well starts producing noticeably different output, update the prompt rather than blaming the tool. A well-maintained prompt library accounts for this drift.
Mistake 5: Building Team Dependency on One Person’s Prompt Knowledge
If only one engineer on the team knows the good prompts and the rest use vague, default prompts, the efficiency gain is isolated rather than compounding. Building and sharing a team prompt library — as described in the section above — is the difference between individual productivity and team-level capability uplift.
Prompt Patterns That Work Across All Categories
Beyond the specific prompts above, here are the underlying structural patterns that make any AI prompts for SDET tasks more effective — regardless of which AI tool you are using or which testing task you are trying to accomplish.
Pattern 1: Role + Context + Constraints + Format
Every high-quality prompt in this guide follows this four-part structure:
- Role: “You are a senior QA engineer specialising in [domain]” — anchors the AI’s reasoning in the right expertise frame
- Context: The specific feature, endpoint, user story, or code you are working with — the more specific, the better
- Constraints: What must be included, what must be excluded, what conventions to follow
- Format: Exactly how the output should be structured — table, JSON, code, numbered list
A prompt missing any one of these four elements will produce noticeably worse output than one that includes all four.
Pattern 2: The Negative Instruction
Adding explicit “do not” instructions to a prompt dramatically reduces AI’s tendency to pad output with unwanted boilerplate. Common negative instructions that work well in QA prompts:
Do not include happy path scenarios — negative only. Do not add an introduction or explanation — output only. Do not suggest retries as a fix unless you explain why it is appropriate here. Do not use CSS class selectors — use getByRole or getByTestId only. Do not include placeholder Lorem Ipsum text — use realistic domain-specific data.
Pattern 3: Staged Prompting for Complex Tasks
For complex tasks — like generating an entire test framework or a comprehensive test strategy — break the prompt into stages rather than asking for everything at once. Stage 1 generates the structure/outline. Stage 2 fills in each section. Stage 3 reviews and refines. This consistently produces better output than a single mega-prompt, because the AI can focus on one layer of complexity at a time.
Pattern 4: Verification Prompt
After receiving any complex AI output, use this verification prompt to catch gaps before you commit the output:
Review the output you just produced and check it against the original requirements. List any requirements that are not fully met in the output. List any areas where the output makes assumptions not supported by the information provided. Do not add to or change the output — only identify gaps.
Frequently Asked Questions
Which AI tool produces the best output for QA tasks — ChatGPT, Gemini, or Claude?
For test case generation and bug reports, all three produce comparable quality when given well-structured prompts — the prompt quality matters far more than which tool you use. Where differences emerge: Claude tends to produce more cautious, nuanced output for evaluation and judgment tasks; ChatGPT GPT-4o tends to be strong at structured data formats like JSON and CSV; Gemini has advantages when your team uses Google Workspace (Docs, Sheets) since it integrates natively. For code generation specifically in a Playwright/TypeScript context, GitHub Copilot’s in-editor context awareness gives it a practical advantage over chat-based tools for the kinds of tasks in Category 4 of this guide.
Are these prompts safe to use with proprietary application data?
Check your organisation’s AI usage policy before pasting proprietary data — user stories, API specs, or database schemas — into any external AI tool. Most enterprise teams use one of three approaches: anonymise or redact sensitive fields before prompting, use an enterprise-tier AI tool with explicit data retention opt-out (GitHub Copilot Enterprise, Claude for Enterprise, ChatGPT Enterprise), or run a self-hosted model for sensitive data. The prompts in this guide work equally well with anonymised or synthetic data — you do not need to paste real production data to get useful output.
How should I handle it when AI generates test cases with incorrect expected results?
This is expected and normal — it is one of the reasons the “review before committing” principle applies to all AI output in QA. Incorrect expected results in AI-generated test cases usually happen because: the AI made an assumption about your application’s specific behaviour that does not match reality, the user story or spec you provided was ambiguous, or the AI generalised from common patterns that do not apply to your specific implementation. The fix is always a more specific prompt with the correct expected behaviour stated explicitly, not a longer timeout or a retry.
Can I use these prompts in GitHub Copilot Chat inside VS Code?
Yes — all prompts in this guide work in Copilot Chat. For the code-generation prompts (Categories 4 and 5), you get additional benefit from Copilot’s in-editor context: reference specific files using #file:path/to/file.ts in your prompt, and Copilot will use that file’s actual content as context rather than relying on what you paste manually. For the test case and bug report prompts (Categories 1 and 2), the chat interface works identically to any other AI chat tool.
How do I stop AI from generating test cases that already exist in my suite?
Add this instruction to any test case generation prompt: “Here are the test cases that already exist — do not duplicate them, and do not generate variants that are functionally identical even if the wording differs: [paste existing test case titles].” For large suites, paste the 10-15 most closely related existing tests rather than the entire suite — the AI does not need to see every test case to avoid obvious duplication.
Is prompt engineering a skill I need to add to my resume?
Not as a standalone item — “prompt engineering” as a job skill is already being absorbed into the broader AI QA Engineer skill set rather than remaining a distinct specialisation. What is worth calling out on your resume is the specific, measurable outcome of using AI-assisted workflows — the format shown in the QAtribe AI QA Engineer guide (quantified achievement bullets) is more compelling than listing “prompt engineering” as a skill.
External Resources
- OpenAI Prompt Engineering Guide — official best practices from OpenAI for structuring effective prompts
- Anthropic Prompt Engineering Overview — Claude-specific prompt engineering documentation
- Google Gemini Prompting Strategies — official Gemini prompting guidance
- GitHub Copilot Chat Prompt Engineering — specific guidance for prompting in VS Code
- Promptfoo — open-source tool for testing and evaluating AI prompts systematically
- Playwright APIRequestContext Documentation — reference for the Playwright API testing approach used in Category 4
- QAtribe: What Is an AI QA Engineer? — the companion career guide for SDETs transitioning into AI QA roles
- QAtribe: Debugging Flaky Tests With AI — the full workflow behind Prompt 18 in this guide
Conclusion
The 30 AI prompts for SDET engineers in this guide cover every major QA task category — from generating your first test case to reviewing existing automation code, from writing a bug report to designing a test strategy for an AI-powered feature. Used correctly, these prompts turn AI from a novelty into a genuine productivity multiplier.
But the prompts themselves are only half the story. The other half is the practice of using them consistently, iterating when output is wrong, sharing what works with your team, and keeping the library current as tools evolve. An AI prompts for SDET library that one person uses occasionally produces individual benefit. A library that an entire QA team uses systematically, maintains collaboratively, and improves continuously produces compounding team-level productivity gains that are visible in metrics — test case coverage rates, bug report quality, time-to-merge for automation PRs.
Start with two or three prompts from this guide on a real task this week. Refine them based on what the output gets wrong. Share what works with your team. That is the whole process — and it compounds faster than most people expect.
If you found this guide useful or have a prompt pattern that works well for a task not covered here, drop it in the comments below.
