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.
Top comments (3)
Hi Ashley, I'm using a Postman a lot in my current day job, basically to do manual testing, but after reading this I'd like to juggle around a bit with those pre-request scripts. Really nice example you gave here, I'm gonna find (or write) myself a fake API to get a bit more acquainted with it,
Btw, I'm also a marketer who transitioned into software testing (about 2 years now). My advice: just keep doing what you love and you'll find your way sooner than later. Good luck!
The pre-request scripts are super neat! Let me know how it goes.
Thankyou Karel, that's really encouraging to hear! What skills from marketing did you transfer over to testing? I find it mostly gives me an edge with finding edge cases - understanding different types of customers and potential ways software can be misused - plus having a deep understanding of the relationship between conversion rates and hosting cost budget (I need to spend this much on hosting and this much on advertising to make this much....).
Not necessarily a skill but what I feel is very emphasized in the marketing industry is "strategy". I remember my previous (marketing) manager who was consistently taking into account the long-term marketing strategy he had in mind. Now that I'm working as a tester, I feel that continuously developing and emphasizing the elements of a sound strategy (defining goals, tactics, metrics ...) is often lacking. We keep certain metrics ofcourse, but when it comes down to the bigger picture I believe that we could learn a lot from the marketing department.