🗓️ 14-Day API Tester Prep Plan

// STUDY

• HTTP methods: GET, POST, PUT, PATCH, DELETE — idempotency and safety rules, and why the distinction matters when designing test cases for a badly behaved API
• Status code semantics: 200, 201, 204, 400, 401, 403, 404, 409, 422, 500 — what each code means for the client and the specific test assertion it demands
• REST constraints: statelessness, uniform interface, resource naming conventions — what makes an API design testable versus painful to test
• Authentication mechanisms: API keys, Bearer tokens, OAuth 2.0 (client credentials and authorisation code flows), session cookies — what each means for test setup and token refresh handling

// PRACTISE

• Read the API Tester role page and map each listed skill to a question bank topic — this becomes your study tracker for Days 12–14
• Using only curl or a REST client (Postman, Bruno, or Insomnia), call 3 endpoints on a public API (e.g. jsonplaceholder.typicode.com): GET a collection, GET a single resource, POST a new resource — record every status code, response header, and body field, and write one sentence explaining what each means
• Write 5 test conditions for a PATCH endpoint that updates a user's email: happy path (200 + body), malformed JSON body (400), missing Authorization header (401), resource not found (404), and email already taken (409)

// STUDY

• Postman collections: request organisation, environments and variables, test scripts with pm.expect(), pm.response.to.have.status(), Newman CLI for running collections in CI
• JSON schema validation: required fields, type checks, pattern matching, enum values, additionalProperties: false — how to validate that a response body matches a documented contract
• Negative case design: malformed payloads, out-of-range values, missing required fields, wrong Content-Type header, expired or stale tokens — each deserves its own assertion, not just a status code check
• Request chaining: extracting a resource ID or auth token from one response using pm.environment.set() or a variable, and passing it as a path parameter or header into the next request

// PRACTISE

• Build a Postman collection against reqres.in or jsonplaceholder.typicode.com: GET list → GET single → POST create → DELETE, with pm.expect() assertions on status code, body shape, and at least one response header for each request
• Add 3 negative tests: a request with a missing required field (expect 422 or 400), a request with an invalid auth token (expect 401), and a request with an out-of-range value (expect 400 or 422) — assert the correct status code and a meaningful error message in the body
• Chain 3 requests: POST to create a resource, extract the returned ID, use it in a GET to retrieve the same resource, then DELETE it and assert 200 or 204

// STUDY

• REST Assured: given/when/then DSL, path and query parameter injection, response body extraction with JsonPath, schema validation using the json-schema-validator library, and response time assertions
• Karate DSL: feature file syntax, background section for shared auth setup, call expressions for reusable flows, data tables for parameterised requests, built-in response matching with match and contains
• Data-driven API tests: loading test data from a CSV or JSON file and running the same assertion logic across multiple input payloads — one failing row should not block the rest
• CI integration: running REST Assured (Maven/Gradle) or Karate tests in a GitHub Actions workflow, triggering on push, publishing the Surefire or Allure HTML report as a downloadable artifact

// PRACTISE

• Write a REST Assured or Karate test suite covering the same flows as your Postman collection: at minimum, GET list with schema assertion, POST create with body extraction, DELETE and verify 404 on subsequent GET
• Add one data-driven test: the same endpoint, 3 different request payloads in a data table or CSV, each with a distinct expected HTTP status code — assert status and body for each row
• Set up a GitHub Actions workflow that installs dependencies, runs the full suite on push, and uploads the HTML report as an artifact — trigger a deliberate failure and fix it from the Actions log alone without running locally

// STUDY

• REST Assured bank: focus on JsonPath extraction, schema validation, response time assertions, authentication setup (given header, OAuth helper), and common DSL mistakes
• Karate bank: feature file structure, call patterns, background fixtures, data tables, and the difference between match, contains, and each
• Contract testing fundamentals: consumer-driven contracts, Pact terminology (consumer, provider, pact file, pact broker), and when Pact adds value over schema validation alone — senior interviewers test this
• Behavioural bank: an API breaks backward compatibility mid-sprint, a service returns inconsistent status codes, a bug only appears under load — practise structured STAR answers

// PRACTISE

• Answer 10 questions aloud from the API, REST Assured, and Karate question banks — time yourself at 90 seconds per answer and flag every question where you stalled
• Identify your 5 weakest answers and write a worked example for each, drawing on the test suite you built in Days 4–11
• Run a 30-minute timed mock: given an OpenAPI spec for an endpoint you have not seen before, produce a written test plan — which cases to automate first, which to leave exploratory, and how you would structure the suite