Review and Stretch Goals

You've finished the capstone — or at least taken a serious first pass. This lesson is the part most courses skip and the part that matters most: a structured review of your own work, a set of stretch goals to push the suite further, and concrete pointers for what to learn next. Treat the checklist below as a rubric: tick what you've genuinely produced, leave blank what you skipped, and use the gaps to plan a second pass.

Self-assessment checklist

Run through every item. Be honest with yourself — the people who get the most out of this kind of work are the ones who notice their own gaps without flinching.

Strategy and structure

• ☐ Strategy document exists and fits on one page.
• ☐ Scope is explicit: what's covered, what's deliberately out.
• ☐ Approach explains the order of work and the rationale.
• ☐ Tools are named (one per category, not five overlapping).
• ☐ Risks are listed with mitigations, not just hand-waved.

Permission matrix

• ☐ Every role × every endpoint covered.
• ☐ "Owner vs other user" rows present where relevant (the IDOR catchers).
• ☐ Anonymous (guest) gets 401 not 403 on protected endpoints.
• ☐ Admin doesn't quietly inherit user-only operations (e.g. PUT on someone's booking).
• ☐ At least three "should be 403" cells the matrix surfaced that I'd otherwise have missed.

Test inventory

• ☐ At least 50 cases.
• ☐ Distribution roughly matches the brief (functional ~20, auth ~10, negative ~10, edge ~5, pagination ~5).
• ☐ Every case has: ID, endpoint, request shape, expected status, expected body assertion, preconditions.
• ☐ Cases are concrete enough that another QA could execute them without follow-up questions.
• ☐ Edge cases include double booking, past dates, overlapping dates.

Auth and bookings deep dives

