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]

AI Prompt - Integration testing

AI Prompt (integration level)

Prompt text

“Propose integration test cases for how \[component A] interacts with \[component B/service]. Include setup data, API contracts, dependency assumptions, and validation points. Cover success, failure, and timeout scenarios.”

How to apply critical thinking

·         Understand the integration surface

·         What exact APIs/events/interfaces are used between A and B?

·         What are the guarantees on order, idempotency, and eventual consistency?

·         Generate test cases for each interaction

·         Happy path: component A calls B with valid data; B responds as expected.

·         Contract mismatch: missing fields, versioned schemas, optional vs required fields.

·         Failure modes: B returns 4xx/5xx, malformed response, partial data.

·         Timeouts/retries: B is slow or unreachable; how does A behave?

·         Data consistency: verify that side effects (DB writes, messages) are consistent across both components.

·         Questions on ambiguities

·         Who is the source of truth for shared fields?

·         Expected behavior when one side is upgraded and the other is not?

·         How long should A wait before giving up on B?

·         What test ideas might be missed

·         Race conditions when multiple A instances talk to B concurrently.

·         Integration behavior under partial outages (e.g., one region down).

·         Back-pressure or throttling scenarios across components.

Output template (integration testing)

Context: [component A, component B/service, integration style (REST, queue, db, event bus)]

Assumptions: [API version, auth mechanism, network reliability, contract stability]

Test Types: [integration]

Test Cases:

ID: [TC-IT-001]

Type: [integration]

Title: [e.g., "A saves order when B confirms payment"]

Preconditions/Setup: 

  - [Deploy A+B in test env]

  - [Seed DBs or queues]

  - [Configure stubs only for external systems, not between A and B]

Steps:

  1. [Trigger A via API/event]

  2. [A calls B as part of flow]

Variations:

  - [B returns success]

  - [B returns 4xx, 5xx]

  - [B times out]

Expected Results:

  - [A’s behavior: commit/rollback, messages emitted, logs, metrics]

Cleanup:

  - [Clear DB, queues, reset configs]

Coverage notes:

  - [Which integration paths and contracts are validated; untested paths]

Non-functionals:

  - [Latency expectations across A↔B, retry limits]

Data/fixtures:

  - [Shared IDs, domain objects, schema versions]

Environments:

  - [Integration env with A+B only; prod-like configs]

Ambiguity Questions:

- [Ownership of fields, error-handling strategy, retry/backoff policy]

Potential Missed Ideas:

- [Multi-instance interactions, failover, schema evolution tests]

AI Prompt - Unit Test case generation

AI Prompt (unit level)

Prompt text

“Generate unit test cases for \[function/module] in \[language/framework]. Include inputs, expected outputs, edge cases, and mocks/stubs needed. Cover error handling and boundary conditions.”

How to apply critical thinking

·         Clarify the contract

·         What are the exact inputs, outputs, and side effects?

·         What invariants must always hold true?

·         What are explicit vs. implicit preconditions (e.g., non-null, sorted arrays, valid IDs)?

·         Generate strong test cases for each feature

·         Nominal cases: typical valid inputs that represent common usage.

·         Boundaries: min/max values, empty collections, zero/one/many elements, off-by-one.

·         Error handling: invalid types, null/undefined, out-of-range, malformed data.

·         State-related: same input called multiple times (idempotency), caching, internal state changes.

·         Mocked dependencies: happy/failure paths from downstream functions, repositories, external services.

·         Questions on ambiguities

·         What should happen on unexpected input types or missing parameters?

·         Are there performance constraints (e.g., max list size) that should influence tests?

·         How should the function behave when its dependency returns partial/empty data?

·         What test ideas might be missed

·         Rare but realistic values (e.g., leap-year dates, large numbers, special characters).

·         Concurrency or re-entrancy (same function called from multiple threads).

·         Backwards compatibility behavior if this function replaces an older one.

Output template (unit testing)

Context: [function/module name, language/framework, key responsibility]

Assumptions: [input types, error-handling strategy, side-effect rules]

Test Types: [unit]

Test Cases:

ID: [TC-UT-001]

Type: [unit]

Title: [short name, e.g., "returns total for valid items"]

Preconditions/Setup: [instantiate class, configure dependency mocks/stubs, sample data]

Steps: 

  1. [Call function with specific inputs]

Variations: 

  - [Variation 1: boundary]

  - [Variation 2: invalid input]

  - [Variation 3: dependency failure via mock]

Expected Results: 

  - [Return value/assertions]

  - [Side-effects, e.g., "no DB call", "log written"]

Cleanup: [reset mocks, static state]

Coverage notes: [what paths are covered, branches not covered, known gaps]

Non-functionals: [micro-performance expectations if any, e.g., "completes < 5 ms"]

Data/fixtures: [inline literals, factory methods, builders]

Environments: [local dev, unit test runner, CI]

Ambiguity Questions:

- [Question 1 about unclear behavior]

- [Question 2 about edge case]

Potential Missed Ideas:

- [Suspicious area where tests might still be thin]

Best practices for test automation in agile software development

 Agile software development is a highly iterative and collaborative approach to software development that emphasizes flexibility and adaptability. Test automation can help agile teams to improve the speed and efficiency of their testing process, but it is important to use best practices to ensure success. In this blog post, we will explore the best practices for test automation in agile software development.

1. Plan and prioritize test automation: Before starting test automation, it is important to plan and prioritize which tests to automate. Agile teams should focus on automating tests that provide the most value, such as high-risk areas of the application or frequently executed test cases.

2. Collaborate and communicate: Test automation should be a collaborative effort between developers, testers, and other stakeholders. Collaboration and communication are critical to ensure that all team members understand the scope and objectives of the testing effort.

3. Use the right tools: Choosing the right test automation tools is essential for success. Agile teams should select tools that are easy to use, provide good documentation and support, and integrate well with their development environment.

4. Build a reusable automation framework: A reusable automation framework can help reduce the time and effort required for test automation. Agile teams should focus on building a flexible and modular framework that can be easily customized for different projects.

5. Use continuous integration and delivery (CI/CD): Integrating test automation with CI/CD can help automate the testing process and ensure that all code changes are tested automatically. This reduces the time and effort required for testing and ensures that the software is always in a releasable state.

6. Use data-driven testing: Data-driven testing can help increase the coverage of tests and ensure that they are more comprehensive. Agile teams should use a set of test data to execute a single test script, reducing the number of scripts required for testing.

7. Test early and often: Testing early and often is critical to the success of test automation in agile software development. Agile teams should ensure that tests are run continuously throughout the development process to catch issues early and reduce the risk of costly bugs later on.

In conclusion, test automation can be a powerful tool for improving the speed and efficiency of testing in agile software development. By following best practices such as planning and prioritizing test automation, collaborating and communicating, using the right tools, building a reusable automation framework, using CI/CD, using data-driven testing, and testing early and often, agile teams can ensure success and deliver high-quality software to their customers.