Write a test plan

A test plan says what you will test, how, with what, and when you will call it done. A page or two is enough. Its value is in the decisions it forces before you start, and in giving everyone the same answer to "is it tested?"

What goes in one

Section	Answers
Scope	What is being tested, and what is deliberately not
Approach	Which kinds of test, at what depth
Environment	Where the tests run, with which accounts and data
Tools	What sends the requests and records the results
Entry and exit criteria	When testing can start, and when it is finished
Risks	What could go wrong with the testing itself
Deliverables	What exists at the end: collections, reports, a bug list

How to write one in an hour

1. List the endpoints. From the API's documentation or its OpenAPI file. ApiWorkbench can import an OpenAPI file as a collection, which gives you the list and a request for each.

2. Rank them. Mark each high, medium or low using the two questions from Fundamentals: how likely to break, how costly if it does.

3. Choose the kinds of test for each rank. High: functional, negative, auth, workflow, load. Medium: functional and negative. Low: a smoke test.

4. Write down what is out of scope, and why. This protects you later.

5. Fix the environment and the data. Which address, which test accounts, how test data is created and cleaned up.

6. Set the exit criteria as things that can be checked, not feelings.

Template

Copy this and fill it in.

# Test plan: <API name> <version>

Author: <name>      Date: <date>      Status: Draft | Agreed

## 1. Scope
In scope:
- <endpoint or feature>
Out of scope:
- <endpoint or feature>, because <reason>

## 2. Approach
| Area | Priority | Kinds of test |
|------|----------|---------------|
|      |          |               |

## 3. Environment and data
- Base URL:
- Accounts:
- Test data: created by <how>, removed by <how>
- Dependencies mocked: <which, and with what>

## 4. Tools
- Requests and tests:
- Mock server:
- Automation:
- Bug tracker:

## 5. Entry criteria
- [ ] <what must be true before testing starts>

## 6. Exit criteria
- [ ] <what must be true to call testing done>

## 7. Risks
| Risk | Effect | What we will do |
|------|--------|-----------------|
|      |        |                 |

## 8. Deliverables
- <collection, report, bug list>

A filled-in example: the Shop API

Written for the Shop API sample.

# Test plan: Shop API (sample) v1

## 1. Scope
In scope:
- Sign-in: POST /auth/login, GET /me
- Catalog: GET /products, GET /products/:id
- Orders: POST /orders, GET /orders/:id, DELETE /orders/:id
Out of scope:
- Payment: handled by another service, not in this API
- The web front end: tested separately

## 2. Approach
| Area    | Priority | Kinds of test                                    |
|---------|----------|--------------------------------------------------|
| Sign-in | High     | Functional, negative, auth                       |
| Orders  | High     | Functional, negative, boundary, auth, workflow, load |
| Catalog | Medium   | Functional, negative                             |

## 3. Environment and data
- Base URL: http://localhost:4020 (Mock Studio), later staging
- Accounts: ada@example.com (test account only)
- Test data: each run creates its own order and cancels it
- Dependencies mocked: the whole API, with Mock Studio

## 4. Tools
- Requests and tests: ApiWorkbench, collection "Shop API (sample)"
- Mock server: Mock Studio, project "Shop API (sample)"
- Automation: apiworkbench-cli in CI, JUnit report
- Bug tracker: the project's issue tracker

## 5. Entry criteria
- [ ] The mock starts and GET /products answers 200
- [ ] The collection is imported and baseUrl is set

## 6. Exit criteria
- [ ] Every in-scope endpoint has a passing happy-path test
- [ ] Every protected endpoint has a "no token" test that gets 401
- [ ] The order quantity limit is tested at 10 and at 11
- [ ] The full collection passes three runs in a row
- [ ] The checkout flow runs with 5 users and no errors
- [ ] No open bug of high severity

## 7. Risks
| Risk                                   | Effect               | What we will do                      |
|----------------------------------------|----------------------|--------------------------------------|
| The mock differs from the real API     | False confidence     | Re-run the suite against staging     |
| The mock does not store data           | Cannot test state    | State tests wait for staging         |

## 8. Deliverables
- The ApiWorkbench collection, exported and committed
- The JUnit report from the final run
- A list of bugs found

Keeping it honest

• Exit criteria must be checkable. "Well tested" is not. "Every protected endpoint has a no-token test" is.
• Write down what you skipped. Untested areas that nobody knows about are the dangerous ones.
• Change the plan when the facts change, and say so. A plan nobody updates is ignored.
• Keep it short. If it is longer than two pages, nobody will read it.

Next steps

• Write test cases: turn the plan into scenarios
• Checklists