How To Perform API Testing – Basics Explained
With the expansion of microservices in the software development practices, QA engineers have an increase in testing activities related to APIs. Approach to testing APIs must be systematic and well planned. Quite often the documentation about APIs is scarce and it is not covered by development practice. In this case it is of paramount importance to have a frequent and clear communication with developers. API testing can be done in isolation or as a part of integration testing. Let’s first discuss API testing in isolation.
API basics
API is not visible on the UI and it represents a connection channel between two different modules of software or even two different systems who need to communicate together. It takes so called request from one side and pass it to the other side. These two sides are often referred to as client and server. The easiest test we can do is to send a valid request and examine the response from the server. First, we must know how a valid request looks like and what the response should look like. In ideal circumstances the details about request and response in the API docs. In the document below we see the URL where we should send a request, so called end point. We see that we need a token for the authorization and we see what body of the request should look like.
Ideally we would also have what response should look like to avoid any surprises.
Examine the documentation
At first we need to prepare ourselves for testing. Our first reference should be documentation or if there are none documentation then a conversation with developers and architects is a must. Either way we should remove any doubts before start of testing. Examine if you have all the information for testing. How to obtain authentication token for example. Do the requests use appropriate HTTP methods? What are the requirements in terms of response times? What should we expect for response codes? This is the time to ask as many questions as possible and to point out to unwanted behavior for fast resolution.
API “happy path” testing
To cover all the possibilities with our tests, we need to start with basic “happy path” test. First make sure that everything is working as described in the documentation. Since we don’t need the UI for API testing we would use some software for testing. The most popular choices are Postman, Katalon, SoapUI or Hoppscotch. When we perform “happy path” testing, we should pay attention to response body, response code and response time also. Response code should be in 2xx range for successful responses and response time should be below 500 ms. Of course, response time is subject to discussion according to user’s expectations, but in general 500 ms is a standard.
API negative testing
Next in line, we should try to pass invalid data in request, either by connecting to the wrong end point or sending non-existing data in the body of the request. The developers anticipate these kinds of things and these responses usually have a valid message covering such cases. If there is no such message but the response returns error code the QA engineer should report a bug. Another thing that we must cover with the test is authentication, or better said the lack of. If the user does not authenticate or fails to send the token with the request, the API must behave in a specific way. A different variation of this test is to check the API behavior for user that doesn’t have the right to use this API.
API performance testing
Testing one request at a time is useful but doesn’t depict the real life. Imagine that you have an online store with credit card payment option. The user is redirected to the payment processor page on checkout. This redirection means that your online store uses payment processor’s API. I don’t think we have to point out that API failure on this step because too many people are trying to checkout would be detrimental to the business. It is essential to test the API with larger number of requests attempting to pass information. It can give us insight about possible dropped requests or about response time increase followed by larger number of users. Postman makes it easy to do API performance testing as described in one of my previous articles.
The benefits of API testing
It is quite easy to achieve Shift left testing by doing API testing, because it provides fast feedback. The issues can be solved early in the development process. We don’t need UI to perform it but it offers us an abundance of information about our system. As part of integration testing, API testing provides us with 95% of information about usability and functionality of our software. We can complete a lot more tests even with automated testing when we use API testing compared to UI testing. It is not browser dependent and it is programming language agnostic. QA engineers can easily share API requests with developers if they need to reproduce some issue. That would be very difficult in situations when QA engineers use UI automation tool. Another thing is that it is relatively easy to automate API testing compared to UI tests. There is a variety of tools that can be used for automation and including the tests in CD pipelines. If you would like to explore automation of tests directly from Postman and including the tests in Azure DevOps pipeline, you can find more information in this article.
