AI Prompt - Performance or Load Testing

Prompt (performance level)

Prompt text

“Draft performance and load test scenarios for \[service/endpoint]. Specify SLAs/SLOs, target RPS, concurrency patterns, payload sizes, ramp-up, soak, spike, and metrics to collect (latency percentiles, errors, saturation).”

How to apply critical thinking

·         Clarify performance requirements

·         SLAs (e.g., p95 < 300 ms) and SLOs (e.g., 99.9% of requests under 500 ms).

·         Expected peak vs normal traffic, growth projections.

·         Generate performance scenarios

·         Baseline: light load to validate harness and get reference metrics.

·         Load: sustained target RPS with realistic traffic mix.

·         Stress/spike: sudden surges above normal to find breaking points.

·         Soak: long-running tests to detect leaks, slow degradation.

·         Concurrency: many simultaneous users, with realistic think times.

·         Questions on ambiguities

·         What’s the exact definition of “failure” for this service?

·         Which resources are most constrained (CPU, memory, DB connections, network)?

·         Are there autoscaling policies or rate limits that influence scenarios?

·         What test ideas might be missed

·         Multi-tenant contention: one tenant starving others.

·         Thundering herd effects after outages or cache flushes.

·         Performance in non-happy paths (errors, retries, timeouts).

Output template (performance/load testing)

Context: [service/endpoint, architecture (monolith/microservice), criticality level]

Assumptions: [SLA/SLO targets, expected traffic patterns, caching, autoscaling]

Test Types: [performance, load, stress, soak]

Test Cases:

ID: [TC-PERF-001]

Type: [performance/load]

Title: [e.g., "Sustained load at target RPS"]

Preconditions/Setup:

  - [Prod-like environment, data size, configs]

  - [Monitoring/observability in place]

Steps:

  1. [Configure load tool with target RPS, concurrency, payload mix]

  2. [Run test for defined duration]

Variations:

  - [Baseline low load]

  - [Target steady-state load]

  - [Spike from low to 2x/3x target]

  - [Soak at target for N hours]

  - [Different payload sizes and request mixes]

Expected Results:

  - [Latency percentiles within SLO]

  - [Error rate within acceptable limits]

  - [Resource utilization in safe bounds, no leaks]

Cleanup:

  - [Reset environment, clear queues/caches, roll back configs if changed]

Coverage notes:

  - [Which scenarios/traffic patterns are validated; untested extremes]

Non-functionals:

  - [Capacity headroom, resiliency under stress, autoscaling behavior]

Data/fixtures:

  - [Realistic datasets, representative payload samples]

Environments:

  - [Dedicated perf env, or carefully controlled prod-like setup]

Ambiguity Questions:

- [Exact SLOs, business impact of degradation, allowed mitigation strategies]

Potential Missed Ideas:

- [Downstream dependency limits, batch jobs overlapping with peak traffic, cold-start behavior]

AI Prompt - End to End Testing

AI Prompt (E2E level)

Prompt text

“Outline E2E test flows for user goal \[describe]. Include start state, navigation steps, data setup/cleanup, cross-browser/device considerations, and success/failure assertions.”

How to apply critical thinking

·         Think in user journeys, not screens

·         What represents a complete success for this goal from the user’s point of view?

·         What critical checkpoints must be true across multiple systems?

·         Generate E2E flows

·         Primary journey: start → navigate → perform actions → see confirmation.

·         Alternative flows: different entry points (deep links, notifications).

·         Failure flows: invalid input, backend failure, partial completion, recovery.

·         Cross-system checks: UI, API, DB, emails/notifications, logs.

·         Questions on ambiguities

·         Which parts are okay to mock vs must be real?

·         What’s the acceptable flakiness risk vs coverage (how many browsers/regions)?

·         Which 2–3 E2E flows are truly business-critical?

·         What test ideas might be missed

·         Long-running flows (multi-session, multi-day tasks).

·         E2E behavior across releases (backwards compatibility).

·         User switching devices mid-flow.

Output template (E2E testing)

Context: [user goal, e.g., "complete checkout with discount"], systems involved

Assumptions: [data seeding approach, real vs mocked dependencies, browsers/devices]

Test Types: [E2E, regression]

Test Cases:

ID: [TC-E2E-001]

Type: [E2E]

Title: [e.g., "User completes checkout with valid card"]

Preconditions/Setup:

  - [User account state, inventory, promo codes]

  - [Email/SMS delivery system configured]

Steps:

  1. [User logs in/registers]

  2. [Adds item to cart]

  3. [Applies promo]

  4. [Completes payment]

  5. [Views confirmation page/email]

Variations:

  - [Different payment methods, shipping options]

  - [Abandoned cart then resume]

  - [Failed payment then retry]

  - [Different browser/device combos]

Expected Results:

  - [UI confirmations, order in DB, payment captured, notifications sent]

Cleanup:

  - [Cancel/refund orders, restock inventory, clean test data]

Coverage notes:

  - [Critical path coverage, dependencies involved, known gaps and reasons]

Non-functionals:

  - [Latency of end-to-end flow, robustness under typical load]

Data/fixtures:

  - [Seed scripts, test accounts, cards, promo codes]

Environments:

  - [Staging/prod-parity with all integrated services]

Ambiguity Questions:

- [What is in-scope E2E vs already covered by integration tests?]

Potential Missed Ideas:

