11.5. API Testing Checklist for QA

Check for correct HTTP status (200, 201, 400, 404, 500)

This chunk emphasizes the importance of validating the HTTP status codes returned by API requests. HTTP status codes are standardized responses that indicate whether a request has been successfully processed or if an error occurred. A 200 or 201 status code typically means the request was successful, while 400 and 404 indicate client errors and 500 indicates a server error.

Imagine you send a package through a courier service. Upon checking the status online, a 'delivered' status confirms your package reached the recipient. If it says 'not found,' it indicates an issue in the delivery — similar to how HTTP status codes inform you about the success or failure of an API request.

Verify fields like id, name, etc.

This chunk discusses the necessity of verifying that the response body returned by the API contains the expected fields, such as 'id' and 'name'. Each API request should return a well-defined structure in its response, and validating the presence and correctness of these fields ensures the API functions as intended.

Think of this like checking your bank statement after a transaction. You expect to see the transaction ID and the amount debited from your account. If those details are missing, there may have been an error in processing the transaction, just like missing fields in an API response could indicate an issue.

Ensure id is an integer, email is a string

In this chunk, the focus is on validating the data types of the fields returned in the API response. For example, confirming that the 'id' field is an integer and that the 'email' field is a string ensures that the data adheres to expected formats and can be processed correctly by applications consuming the API.

Consider how you would ensure that the information on an online job application is correctly formatted. You wouldn’t want a numeric value in the email field; just like ensuring fields in API responses have the correct data types prevents errors during data processing.

Send without token and verify 401 Unauthorized Test

This chunk pertains to testing the API's authorization mechanisms. By sending a request without an authorization token and checking for a 401 Unauthorized response, you can confirm that the API correctly restricts access to authenticated users only. This kind of testing is critical for ensuring the security of the API.

Imagine trying to enter a secured building without your ID badge. The security team will not let you in, and you'll receive an 'unauthorized' response. Similarly, APIs should block access unless the user is authenticated with the correct token.

Send invalid data, expect proper error message

This chunk highlights the practice of negative testing, where invalid data is sent to the API to ensure it handles errors gracefully. By checking for appropriate error messages in response to invalid input, developers can confirm that the API provides useful feedback to users, improving overall user experience and system reliability.

Think of a vending machine. If you enter an invalid code, you expect it to respond with an error message explaining the issue. Similarly, when an API receives invalid data, it should respond with a meaningful error message to help users correct their inputs.

--