Testing and automating REST API functional use cases with POSTMAN : QA Tester / Business Analyst journey 2022

8 min readAug 14, 2022

Hello, happy to start this new journey from QA Tester / Business Analyst personal experience in the mystic swamps of software / application testing. As discussed in the product owner journey which you can read HERE, when building a software / application / etc … all is not about interface test, the API too must be tested, then the performance tested (but that is an another subject). There are different types of API from GraphQL, to Soap, but in this example the REST APIs which are one of the most common structure will be explored .

Why APIs are becoming more important these days than before ?

Why should this subject is more important now than ever ? Well, simply because of the latest's trends of architecture and applications that enhance the use of APIs such as:

1. Headless (CMS or others) trends : We will not go deep into this but it means that the web pages are not generated server-side, it means that all data even some static are exposed by API’s

2. API as a service : Stripe API, Twilio API, Google Maps API, etc… a lot of business models offers now API as a service for payments online, maps, sms sending, email sending, retrieving weather, etc…

3. Mobile applications and some IoT: Most mobile applications (API are mandatory for those with authentication, account, profile management and non local data storage) need to connect to a backend server via API to exchange data and do basic operations such as login, retrieving user data, etc…

4. Microservices architecture (vs monolithic architecture): this kind of architecture will need each service to communicate, and the most common and simplest way to communicate between services is with API (synchronous), there is another way of communicating, the asynchronous one which is used in IoT and edge(device(s) to device(s) , device(s) to server(s))

There are a lot of other factors but we need to keep in mind that more and more systems are interfaced via network today than 10 years ago

Funny experience, when functional quality engineer saw that API testing was mandatory : Oh NOOOO :-) backend code, we are dont’ do code …

One of the answers to that kind of reaction is to reassure and remove any stress : The thing is that THERE IS NO NEED TO KNOW THE APPLICATION CODE TO TEST THE APPLICATION API.

The strategy is that “when you test an api you don’t care about the code running, you just want to check if your application expose an interface, so that test cases can be done”

API requests , what is behind that?

This part is already detailed in another article but to sum it up there are 4 kind of steps to load a webpage, these information are accessible for everyone by doing :

inspect the page
go to the network section
reload the page
wait for the page to be fully loaded and you can see : the document part is the static content of the page, the stylesheet is the “fancy part” including applying the spaces, fonts and colors, the script part include the different script run while loading the page and can include complex animations, and the API requests are referenced under the xhr/fetch tags usually
select the xhr/fetch lines to see the api calls and responses(or you can filter)

Undestanding basic API responses

What happens when we call a server via an HTTP request ? When calling a server with an HTTP request, the server will respond (or not) with an answer and a status. The most common statuses to keep in mind are :

200 : request treated (most of the time it doesn’t mean the functional test case is ok, the answer content must be checked)
401 : permission denied, you need some permission from authentication to use this service (view the authentication part)
404 : you are accessing a ressource that doesn’t exists
500 : there is problem with the server or the request

The send message is described (header, body, parameter) and the response too

Accessing API Documentation

API documentation are widely share through the swagger format. It’s a pretty standard way to present all the webservices and the ways to authenticate.

The most useful link for this is the swagger Editor : https://editor.swagger.io/ This tool can be used to format the application swagger, or to check though the GUI the documentation of an API.

Testing with POSTMAN

With a tool such as POSTMAN, testing an API becomes super easy, so we will test it by implementing an object, for the information an object is a instance of an unique set of data in an application. To install postman you can go there : https://www.postman.com/

Let’s go, the test and automation will be described in a few steps below.

STEP 1 : Authenticate user

The provided authentication is only a frontend mock, and the objective is not to explore that process, but usually API authentication request will provide a token that can be used later in each request.

Authentication request response for the frontend

STEP 2 : Build functional request workflow