• ☐ Auth covers register / login / refresh / wrong-password / wrong-role / expired / tampered token.
• ☐ Wrong-password and non-existent-email return the same 401 (no user enumeration).
• ☐ Refresh token rotation is tested (used token shouldn't work twice).
• ☐ Booking suite covers create, read, update, cancel — all four, all scoped properly.
• ☐ Booking suite includes attempts by non-owners (who should be denied).
• ☐ Booking validation: missing fields, invalid date format, from > to.

Schemas

• ☐ JSON Schema written for POST /bookings 201 response.
• ☐ JSON Schema written for GET /hotels/:id 200 response.
• ☐ Both schemas mark required fields explicitly.
• ☐ Both include additionalProperties: false.
• ☐ Date and email fields use format: date-time / format: date / format: email.

Smoke list

• ☐ Exactly 10 commands.
• ☐ All run anonymously or with a single test account.
• ☐ Each entry has the curl command and the expected status.
• ☐ Whole list runs in under 30 seconds.
• ☐ No mutating operations in the production smoke set.

If you scored 25/30 or higher, the capstone is solid. If you're at 15-24, identify the cluster you missed and do a focused second pass on that area. Below 15, treat it as a sign to revisit specific chapters — usually 4 (request patterns) and 8 (strategy) are the most under-attended.

Reflection questions

Sit with each of these for a minute or two. The answers tend to surface what you've actually learned versus what you've just read.

• What surprised you? Some part of building this suite went a different direction than you expected. What and why?
• What did you skip — and would you skip it again on a real project? Performance? Security? Contract tests? Justify the choice.
• Where would the suite be most likely to give a false green? Identify the bug class your current tests can't catch. That's your next investment.
• If you could automate one thing first, what would it be? The smoke list, the auth suite, or the booking flow are usually highest-ROI starters.
• What would you tell a teammate just starting this? The advice you'd give surfaces what you found hardest.

Stretch goals

If you finished early — or want to push the work further — pick one of these. Each adds a real capability that maps to something you'd do in a job.

1. Automate the smoke tests

Wrap the 10 curl commands in a bash script (or Python script with requests). Each command runs, status is captured, the script exits non-zero if any check fails. Add a final summary line: "9/10 passed; failed: TC-S-007."

A good first automation. Roughly 50 lines of code. Wire it into your CI as a post-deploy step.

2. Add GraphQL coverage

Imagine BookItNow exposes /graphql alongside the REST API, supporting hotel(id) and bookings queries. Sketch:

• A query that fetches a hotel with its rooms in one call.
• The same query unauthenticated — what's the expected error structure?
• Three negative cases: invalid id, unknown field, wrong argument type.
• A mutation createBooking parameterised with variables.

Compare the same booking flow in REST vs GraphQL. Note where the test shapes differ.

3. Build a Pact contract

The booking client (a frontend) consumes the booking API. Sketch a Pact contract from the consumer's perspective:

• One interaction for GET /bookings/:id returning the four fields the frontend uses.
• Use like() for string fields, exact-match for enums, regex for the createdAt ISO 8601 timestamp.
• Imagine the provider renames total to totalCost. Predict whether your contract catches it.

You don't need to actually run Pact — sketching the file in JSON is enough to confirm you understand it.

4. Performance scenarios

Write a short load-test plan:

• Scenario: 10 simultaneous booking attempts against the same room.
• Expected: one 201, nine 409s — or whatever the API's documented behaviour says.
• Scenario: 100 concurrent GET /hotels calls. Expected: all 200, p95 under 800ms.
• Scenario: 30 logins per second sustained for 1 minute.

If you want to take it all the way, the plan can be implemented in k6 or Locust in a few dozen lines.

5. Generate an OpenAPI spec from your test cases

Reverse the usual flow. From your inventory, write the OpenAPI spec the system should satisfy. Tools like Stoplight Studio make this painless. Then run Schemathesis against the (hypothetical) staging URL to see what it would test for free.

This stretch teaches more about API design than testing — and it's exactly the muscle that shifts QA from "checks the API" to "improves the API."

Where to take this next

You've covered API testing concepts in depth. The next steps are tool-specific skills and adjacent disciplines.

A few specific recommendations:

• If you don't already have a programming language under your belt: start with Python for QA — it pairs better with API testing than any other language and the requests library makes the work trivial.
• If you already use Java: Core Java for QA gives you the foundation for REST Assured, the dominant Java API-testing framework.
• If browser testing is on your roadmap: Cypress with TypeScript and Playwright both have first-class API testing capabilities — you can mix UI and API in one suite.
• For a tool focus: Postman is still the most-used API testing tool in QA shops. A dedicated Postman course is the natural follow-up to this one (coming to qa.codes).
• For depth: real microservices testing (saga patterns, eventual consistency, distributed tracing) is its own discipline. Worth pursuing once you have one or two services' worth of API tests under your belt.

What you've actually learned

If you walk away from this course remembering ten things, the right ten are:

1. APIs are contracts; tests verify the contract holds.
2. Status codes carry semantics — pick the right one and assert on it.
3. JSON Schema validation is cheap insurance against shape drift.
4. Auth needs a matrix, not a smoke check.
5. JWTs are readable; signature is what makes them trustworthy.
6. Negative and edge cases find more bugs than positive cases.
7. Pagination, filtering, and sorting hide off-by-one bugs at the boundaries.
8. Mocks are powerful and dangerous; pair with contracts to prevent drift.
9. CI tiering (smoke / functional / integration / nightly) keeps suites fast.
10. The right test plan is defensible, not exhaustive — you can explain what's covered, what's not, and why.

Those ten are enough to be a strong API tester at any company. Everything else — Postman tricks, framework specifics, advanced contract testing — is detail you pick up on the job.

You finished the course. Go ship a test plan.

📝 Capstone task

Final pass on your work.

1. Run through the self-assessment checklist above. Tally your score honestly.
2. For every unchecked item, decide: address it now, or accept the gap and document why.
3. Pick one stretch goal and spend two hours on it. Even an unfinished attempt at automation, GraphQL coverage, or a Pact sketch leaves you noticeably stronger.
4. Write a one-paragraph reflection answering: "If I had to start this capstone over, what would I do differently?"
5. Save the final version of your deliverables somewhere you'll find them later. They're a real portfolio artefact — useful in interviews, useful as a template for the next time you join a project that needs the same kind of plan.

Welcome to the working ranks of API testers.