Introduction

For my portfolio, I conducted exploratory testing with Postman and saved my requests in a set of collections. This is what I learnt. As part of my study, I took Amber Race's TAU course on Service APIs, which I will reference throughout.

Tips

1- Use the environmental variables. They make mistakes harder to make, and ensure you're using the same values every time.

2- Duplicate is your friend. When you're just changing a single param, it's better not to rewrite the whole test every time.

3- You can write pre-request scripts and tests which also send requests to the API you're testing, or any other you have access to.

What's so cool about pre-request scripts?

Well, tests aren't flaky in and of themselves. There's nothing inherent about them. It is often to do with the way they're written, and thus it can be fixed.

Pre-request scripts enable API tests to be independent of each other. You no longer have to be reliant on test order.

Here's one of mine for each, before I discovered you can make pre-collection pre-test scripts.

4- You can write pre-request scripts for a whole collection.

With a pre-collection pre-request script, I can move all of the current pre-request script to pre-collection, and create a crocodile object for just this test in my new pre-request script. Then I keep the test script the same. Perhaps the variable name might change.

5- You can test a whole set of possible inputs without creating a separate request for each one. Here's how.

a) create a CSV file with a header row. Where you're only testing one set of inputs and the reason for using each line is slightly different, I like to use the second column for explanation.

b) Use the header row name to get the variable. Then set it like so. It will look red and an alert will appear that it is not connected to anything. That's true enough until...

c) When you run the collection, add the file in 'upload file'.

Plus: From exploratory to regression

If I was to transform this test suite from exploratory to regression, I would do the below.

The API I am using has a rate-limit of 100 crocodiles per account. Therefore I should delete my new crocodile objects after every test, and create a new one for every test.

I would create several before testing the 'view list of crocodiles' request. Creating crocodile objects this way I don't need to manually delete crocodiles every so often.

I would then use two test-k6 accounts - one on the limit to check the rate-limit works, and one for the rest of the tests which require authorization.