How Postman can Improve Your QA Engineering Practices

Connected services that depend on APIs can be difficult to test. You want to be certain whether or not a server will be available, if it will provide the expected result, or if changes made to your service will break other dependencies. Whether consuming your own APIs or third-party APIs, you can alleviate concerns with a structured and collaborative approach.

Good QA engineering is all about automation and replication. These qualities make good sense in terms of your time and the reliability of a product. In this article, we'll take a look at best practices in QA engineering and how Postman can help fill the gaps in your QA practices, including how to inspect API responses, test for specific results, and run tests at the right times, in the right way (hint: automation). Even better, you'll learn how you can build off of your team's work and share what you create with other engineers and colleagues.

Inspect API Responses with Test Scripts

Testing in Postman is much like testing most other software; you provide input to your APIs and interpret the results. Postman's core functionality includes making API requests and storing the response for analysis. You can view the results yourself, share them with teammates, save requests to Postman Collections, and run tests against the responses.

Inspect API Responses with Test Scripts

When you make a basic API request with Postman, you can provide parameters, headers, body, and authentication details. After you send the API call, you'll see your data in the response. The response will show you a status code, such as "200 OK" for a successful read operation. The body and headers contain the most detailed data - generally containing your expected (or, at times, unexpected responses). For JSON responses, you can collapse and expand arrays and objects in the result. You'll also receive any metadata, such as the response time and content length.

After you understand the basics of your API call, you'll want to write tests against it. This is where you'll declare what you expect to see in the response. In the request pane at the top of your Postman app, click the Tests tab. Here, you can start writing scripts based on the API response. Postman also provides example test snippets to help you get started with your testing.

For example, here's how we'd look for a 200 status code:

pm.test('Good response', function () {
   pm.response.to.have.status(200);
});

Send the request again and you should now have numbers next to the Test Results tab in the response pane. If all is well, the tab should include "(1/1)" for a successful test. When you click the tab, you'll see the test name and whether it passed or failed.

There are a whole lot more test scripts, the foundation of performing QA on APIs. For more, see our API test scripts introduction that includes examples and syntax for the data available in the Postman sandbox.

Automate Collection Runs Across Environments

Running one-time tests from the Postman app is useful, but the most effective QA engineers create repeatable workflows. In Postman you can organize multiple requests into a collection and run them all sequentially. You can use response data in subsequent requests and ensure the right authentication and variables are used by creating environments that are specific to your collection. Best of all, you can run your tests on a schedule, so you always know your APIs are operating as expected.

Manage Environments

Here's how to do it. Create a new environment by clicking the New button and select Environment. Give your environment a name, then add some variables for this environment (ie. API key, client ID, etc.). You can store different variables for development and production servers or share a collection without including your credentials by storing your credentials locally.

New Environment

Once you have an environment, you can apply it to the current request by selecting it from the dropdown menu on the upper right in the Postman app. When you run a series of tests on an entire collection, you can select the corresponding environment to ensure that all of the necessary keys are available for the runs.

Apply a new environment

Finally, use Postman Monitors to schedule tests on a collection. You can choose the timing, from every five minutes to once a week. Run monitors using your particular environment and from one or more worldwide regions.

Bring Tests to the Command Line with Newman

So, you now have the know-how to create some collections that include API requests and robust, repeatable tests. You can run them from the Postman app and on any schedule you choose using monitors. Now you may want to expand on how you can initiate these tests. Many QA engineers want to run Postman tests as a response to an event, such as a deploy, in order to ensure that you don't break anything with a new build. Our command line utility, Newman, makes that possible.

Bring Tests to the Command Line with Newman

First, you'll want to export your collection from the Postman app. Newman uses a JSON text format to represent the requests and tests within your collection. Within the Postman app, hover over your collection, click the "" menu, and select Export. Choose the latest format and click the Export button to begin the download.

Export your collection from the Postman app

Next, you'll also want to download your environment so Newman has access to the variables you created. Click the gear for settings, then the down-arrow next to the environment you want to download. Store it in the same location as your collection, then open up a terminal and navigate to the directory you saved your Postman files in.

Make sure you've installed Newman from NPM and run your tests using this command:

newman run CollectionName.postman_collection.json -e EnvironmentName.postman_environment.json

You'll get the results of your tests right on the command line. Command line tool junkies may prefer running tests this way, but there's another reason to use Newman. You can incorporate your Postman tests into your build systems, such as Jenkins and Travis CI. With each deployment, you can ensure that your API tests pass - making your services pass through QA more quickly and making your product more reliable.

Collaborate With the Whole Team

You could keep these API QA efforts all to yourself, but you'll get more out of it when you share with your team. Throughout the API lifecycle, you can collaborate with your team to create, run, and test collections. Postman makes it easy to share collections using team workspaces. Postman Workspaces allow you to maintain personal workspaces for your own work and to create team workspaces to share collections, feedback, and work with your teammates.

Postman Workspaces

In the left sidebar of the Postman app, hover over your collection, click the "" menu, and select Share Collection. You can choose an existing team workspace or create a new one and invite teammates to collaborate. There is no limit to the number of team members that can be in a Postman Workspace, so invite everyone who might access the API—the QA team, other engineers, architects, and product managers.

Your requests, tests, and other scripts come along with a shared collection. However, if you created an environment with variables or access tokens, you may also want to share it in the workspace. Keep in mind that variables can be used to hide any information that you don't want to share with your team, like personal keys and IDs. To share an environment with your team, just click the gear to manage environments, then hit the Share button for the appropriate environment.

We've found Postman users that work in team spaces are able to accomplish more together. Collaborating with others in your organization allows QA engineers to begin their work earlier, build tests on top of existing requests, and helps close the gap between development and QA. Further, with team workspaces, you can start a new project with elements that collaborators have previously shared.

For more information, including pricing, see our plan comparisons.

Be sure to read the next Application Development article: Github Adds Features to Atom to Support Easier Code Review

 

Comments (0)