Automation of Tester's Routine Using Postman

Many testers and developers use Postman for both manual and automated API testing. However, not all Postman users fully exploit its capabilities to simplify API-related tasks.

In this article, I will demonstrate a few basic examples of how to make API testing faster, more efficient, and reduce time spent on various routine actions when using Postman.

Let's dive in and uncover some tips and tricks that will make your API testing experience with Postman faster, more efficient, and less prone to repetitive tasks.

Let’s start with Environment.

Environment

In Postman, the Environment feature allows you to manage environment variables during the execution of test scenarios. It serves as a container where you can define and store a set of variables that will be used in all requests and scripts associated with that environment.

Using the Environment feature in Postman provides flexibility and reusability. Instead of hard-coding values or repeating them across multiple requests and scripts, you can define variables in the environment and reference them wherever needed.

This way, you can easily update values in one central location without modifying each individual request.

Indeed, each variable in an Environment has a name and a value. You can utilize these variables to store data such as URLs, authentication tokens, API keys, and other values that can be used in your requests

Let's consider an example:

We have a regular backend service with a REST API, https://reqres.in, that we want to test. Let's create the first environment.

To create an environment, open the "Environments" tab in the left menu of Postman, and click on the "+" button.

Now enter the name of the first environment, let's call it "Production."

In an Environment, variables are typically created to be reused across requests.

Let's create the first variable: Name it "service_url" and set its value to "https://reqres.in".

After creating the variable, click on "Save" to save all the changes.

In the top right corner, locate "No environment" and click on it. Then, select our created environment, "Production". Now, we can use the variables from the selected environment.

Let's go to Collections and create a new request. In the URL field, enter the following: “{{service_url}}/api/users”. Now, you can click on "Send" and see the result:

Our request has been completed successfully. The request was made to the address "https://reqres.in" which was stored in the environment variable "service_url" and we appended "/api/users" to it.

By utilizing the "service_url" variable, we can easily reuse it across all our requests. This allows for flexibility and makes it convenient to manage and update the base URL in a single place, saving time and effort in case the URL needs to be modified.

But the real power comes when we create multiple environments. Let's go back to "Environments" and create another environment called "Stage". In this environment, let's create the "service_url" variable again, but this time, with the value "https://stage.reqres.in".

Now, in the top right corner, change the Environment to "Stage." Go back to the previous request and execute it again:

We receive an error in the response because the domain "stage.reqres.in" does not exist. However, this is not a problem as it confirms that the URL has changed to the value of the "service_url" variable from the "Stage" environment, and everything is functioning correctly.

By creating multiple environments with the same variables but different values, we can easily switch between them as needed.

In the projects I participate in, we typically create the following environments:

• Production: Used to test requests in the live production environment.

• Stage: Used to test requests in the development/staging environment.

• Branch: Created specifically for testing API branches or feature branches.

• Local: Created for testing the API on a locally deployed service. It is typically used by developers to test and debug the API on their local machines.

For each environment, variables are created and shared across requests. These variables can include API keys, URLs, user agents, and other parameters that differ from one environment to another.

By utilizing environments, you can easily switch between different environments (such as Dev, Production, Branch, or Local) with just a couple of clicks.

Now, let's move on to another tool that helps speed up the creation of new requests.

Request Header Presets

In most services, each request has a set of headers that can include the following:

• Content-Type: Specifies the media type of the request payload, such as application/json or application/x-www-form-urlencoded.

• Authorization: Provides authentication credentials or tokens to access protected resources.

• User-Agent: Identifies the client making the request, typically the name and version of the software or application.

• And other custom headers specific to different services

Indeed, manually filling in all the headers for each new request can be time-consuming, especially when there are numerous headers involved.

Two functions come to our rescue in such situations:

• Duplicate: This function allows you to quickly create a new request by copying an existing one and then modifying it to suit your needs. It is a fast method but may not always be suitable if certain requests have unique headers that should not be sent in other requests.

Header presets: This is the function we will be discussing now.

To access the header presets feature, follow these steps:

1. Open any request in Postman.

   
   

2. Go to the "Headers" section.

   
   

3. On the right-hand side, you will find a button labeled "Presets."

After clicking on the "Presets" button, select "Manage presets", and in the opened menu, click on "Add". You will then see the following screen:

Here, we can add headers for presets. Let's create the first header:

• Key: "Accept-Language"

• Value: "en"

