API Testing Guidebook

API Testing Guidebook

What is API ?

API stands for Application programming Interface, it is a mediator which is present between the presentation layer and the Database layer. API enables the communication and the data transfer between the two channels. API is a business logic, which is written by the developer in any programming language to perform the business/requirement related operations.

What is API Testing ?

API Testing is testing the business logic of the developed application. The purpose of the API Testing is to validate that the developed business logic of the application is working according to the given requirements.

Types of HTTP Methods ?

HTTP (Hypertext Transfer Protocol) is a protocol used by the World Wide Web to transfer data between servers and clients. HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. The most commonly used HTTP methods are:

  1. GET
  2. POST
  3. PUT
  4. DELETE
  • GET : The GET method is used to retrieve the data/ information specified in the given URL and displays it to the user.
  • POST : The POST method is to send the data to the server and create a new resource on the server.
  • PUT :  The PUT method is used to update a resource (such as a file) on the server. This method is like replacing or updating something.
  • DELETE : The DELETE method is used to delete a resource (such as a file) from the server. This method is like deleting something.

HTTP status codes 

HTTP status codes are 3-digit numbers returned by a server in response to a client’s request. They indicate whether the request was successful, or if an error occurred. Here are the most common HTTP status codes ,

2xx (Successful): These codes indicate that the client’s request was successful. For example, 200 OK means that the request was successful and the server is returning the requested data.

  1. 200 OK: This status code indicates that the request was successful and the server is returning the requested data. It is the most common 2XX status code.
  2. 201 Created: This status code indicates that the server has successfully created a new resource as a result of the client’s request. For example, when a new user account is created.
  3. 202 Accepted: This status code indicates that the server has accepted the client’s request, but the request has not been fully processed yet. This is often used for long-running tasks that take time to complete.
  4. 204 No Content: This status code indicates that the server has successfully processed the request, but there is no content to return. This is often used for requests that delete or update a resource, where no data needs to be returned.

4xx (Client Error): These codes indicate that the client’s request was invalid or could not be fulfilled. For example, 404 Not Found means that the requested resource was not found on the server.

  1. 400 Bad Request: This status code indicates that the client’s request was invalid or malformed. For example, if the request is missing a required parameter.
  2. 401 Unauthorized: This status code indicates that the client needs to authenticate itself to access the requested resource. For example, if a user tries to access a protected resource without logging in.
  3. 403 Forbidden: This status code indicates that the client does not have permission to access the requested resource. For example, if a user tries to access a resource that they don’t have access to.
  4. 404 Not Found: This status code indicates that the requested resource could not be found on the server. For example, if the client requests a resource that has been deleted or moved.
  5. 405 Method Not Allowed: This status code indicates that the requested resource exists, but the HTTP method used to access it is not allowed. For example, if a client tries to use a POST request to retrieve data instead of a GET request.

5xx (Server Error): These codes indicate that an error occurred on the server while processing the client’s request. For example, 500 Internal Server Error means that there was an error on the server.

  1. 500 Internal Server Error: This error occurs when the server encounters an unexpected condition that prevents it from fulfilling the request made by the client. It is a generic error message that doesn’t provide much information about the specific problem.
  2. 501 Not Implemented: This error occurs when the server doesn’t support the functionality required to fulfill the request made by the client. For example, if a client sends a request for an HTTP method that the server doesn’t support, the server will return a 501 error.
  3. 502 Bad Gateway: This error occurs when the server acting as a gateway or proxy receives an invalid response from the upstream server. In other words, the server acting as a gateway or proxy cannot get a valid response from the server it forwards the request to.
  4. 503 Service Unavailable: This error occurs when the server is unable to handle the request due to temporary overload or maintenance. This error indicates that the server is currently unable to handle the request and the client should try again later.
  5. 504 Gateway Timeout: This error occurs when the server acting as a gateway or proxy doesn’t receive a response from the upstream server within a specified time limit. In other words, the server acting as a gateway or proxy times out while waiting for a response from the server it forwards the request.

API Test Case Identification Approach:

  • Normal Test Case(Positive Test Case)
  • Negative Test Cases
  • Security Related Test Cases
  • Chaining Request Verification related Test cases
  • File Upload Related Test Cases