- [Cross-region flows, multi-tenant behavior, rollback/compensation flows]

AI Prompt - Functional UI Testing

AI Prompt (UI level)

Prompt text

“List UI test cases for \[page/feature]. Include happy paths, form validations, accessibility focus/keyboard/ARIA, error states, responsive breakpoints, and localization if applicable.”

How to apply critical thinking

·         Understand the user goal

·         What is the primary job of the page/feature?

·         What are the critical user journeys and failure modes?

·         Generate test cases

·         Happy paths: user completes the main task with valid inputs on supported devices/browsers.

·         Validation: client-side + server-side checks; inline vs global errors.

·         Accessibility: keyboard-only navigation, screen reader semantics, focus management, ARIA attributes.

·         Responsiveness: layout/behavior at different breakpoints and orientations.

·         Localization: long translations, RTL layouts, number/date formats.

·         Questions on ambiguities

·         Which browsers/devices and assistive technologies are in scope?

·         What is the expected behavior for validation error prioritization?

·         How should error messages be phrased (tone, length, localization)?

·         What test ideas might be missed

·         Interruptions (network flaky, modal dialogs, session timeout).

·         Browser autofill, password managers, copy-paste behaviors.

·         Color contrast changes in dark/light modes.

Output template (UI/functional testing)

Context: [page/feature name, platform (web/mobile), key user goals]

Assumptions: [supported browsers/devices, accessibility level (e.g., WCAG 2.1 AA), feature flags]

Test Types: [UI, functional, accessibility]

Test Cases:

ID: [TC-UI-001]

Type: [UI/functional]

Title: [e.g., "User submits valid signup form"]

Preconditions/Setup:

  - [User state (logged out/in), necessary data]

  - [Screen resolution, theme (light/dark)]

Steps:

  1. [Navigate to page]

  2. [Fill form fields]

  3. [Submit]

Variations:

  - [All required fields valid]

  - [Each field invalid individually]

  - [Keyboard-only navigation]

  - [Screen reader focus order]

  - [Different breakpoints: mobile/tablet/desktop]

  - [Different languages/locales]

Expected Results:

  - [UI state: success banner, redirect, error messages]

  - [Focus placement, ARIA attributes, role announcements]

Cleanup:

  - [Delete created user/data, reset UI state]

Coverage notes:

  - [Covered form paths, validations, accessibility checks, responsive states]

Non-functionals:

  - [Perceived performance, loading indicators, smooth transitions]

Data/fixtures:

  - [Test accounts, localized strings, feature flags]

Environments:

  - [Staging with prod-like assets and CDN]

Ambiguity Questions:

- [Accessibility expectations, supported locales, auto-save behavior]

Potential Missed Ideas:

- [Offline/low-bandwidth, browser extensions, system zoom/high-contrast modes]

AI Prompt - API Testing

Prompt (API level)

Prompt text

“Create API test cases for endpoint \[METHOD /path]. List preconditions, request variations (valid/invalid/missing/edge), auth cases, rate limits, pagination, idempotency, and expected status codes/payloads.”

How to apply critical thinking

·         Understand the API contract

·         Request/response schemas, required vs optional fields, business rules.

·         Authentication/authorization rules per role/tenant.

·         Generate comprehensive test cases

·         Valid requests: minimal valid, full valid, typical real-world payloads.

·         Invalid/malformed: missing required fields, wrong types, extra fields, oversized payloads.

·         Auth: no token, expired token, wrong roles, different tenants.

·         Rate/pagination/idempotency: hitting rate limits, page boundaries, repeating same request.

·         Questions on ambiguities

·         What is considered a client error vs server error?

·         How precisely does pagination behave when data changes between calls?

·         Are error codes standardized across APIs?

·         What test ideas might be missed

·         Security aspects (injection, sensitive data leakage, error message detail).

·         Backwards compatibility when fields are added/removed.

·         Localization of messages in error payloads (if applicable).

Output template (API testing)

Context: [HTTP method, path, domain area (e.g., "POST /orders")]

Assumptions: [auth mechanism, versioning strategy, content type, rate limits]

Test Types: [API, security (as applicable)]

Test Cases:

ID: [TC-API-001]

Type: [API]

Title: [e.g., "Create order with minimal valid payload"]

Preconditions/Setup:

  - [Existing users, auth token, seed data]

  - [Feature flags on/off]

Steps:

  1. [Send request with defined payload/headers/query params]

Variations:

  - [Valid minimal]

  - [Valid full]

  - [Invalid type]

  - [Missing required field]

  - [Oversized payload]

  - [Unauthenticated / unauthorized]

  - [High-rate sequence to trigger rate limit]

Expected Results:

  - [Status codes per variation]

  - [Response payload, headers]

  - [Side effects, e.g., DB records, events]

Cleanup:

  - [Delete created entities, reset quotas if needed]

Coverage notes:

  - [Covered status codes, auth paths, pagination, idempotency]

Non-functionals:

  - [Latency SLAs, payload size constraints, security checks]

Data/fixtures:

  - [Sample JWTs, user roles, example payloads]

Environments:

  - [API test env with prod-like gateway, WAF rules if possible]

Ambiguity Questions:

- [Unclear edge behaviors on pagination, updates during reads, error code mapping]

Potential Missed Ideas:

- [Negative security tests, content-negotiation, multi-tenant isolation]