QA Interview Hub · Knowledge base · Quizzes

API

Checklist: what to test in an endpoint

What to check when testing an endpoint

The basics: the status code, the response structure against a schema, the types and values of fields, headers (Content-Type, caching, CORS) and response time. For POST, PUT and DELETE I check the side effect: through GET or a DB query. I also check conformance to the Swagger documentation.

Negative cases: missing required fields, wrong data types, empty strings and null, boundary values of length and numbers, extra fields. Also a nonexistent ID (404), an invalid ID format, a wrong method (405), a wrong Content-Type (415). Errors must return clear messages without stack traces and internal details.

Security and more: a request without a token and with an expired token, access to someone else's resource by changing the ID (IDOR), SQL injections in parameters. Then pagination, sorting and filters, idempotency, parallel requests and rate limiting.

Positive and negative cases

Go through this list for every new endpoint; in an interview, recite the same list in answer to "how would you test this API".

Positive

  • A valid request gives the right status, schema and field values.
  • The record was really saved: check through GET or SQL.
  • Only the required fields, and all fields together.
  • Pagination, filters, sorting; an empty result is [], not an error.
  • Response time within the SLA.

Negative

  • Without a required field, with null, an empty string.
  • A wrong type: a string instead of a number, an array instead of an object.
  • Boundary values: 0, minimum, maximum, maximum + 1, long strings.
  • Invalid JSON and a wrong Content-Type.
  • A nonexistent id gives 404; an unsupported method 405.
  • A duplicate of a unique value gives 409.
  • In all cases a 4xx with a clear message, without a stack trace and without a 500.

There are usually more negative cases than positive ones, and they are what find most validation bugs.

In an interview: First the positive cases: status, schema, values and a check of saving through GET or SQL. Then the negative ones: missing fields, wrong types, boundaries, invalid JSON, a nonexistent id and duplicates, and everywhere I expect a 4xx with a decent message, not a 500.

Security and fintech

Security and access

  • Without a token, with an expired and a corrupted token: 401.
  • A role without rights: 403.
  • Someone else's id in the URL: no one else's data (IDOR).
  • The response has no passwords, full card numbers or internal fields.
  • SQL injection and special characters in string fields don't break the request.
  • Rate limiting: 429 after the limit.

Fintech

  • Amounts are exact decimals: 0.1 + 0.2, rounding, cents.
  • A negative amount, zero, an amount above the balance or limit.
  • A repeat with the same Idempotency-Key: no double debit.
  • Currency: ISO 4217 codes, an unsupported currency.
  • The balances of sender and recipient after a transfer add up; on an error nothing is partly debited.
  • Dates and time zones: the ISO 8601 format, operations near midnight.

The point about 0.1 + 0.2 is a reminder that in JavaScript it gives 0.30000000000000004. If the backend or front end calculates money in float, cents sooner or later "drift", so amounts must be stored in decimal types or in minor units (cents).

In an interview: For security I check 401 and 403, IDOR, the absence of sensitive data, injections and rate limiting. In fintech I add amount precision, payment idempotency, ISO 4217 currencies, balance consistency and time zones.