We will test a functional CRUD (CREATE, READ, UPDATE, DELETE). For that instance we will use the field that gives an unique identification to the object, which is the “id” field in our case. We will read at multiple step of the test workflow to check that the object is created, deleted and modified.

Object Identification : In some systems, this id will be in a form of an uuid which is a timestamped and unique id: 2326c3b1-c8e5–41d3-b098–0eb032dc8533 (you can test here https://www.uuidgenerator.net/). It will be discussed in another topic but using “incremented id only like 30 in our case” is not a secure strategy and doesn’t define the uniqueness of an object in a global scale network. But it is definitely more readable for human and fits on some use case like e-commerce catalog internal identification.

Here we have 4 steps :

Create a pet (CREATE : HTTP POST request) https://petstore3.swagger.io/api/v3/pet
Check the pet info (READ : HTTP GET request) https://petstore3.swagger.io/api/v3/pet/30
Modify the selected pet (UPDATE : HTTP PUT request) https://petstore3.swagger.io/api/v3/pet
Check the pet info (READ: HTTP GET request) https://petstore3.swagger.io/api/v3/pet/30
Delete the pet (DELETE : HTTP DELETE request) https://petstore3.swagger.io/api/v3/pet/30
Check the pet info (READ: HTTP GET request) https://petstore3.swagger.io/api/v3/pet/30

NB : In this case we will be working on “pet management microservice” provided by swagger but we need to keep in mind that we can manage any kind of object in an application: flight / train / car booking, e-commerce order and invoices, bank account and wire management, game account creation, person profile, etc…

STEP 3 : Automate requests

The fun part !!!

But also the technical part, Postman provides already premade scripts for testing.

But for real full complex use cases we can cover test such as (randomising a value, picking a random object, checking a field value, waiting for a specific time or date before a request, fill fields with standardized random values), these are available here : https://github.com/Mino75/Postman-scripts

Automating all the request is the most interesting thing, this part can save thousands of hours of configuration and testing. Postman interface that allow us to run some scripts and to store environment values to make the test more dynamic.

STEP 4 : Apply test conditions on each request

The first step is to apply the global conditions that will be automatically tested on each request : for our case it is the response time

PS : Normally a request must be respond below 800ms MAX, if the treatment is higher the team must consider use asynchronous instead of synchronous and release the use. Users won’t wait screen freeze loading that exceeds 1s.

The second step is apply all the functional tests on the requests :

create and check that there is an id
update then check that the updated data changed
delete and check that there is no object.

STEP 5 : Run the test

Note : before running, we must ensure that en empty environment have been created, Postman will store all the values in the selected active environment.

Click on button to run the entire test. (to open the runner righ click or click the icon in the bottom right)

Postman provide a summary which can show the different test results

STEP 6: Iterate the test

Sometimes, one feature works a limited number of times on purpose, by system limitation or by development mistake, for example a user can post 10 comments per minute to limit spam. The iteration part allow to validate the existence of this kind of feature / bug.

Iterations are better with randomized data, for example randomize the name each time.

Go further

To go further, the API can be automated by using Newman : the server version of Postman, but this operation need a little bit devOPS operations and might be explored in the future.

Wrapping UP

To sum up, there are 6 steps on automating API test :

Authenticate
Build the workflow
Automate the requests
Apply tests conditions
Run the test
Iterate the test

Input value must be controlled by the API not only the interface, so characters length, type must be added in the API test book.

The most important thing is that the test must follow the test-book and cover all test cases (passing, non passing, degraded). The test example provided does not cover all detailed test cases, some important test cases like imputing a name with 10 thousand characters must result in an error “maximum characters 50 for a name”are the kind of test that must be added to make a complete automated test book.

The postman workspace is available here : https://www.postman.com/blue-shadow-467580/workspace/testing-and-automating-rest-api-functional-use-cases-withpostman-mino-randriamanivo

The test template and the collections are available here : https://github.com/Mino75/Postman-scripts

See you again, an I hope that with this testing API becomes easier for all.