Manual API testing

REST, Postman, Swagger

What is a REST API and what do you check in API testing?

REST is an architectural style: resources by URL, standard HTTP methods, a response usually in JSON, and the server keeps no state between requests.

What I check:

The status code and the response body: fields, types, values.
Headers: Content-Type, caching, CORS.
Negative cases: invalid data, missing fields, wrong types, 401/403/404.
Business logic: the data really changed in the system (GET after POST, a check in the DB).
Response time.

In an interview: REST is an approach where resources have their own addresses and actions are performed with standard HTTP methods. I check status codes, the structure and values of the response, headers, negative cases with invalid data and without authorisation, and that the change really happened, through a following GET or in the database.

How do you work in Postman?

Collections: requests grouped by functionality.
Environments: variables for dev, staging, prod: {{baseUrl}}, {{token}}.
Pre-request scripts: get a token, generate data.
Tests: assertions on status and body, saving values into variables for following requests.
Collection Runner / Newman: running a whole collection, Newman from the CLI in CI.

// the Tests tab in Postman
pm.test("Status 201", () => pm.response.to.have.status(201));

const body = pm.response.json();
pm.test("Amount saved", () => pm.expect(body.amount).to.eql(100.50));

pm.environment.set("transferId", body.id);   // for the next request

In an interview: In Postman I gather requests into collections, move addresses and tokens into environment variables, get a token in pre-request scripts, and in the Tests tab I write checks and save values, for example an ID, for the following requests. A collection can be run through the Runner or Newman in CI.

What is Swagger and how do you use it?

Swagger (OpenAPI) is an API specification: endpoints, parameters, request and response schemas, error codes. Swagger UI lets you send requests right from the browser.

As QA I use it as a source of API requirements, for a quick check of an endpoint, and for finding discrepancies between the documentation and real behaviour, which are bugs too. The specification can be imported into Postman.

In an interview: Swagger is API documentation in the OpenAPI format with the ability to send requests from the browser. I use it as API requirements, for quick checks, and I look for discrepancies between the documentation and real behaviour. I also import the specification into Postman, so I don't have to create requests by hand.

What is idempotency and why test it?

An operation is idempotent if a repeated call gives the same result as the first. GET, PUT, DELETE are idempotent; POST is not: two POSTs create two records.

I test: resending the same request (a double click, a retry after a timeout), and the system must not create a duplicate.

In an interview: An idempotent operation gives the same result on repeat. GET, PUT and DELETE are idempotent, and POST isn't. I check that a repeated request, for example after a double click or a retry after a timeout, doesn't create a duplicate.

How do you test authentication and authorisation in an API?

A request without a token → 401.
With an expired or forged token → 401.
With a valid token but without rights (an ordinary user on an admin endpoint) → 403.
Access to other people's data: user A requests user B's resource by ID → 403 or 404. This is an IDOR vulnerability, one of the most frequent.
A token after logout no longer works.

In an interview: I check requests without a token and with an expired token, which must give four hundred and one, and with a token without the needed rights, four hundred and three. Most important is whether a user can get someone else's data by substituting another ID: that is an IDOR vulnerability. And that the token stops working after logout.