• Description: "Preferred content language code"

It is a good practice to provide descriptions for headers in presets so that every team member understands the purpose of each header.

Let's name the preset "Standard Headers", and click on "Add."

Now, open the "Headers" tab of the request, and click on "Presets" once again.

In the list, you will see the preset we created. Select it, and the header from the preset will be added to the list of headers:

So we have added our header from the preset to the current list of headers.

That way, we can create multiple presets for different types of requests.

For example, in the projects I participate in, we usually create three presets:

• one for authenticated requests,

• one for unauthenticated requests,

and one for internal requests.

When using presets, there are a few things to keep in mind:

1. If the request's header list already contains headers from a preset, applying the preset will not overwrite those headers. The preset will simply add all the headers to the request's header list. Therefore, it's important to check the list for duplicates.

You can use variables from the Environment in the header values. This makes presets even more powerful, as you can dynamically set values based on the environment.

Now, let's move on to examples of automating routine tasks using tests.

Automation of Passing Authentication to All Requests After Login

At many services, there are endpoints that require authentication. Let's take Bearer authentication as an example, where each request needs to include the "Authorization" header with an authentication token. This token needs to be fresh because it has a specific expiration date.

For testing requests with authentication, there are multiple approaches. I will demonstrate what I consider the simplest and quickest method, in my opinion.

To illustrate this, let's take the reqres.in service as an example again. To access an authenticated endpoint, Bearer authentication is required.

The service has an endpoint "/login" that provides an authentication token. Let's make a request to this endpoint in Postman:

After a successful request, the service returns an authentication token. We need to configure Postman to automatically include this token value in all requests that require authentication.

To achieve this, navigate to the "Tests" tab (located below the URL input), and on the right side, under "Snippets", select "Set environment variable". The following code snippet will be generated:

pm.environment.set("variable_key", "variable_value");

To achieve this, navigate to the "Tests" tab (located below the URL input), and on the right side, under "Snippets", select "Set environment variable". Replace "variable_key" with "authorization_token" and replace "variable_value" with "pm.response.json().token" so that it looks as follows:

pm.environment.set("authorization_token", pm.response.json().token);

Now, execute the request. If it is successful, click on the eye icon in the top-right corner. You will see a screen displaying the list of variables in your environment, which includes the "authorization_token" variable with the value extracted from the response of the request.

What happened here:

• We used a test script. Tests are always executed after the request is made. You can learn more about tests here: Postman - Writing Scripts.

• pm.environment.set() is a function used to set the value of an environment variable, and that's how we set the value of the authorization_token variable. You can even set the value of a variable that doesn't exist in the environment yet, as it will be automatically created.

pm.response.json() retrieves the JSON object from the response of the request. Then we use .token to extract the value from the desired field.

As a result, we have an environment variable that will automatically be set whenever we use the `/login` endpoint. This allows us to have the authorization token automatically included in every subsequent request that requires authentication.

Now all we need to do is go to the relevant requests and add the "Authorization" header with the value "Bearer {{authorization_token}}". This way, the authorization will be automatically included in those requests using the value of the "authorization_token" variable:

As a result, we have written a small script that eliminates the need to manually set the authorization in our environment. It will automatically be applied when a successful login request is made.

This kind of automation allows us to simplify working with requests that require data sharing between them.

Let's move on to the bonus part — generating various fields.

Generating Random Data for Requests

Quite often, when testing different APIs, we may need various data, such as:

• User data: names, surnames, phone numbers, company names, etc.

• Unique UUIDs

• Current date and time

• and much more

  
  

Some of these things can be invented and written manually each time, while others need to be generated using services, websites, etc. But why bother doing that when Postman can do it all for you?

Postman has a wide range of data options that it can generate. You can explore all of them by typing "{{" in the URL input field.

The menu scrolls and contains over 100 different options, such as:

• Current timestamp (UTC or based on your timezone)

• Random phone number

• UUID

• Random locale

• Random color

• And many more

If you frequently test APIs, such as when modifying user data, sometimes it's much more beneficial to use random values instead of hardcoded ones. This allows you to cover unexpected scenarios as it introduces variability.

By using random values, you can test edge cases and uncover potential issues that may not be apparent with fixed values.

Well, Conclusion

So, we have covered several simple examples of automating routine tasks with the features of Postman. These pretty little things greatly simplify working with APIs and reduce the amount of manual work and time spent on testing. Enjoy using them! 🙂