Ensuring your application's smooth and secure operation, especially with millions of daily users, calls for thorough API testing. Identifying vulnerabilities and errors early helps prevent disruptions and protect sensitive data, addressing crucial functionality and security concerns.
In this post, you'll learn how to write manual test cases for API testing, ensuring your systems' integrity and reliability while delivering flawless user experiences and safeguarding your application's reputation. Let's begin!
Key takeaways
Manual API testing involves testers manually interacting with APIs to validate their functionality, reliability, performance, and security. This process includes sending requests to the API and verifying the responses, ensuring the API performs as expected under various conditions. It helps identify bugs and issues that automated tests might miss, providing an assessment of the API's behavior in real-world scenarios.
Here are some key types of API testing:
Writing test cases is one stage of a wider quality assurance testing process — the steps below cover the API-specific detail. Let's examine a detailed step-by-step guide.
Start by thoroughly reviewing the API documentation. This includes understanding the following key elements:
Identify all possible scenarios that need to be tested. Some of the possible ones include:
Also, consider all aspects of the API’s functionality, including:
Prioritize your test cases based on their importance and impact. Focus first on critical functionalities and high-risk areas. This will help ensure that the API's most important features are tested early and thoroughly.
Determine the input data for your test cases. This includes both valid and invalid data. For example:
For each test case, define the expected output by considering the status code, the response time, and the data returned.
| Range | Category | What it means |
|---|---|---|
| 100–199 | Informational responses | The request was received and understood; the client should continue, or ignore it if already finished |
| 200–299 | Successful responses | The request was successfully received, understood, and accepted |
| 300–399 | Redirection messages | The user must take further action to fulfil the request |
| 400–499 | Client error responses | The request contains bad syntax or cannot be fulfilled by the server |
| 500–599 | Server error responses | The server failed to fulfil an apparently valid request |
Remember that HTTP status codes are a standard for web services, but the concept of expected outcomes is universal. Similar codes or messages indicating success, failure, or specific errors would be used for non-web APIs.
Write detailed test cases that outline the steps to be followed. Each test case should include the following:
Run the test cases manually by using manual testing tools. Follow the steps outlined in each test case, send requests to the API, and record the actual responses.
Compare the actual results with the expected results. Note any discrepancies or unexpected behavior. This step helps identify API functionality, performance, or security issues.
Document any defects found during testing. Provide detailed information about the defect, including steps to reproduce, expected and actual results, and any relevant screenshots or logs. Reporting defects helps developers understand and fix the issues efficiently.
| Test Case ID | TC001 |
|---|---|
| Test description | Verify login fails with invalid password |
| Pre-conditions | User must be registered |
| Test steps | 1. Send a POST request to /api/login 2. Include valid username and invalid password in the request body |
| Input data | { "username": "user1", "password": "wrongpass" } |
| Expected results | Status code 401 Unauthorized. Error message: "Invalid credentials." |
| Post-conditions | No session is created |
| Test Case ID | TC002 |
|---|---|
| Test description | Verify fetching user profile details |
| Pre-conditions | User must be logged in |
| Test steps | 1. Send a GET request to /api/user/profile 2. Include valid auth token in the request header |
| Input data | Auth token: Bearer validtoken123 |
| Expected results | Status code 200 OK. Response contains user profile details |
| Post-conditions | User profile details are retrieved |
| Test Case ID | TC003 |
|---|---|
| Test description | Verify creating a new user |
| Pre-conditions | None |
| Test steps | 1. Send a POST request to /api/user/create 2. Include new user details in the request body |
| Input data | { "username": "newuser", "password": "newpass123" } |
| Expected results | Status code 201 Created. Response contains user ID |
| Post-conditions | New user is created in the system |
Here is a checklist you can use for your manual API testing:
| Check | What to verify | Status |
|---|---|---|
| Status code | The response status code is as expected | ☐ Done ☐ Pending ☐ Failed |
| Response time | The API response time is within acceptable limits | ☐ Done ☐ Pending ☐ Failed |
| JSON schema validation | The response validates against a predefined JSON schema | ☐ Done ☐ Pending ☐ Failed |
| Response headers | Specific headers are present, such as Content-Type and Cache-Control | ☐ Done ☐ Pending ☐ Failed |
| Response payload | Response data is correct, including fields, values, and nested objects | ☐ Done ☐ Pending ☐ Failed |
| Response size | The size of the response data is within reasonable limits | ☐ Done ☐ Pending ☐ Failed |
| Response encoding | The encoding of the response is correct, for example UTF-8 | ☐ Done ☐ Pending ☐ Failed |
| Pagination | The pagination logic works, if the API supports it | ☐ Done ☐ Pending ☐ Failed |
| Authentication and authorization | Both mechanisms are correctly implemented | ☐ Done ☐ Pending ☐ Failed |
| Error handling | The response is correct when incorrect parameters are passed or errors occur | ☐ Done ☐ Pending ☐ Failed |
| CORS | Cross-Origin Resource Sharing headers are set correctly, if applicable | ☐ Done ☐ Pending ☐ Failed |
| Concurrency and threading | The API handles concurrent requests and threading correctly | ☐ Done ☐ Pending ☐ Failed |
| Rate limiting | Rate limiting is enforced as expected | ☐ Done ☐ Pending ☐ Failed |
| Security | Sensitive data is not leaked in the response and the API follows security best practices | ☐ Done ☐ Pending ☐ Failed |
| Negative testing | The API responds correctly to invalid or unexpected inputs | ☐ Done ☐ Pending ☐ Failed |
| Performance and load | Performance and response time hold under various load conditions | ☐ Done ☐ Pending ☐ Failed |
| Integration | Integration tests pass where the API interacts with other services | ☐ Done ☐ Pending ☐ Failed |
Global App Testing (GAT) provides an API that integrates crowdtesting into your development process, allowing you to manage functional tests for web and native applications. By leveraging GAT's API, you can efficiently launch, monitor, and retrieve test results directly within your existing tools and systems. This integration facilitates continuous integration and deployment, ensuring testing across multiple device combinations in over 190+ countries.
With GAT's API, you can achieve the following:
You can get started in just two simple steps:
By utilizing GAT's API, you can streamline your testing processes, ensure higher-quality releases at a faster pace, and unlock team and company efficiencies. Interested in partnering with Global App Testing? Schedule a call with one of our specialists today to discover more.
Manual API testing means a tester sends each request by hand and inspects the response, which suits exploratory work, one-off checks and behaviour that is not yet stable. Automated API testing runs those same requests from a script on every build, which suits regression coverage and load. Most teams design and validate a case manually, then automate it once it is proven.
Seven fields: a unique test case ID, a test description, pre-conditions, the test steps including method and endpoint, the input data, the expected results covering status code and response content, and the post-conditions.
There is no fixed number, but a workable baseline is one positive case, one negative case for every validation rule, and one edge case for every boundary value such as empty, minimum, maximum and oversized inputs. Endpoints handling authentication or payments usually need more.
No. You need to read API documentation, understand HTTP methods and status codes, and interpret JSON or XML responses. A tool that sends requests and displays responses is enough to start. Coding becomes relevant when you move to automation.
Testing only the happy path, checking the status code but not the response body, ignoring response headers and timing, failing to reset state between tests so results depend on run order, and testing endpoints in isolation without integration checks.
Check the exact code, not just the range: 200 for a successful read, 201 for a successful create, 400 for malformed input, 401 for a missing or invalid credential, 403 for an authenticated user without permission, 404 for a missing resource, 429 for rate limiting, and 500 for a server fault.
9 Best bug tracking tools to keep testing fluid
10 Best load testing tools to consider
5 Generative AI testing tools to consider