The company I work for is creating an api for our current desktop application.
We’re looking at Postman as a possible API testing solution.
We currently have 2 people available to maintain our API testing. Both of which don’t have much experience with API testing outside of simple postman requests\tests.
Questions:
1.) Based on your experience, at what point does request\test management get difficult? Is it when you have 10 requests and 100 test, or x10 that, or is that even how you’d measure that?
2.) Does anyone know of examples for larger scale projects publicly available?
My thought is to see how companies manage large number tests\requests, so we can learn from it. Most of the test organization examples I’ve seen have been small and not indicative of the real world of 100’s of requests and 1000’s of tests.
3.) Is there anything missing (I’m guessing yes) in regards to the way I’m thinking about API testing?
if the people responsible for API testing don’t have much experience, probably Postman is a good tool to start with.
Things get difficult when you can no longer use the same requests and start duplicating requests and code. Depends on which scenarios you plan to test.
I am not aware of any good examples (not saying that there are none). Many large collections are just API documentation and not necessarily focused on API testing.
Allow yourself to go through a learning process. Get started and adapt along the way. It is hard to make all the right decisions in advance. Make sure you know what is possible with Postman and which are the limitations. Learn about techniques to reuse code and requests. Especially the part with reusing code is causing issues in larger projects.
I would like to explain something here based on my personal experience.
The complexity of your Testcase depends on the complexity of your API design and the way the developer handles the exception. When we started API testing a year before, it was completely manual. We just execute the requests , create Test Data and test it in UI. But that’s not the way it should go right? So my Lead advised us to learn more about API and the API testing process. Then we said to the developers, we will be testing the API solution and not the UI part. So to be more strong as a API tester, you should learn some concepts of API and you need to know what all to be tested as part of API testing.
Because we know in UI, what usually will be covered as Test cases.
That’s not applicable for API. For example API testing covers the response time, schema validation etc…
So I suggest you to start of with the understanding of API first. And then the API testing (basically what will be covered as Tests/Assertions) , and then you already mentioned you are aware of basics in Postman. Now you can design the Tests in Postman as per your needs.
Personally Postman helped me when I started API testing, with very limited knowledge about API testing.
First you can simply start using collection runner, then with Newman and to Jenkins. Likewise you can extend the integration based on the tools available in your organization.
In our Organization, we use Postman for both Documentation and Testing.
P.S: Sorry if I didn’t answer your questions still Let me know what details I should provide more
Postman is quality popular for writing documentation and testing.
If an API provider shares a Postman collection, it won’t include the API tests as those are not relevant for the consumers. This why I said it is hard to find good examples.
Let me know what details I should provide more 