a) Normal Test Case (Positive Test Case):

  • Positive test cases describe happy path scenarios. Positive testing determines that your application works as expected.
  • For positive test cases, you write a test asserting a successful response like receiving a 200 OK , or similar, HTTP status code.
  • Check for the Boundary value analysis for the minimum and maximum values of the acceptance criteria.

Example: Checking the system for a Correct username and password combination to login is a       way of positive testing.

b) Negative Test Cases:

It is always very essential to know why negative testing is important. It is considered as a crucial factor in test case execution. It is interesting to note that negative testing is done to break the project with respect to its different test conditions.

  • Check for Boundary value conditions for the values outside the range of the acceptance criteria. Identify no. of fields which will have this validation and  make the test case of each field one by one.
  • For example: Let’s suppose a user is allowed to encash 20,000 rupees in a day from the ATM machine but if the user enters some value greater than 20,000 then the user should get some error for the same.
  • Check for the special characters validation(if exist):

Identify no. of fields which will have special character validation and  make the test case of each field one by one. Special characters validation may exist for some fields and some fields may not have this validation. 

  • For example: If a user tries to enter some special characters in the Name field then the user should get some error message over there. Special characters include characters like @,#,$,%,^,&, etc.
  • Check for the data format validation:

We should make the test cases by putting the values in the fields which are not lying in the below mentioned conditions.

Fields Validation
EMAIL Correct format of email: “test@gmail.com”
PAN CARD Correct format of PAN Card is

-First 5 characters should be a letter

-Next 4 characters should be a number

-Next 1 character should be a letter

DATE Format Correct format of Date is:

#YYYY-MM-DD#

Mobile Number Correct format of Mobile number for India is:

+91-1234567890

  • For example: If a user provides some wrong format in fields like Email, Date, PAN Card, Mobile number, then the user should give some error message for that validation. Suppose user provide some email like “test@test”, user should get the error message for the email validation
  • Check for the data-type validation:
Fields Validation
Integer Correct format of field should be: 

“number” : 1234

Incorrect format of field should be:

“number” : “abcd”

String Correct format of field should be: 

“name” : “test”

Incorrect format of field should be:

“name” : 1234

  • For example: Let’s suppose there is one key which accepts only numbers in the value and we provide the string value in it then user should get some error message for the same that this field not accept number 

{ “phoneNumber” : “Demo” }, for this case user should get some error message for the same

  •  Check for mandatory fields validation for each and every field: We should check the mandatory fields validation by not providing the key and value of the mandatory fields in request body and query params.
  • For example: For Registration on any website we need to provide our basic details like Name, email and password, suppose we didn’t pass the name in the name in the API then API should give some error for name field.
  • Check for optional fields validation for each and every field(if exist): We should check for the optional fields that if the user did not provide the optional fields value in the API then API should not give any error, API should work as expected.
  • For example: Let’s suppose there are some fields in an application form for the user which are optional and if the user has not provided that field then API should not give any error it should work as expected.

c) Security Related Test Cases: 

  • Authentication and Authorization

Authentication is the process of verifying who a user is, while authorization is the process of verifying what they can access .

For example:

  • Authentication:  Employees in a company are required to authenticate through the network before accessing their company email.
  • Authorization: After an employee successfully authenticates, the system determines what information the employees are allowed to access.

d) Chaining Request Verification related Test cases

Let’s take an example to understand the Chaining Request by getting the details of Flight ticket:

  1. User Login into Application and get “Authorization token”.
  2. The Authorization token will be used in some API to fetch the booking Id
  3. After fetching the booking id we will call one API to get the booking details with booking Id
  4. After getting booking details we can download the details in pdf or any other format by calling one API.

e) File Upload Related Test Cases:

Check multiple file upload

  • Verify that the user can be able to select and upload multiple files if required.
  • Verify the order of the file should be the same as files uploaded or both cases one by one and multiple files uploaded.

Check the file extension

  • Verify that the user can only be able to upload the allowed files only. For example doc, docx or pdf, or image files like jpg, png etc.
  • Verify a proper error message should be shown in case if the user tries to upload the file which is not allowed. File type not allowed.

Check for file size

  • Verify an error message should be shown in case if the user tries to upload files more than the allowed limit.

Leave a Reply