Postman and its faults
In the era of the overwhelming popularity of the microservice architecture instruments of API testing are an apparent necessity. Postman is being praised for the simplicity of its interface, broad functionality and speed. But there are downsides. We tried to analyse the reviews containing the drawbacks of the product and investigated their validity.
These are the most popular reproaches to Postman:
- The no-code conception is not used everywhere, so it is not suitable for beginners
Postman can be used by beginners as well as by experienced specialists. You can build the queries up to your needs with the UI, or write tests on Javascript. The latter can be based on the suggested snippets, that are easy to understand and further use. It will only be needed to set up some parameters (server response status, response time, field value and other). The snippets themselves have names that suggest their meaning. If you are yet unsure as to what exactly you’d like to test, the hints will bail you out.
In addition, it is essential that you know the basics of JS as a QA Engineer.
- You can only test REST API with Postman
No, you can test any kind of protocols, including SOAP or HTTP, and transfer data in different formats.
Nevertheless, using SOAP UI when testing SOAP with its XML format is undoubtedly safer. At the same time, REST-ful web-services are easier to implement and more frequently used. And Postman offers more flexibility there.
- It does not support version control
TestMace, for example, creates tests in the form of a project that can be stored in the same repository with the backend, using the usual mechanisms of project management. At the same time, if a team works with Postman, the in-built synchronisation can be used. In this case, the team will get the latest version in case of updates.
- The need for manual setup of the queries, using swagger documentation
In SOAP UI it is possible to automatically generate tests from the imported description files wsds/wadl. As Postman integrates with swagger, the queries must be written manually.
- There is no possibility to reuse testing scenarios
It is a downside, really. Say, in TestMace such a possibility exists. In Postman you’ll need to create a new collection to reuse some requests from another one. But the developers are keen on following trends in optimizing the product and release new features almost every week. This is why Postman community counts in developers a lot.
- “It is not a real automation”
Well, Postman is not exactly an Automation Testing Tool,it is a tool to help manual QAs in a situation when API needs to be tested, but there is no automation on the project.
Nevertheless, you can make a collection of queries and have them launch automatically.
And, not exactly a downside, but a myth
- Only manual QAs need Postman
Following the principle of testing as soon as possible, the developers themselves sometimes need Postman to check cross-server communication. What also helps is separate top-notch manuals for developers and QAs.
To sum up
We’d like to note once again that postman is not an overarching instrument for automation testing, it is meant to check the client-server queries and backend responses.
The errors can be investigated with the console as well, but there is too little information shown. Whereas Postman reports allow you to look deeper into the issue and identify which microservice caused the error. One can use microservice management tools (Openshift, Rancher, Azure Management tools and so on) to track and detect errors in log-files, but QAs do not usually have access to those.
A comparison with the “Swiss Army knife to work with API” suits Postman well. There is nothing flawless, but Postman with its intuitive interface, diverse functionality and impeccable manuals makes QA’s job much more pleasant.
