What is API testing?
First, we need to know about API. API stands for Application Programming Interface. That’s all.
Then, you may ask: what is its real meaning? So, let’s go with Application Programming first.
Application programming usually has 3 layers: User Interface, Business Logic, and Data Storage.
Did you notice it, the “interface” word? “Interface” here means something simple like “A way that can be used to interact with something”. User Interface means “A way that User can use to interact with the Application”.
And the “Application Programming Interface” means: “A way that Application Programming can use to interact with the Application/System ”. It is not for a specific User to use, just for the interaction between Machine to Machine, Service to Service or System to System, so we can call API is the middleware for the communication.
With this information, let’s go to “What is API Testing?”
API Testing is not only similar to other kinds of Software testing: to ensure that the API is matched with the expected behavior (functionality), but also to test the non-functional aspect of the API which can affect the entire system (performance, reliability, security).
API Testing is the most crucial part of the software development life cycle, so no doubt that this is the most challenging part. But, it is just a piece of cake if you understand it clearly and have a good plan to do it. Let’s see.
Definition of done for API testing
Most of the time, testing a single API can be done with 3 simple steps:
- Send the request: to the targeted server URL with the desired parameter.
- Get the Response from the targeted server.
- Validate the Response: as expected from the test case.
But as usual, we need to define the scope and the test case for API Testing first. So, to make sure that an API is tested thoroughly, we need to focus on the test case and the steps above, especially for step 3: Validate the Response.
DoD for API Testing can be split into 2 parts:
Functional testing:
First of all, we need to make sure the API works correctly and matches all the requirements. Things that can be listed are:
- API is available to use.
- Response codes are correct: for Failed or for Success case.
- Response body output is correct: for the Success case.
- The error message is correct: for the Failed case.
- Make sure that only the right person with the correct permission can use the API.
If the API passed these tests, we can say that the feature related to this issue will work correctly without any mismatch in the behavior.
Non-functional testing:
If the API had already passed the functional testing, why do we need this kind of test?
“A feature works correctly doesn’t mean that it is a correct feature”. With this thinking, we found out that there are a lot more aspects that we need to cover before marking an API is Done:
- Response time: some systems require correctness and can be slow, but some require fast response instead.
- Security: the API needs to match with security rules in the system, without exposing new security issues.
- Reliable: for the high load of usage, if needed.
- And more.
Each system will have its own DoD, but above are the core general items for API testing.
Benefit of good API testing plan / strategy
Everything will work, at least, when you have a good plan. But, having a good plan for API testing requires you to have enough knowledge of your system and a good mindset.
The result of a good API testing plan are:
- Increase the speed of validating the API.
- Collaboration between teams better (Team works on API and Team consumes API), without waiting for a long time to test.
- Increase productivity of the whole team.
- Easier to create the smoke test for the system, with the correct test case.
- Easier to convert to an Automation test case without spending more effort on re-writing the test case
- With good test case collections, changing the requirements is not a big deal because we always know where we need to change on our API test case.
- Unleash the true power of the QA/QC team to try more on “how to make it better/quicker” instead of doing the same testing thing over and over again.
Best practices
To ensure that you are doing API Testing in the right way, here are some best practices that you can apply:
1. Design the test case correctly to ensure coverage, by using all possible API input combinations.
2. Organize test cases by category.
3. Test the happy case with the expected result first. After that, test for the failure case.
4. For the Failure case, make sure the API and system fail gracefully.
5. Keep the test case as isolated as possible, by reducing the dynamic variables in the test case.
6. Prioritize the API call to test the API quickly, and for easier to do the smoke test on it.
7. To make the testing run smoothly, create a plan for the API/Testcase call sequence.
8. Do the Load Test on this API and on other APIs to see how well the system handles stressful situations.
9. Apply the Automation if possible, besides the Manual test.
Tools for API testing
Calling API is easier said than done. It requires a lot of skill to manually call the API directly. Fortunately, we have a lot of tools that help us to call and test the API with familiar user interfaces, like:
- Postman: a tool for manual and automation API testing with an easy-to-use UI.
- SoapUI: the ultimate tool for testing SOAP, REST API. Supported Web Service testing.
- JMeter: a tool for load test API, that also supports functional tests.
- Katalon: a tool for automation test the UI (E2E test), but still can be used to do the API test.
Conclusion:
API Testing allows developers to start testing early in the development cycle before the UI is ready. It helps to eliminate a lot of issues before the integration step happens and helps QA/QC access the thing that they can not explicitly access through the UI or through other services. Understanding API Testing is the crucial step in keeping your system more reliable and more stable, ensuring the success of our system in the future.
•••
Source: https://saigontechnology.com/blog/api-testing-in-software-development