Share
Explore
1. Introduction
The purpose of this document is to analyze the team’s needs and recommend an API testing tool that aligns with functional requirements, cost considerations, privacy policies, and compliance with security standards (ISO).
2. Functional Requirements
2.1 Key Requirements
• Creation and sharing of collections (workspaces, similar to Postman) to synchronize team efforts.
• Local workspace support – the ability to work offline.
• Support for pre-request and post-request scripts.
• Environment variables.
• Execution of entire collections – running scripts for multiple requests simultaneously.
2.2 “Nice to Have”
• Example tests.
• GraphQL testing support.
2.3 Current Usage Scope
• Manual API testing.
• Simple automated tests.
• The need to share collections among users (via JSON files, repositories, or Swagger integration).
2.4 Future Needs
• End-to-end automated testing (e.g., PAI).
3. Constraints
3.1 Cost
• The tool should not exceed the cost of Postman ($19 per user per month as of 11/20/2024).
• A free or open-source licensing model for basic functionality is preferred.
3.2 Privacy Policy
• The tool must not collect or process user-inputted data under business licenses.
• It must comply with client agreements regarding the use of cloud solutions.
3.3 Security and ISO Compliance
• ISO does not prohibit the use of cloud tools, provided client agreements permit it.
• The tool must pass data security approvals.
4. Analysis of Available Tools
4.1
✅ Pros
❌ Cons
• A popular tool with a rich ecosystem.
• No support for running entire collections in the free version.
• The free version supports manual API testing and sharing collections as JSON files.
• Cost of the full version ($19 per user per month).
• Intuitive user interface.
• Limited collaboration features in the free version.
• Support for variables, pre- and post-request scripts, and manual testing.
There are no rows in this table
4.2
✅ Pros
❌ Cons
• Intuitive tool with GraphQL support.
• Limited team collaboration, even in the paid version. Collections can only be shared via JSON export/import (e.g., if one person adds a new request, others must manually import the updated file, increasing the risk of conflicts).
• Free version includes variables, scripts, and manual testing.
• Less advanced collection management features.
• Ability to save collections locally and integrate with repositories.
• User-friendly privacy policies.
There are no rows in this table
4.3
✅ Pros
❌ Cons
• Lightweight and fast web application.
• Lacks advanced real-time collaboration features like commenting or versioning collections without external integrations.
• Supports GraphQL, variables, and manual testing.
• No organized multi-environment support. While users can set global variables, the inability to easily switch between environments limits its usefulness for complex projects.
• Free usage with the option to extend functionality through integrations.
There are no rows in this table
4.4
✅ Pros
❌ Cons
• Supports running collections from the command line.
• Requires manual configuration.
• Can integrate with CI/CD pipelines.
• Lacks a graphical user interface.
• Open-source and free.
There are no rows in this table
4.5
✅ Pros
❌ Cons
There are no rows in this table
5. Recommendation
1. Postman (Free Version) – Recommended as the primary tool for manual API testing and sharing collections via JSON files or repositories. For end-to-end automated testing, external tools (e.g., Newman, custom scripts in JS) can be used.
2. Insomnia – A suitable alternative, especially when GraphQL support and local workspaces are critical.
3. Hoppscotch – Best for lightweight, quick manual testing with basic GraphQL support.
Additional Recommendation: Consider shifting potential costs to clients (to be evaluated).
6. Summary
The free version of Postman remains the most versatile tool for the team’s current needs, providing an intuitive interface and functionalities required for manual API testing and sharing collections. For advanced use cases, Insomnia or Hoppscotch are worth considering.
Additionally, if the team uses Postman only for limited collaboration (e.g., updating endpoints), the paid synchronization service may not be necessary. Alternatives like GitHub repositories or exporting Postman collections to tools like Coda could suffice. If the backend maintains Swagger, importing collections into Postman is relatively straightforward and partially addresses the challenge of updates.
It is worth asking the client about implementing a paid Postman. A bit like we do in some projects - the client pays for the tool and we present the client with the value resulting from it. In the case of Postman, arguments are easy to provide by comparing the plan with the requirements.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.