Application programming interfaces (APIs) enable secure messaging and data transfer between applications using endpoints. Today’s web and mobile applications rely on these APIs to perform all the back-end processing that makes an application function.
SOAP and REST APIs, the two primary types, communicate through request and response messages to exchange data and information between application endpoints. APIs operate behind the UI as back-end processes. For software testers, APIs represent the engine that transfers and saves data between applications and databases.
APIs play a significant role behind the scenes for an application or application suite, which means they can easily cause issues for customers and significantly affect performance. In today’s world of shared data and heavily integrated application processing, software testing is crucial to ensure both API security and functionality. APIs have become critical infrastructure components, so testers must validate API functionality throughout the development lifecycle and post-release.
In this blog, we’ll discuss some ways to conduct manual and automated API testing, including what tests and tools to include for effective test coverage.
API testing methods and test coverage
APIs are fully testable, as long as you’re willing to collaborate. And API testing is essential to make sure these connections work into the future.
Testers must learn about each API and how it impacts the application. To get started, consider forming a partnership with a supportive developer or two. It is standard practice to fully document the functional aspects of an API. The dev team can provide access to this API documentation, and they can also assist with connection issues and ensure tests are valid.
Next, confirm the API documentation specifies the output status and response format accurately. The majority of API testing revolves around the response and the response status code — not only getting the proper response status code but also verifying the response data itself. Response data significantly affects application functionality, performance, and the ability to effectively save and retrieve data.
API response status codes are important for error message verification and negative testing. Standard API response status codes include:
1xx (informational). Indicates the request was received and accepted for processing.
2xx (successful). Indicates the request was successfully received and processed.
3xx (redirection). Indicates there’s an issue with the request that must be addressed before the message is processed.
4xx (client error). Indicates the request cannot be processed.
5xx (server error). The request is valid but the server failed to process it appropriately.
Keep in mind that developers code the specific values for the API. Verify the API documentation is complete and includes the actual expected code for successful and failed requests.
When creating functional API tests, test only one API per test case. Testing a single API at a time simplifies test maintenance and failure analysis. If you plan to create system or end-to-end tests using multiple APIs, make sure the tests clearly state which API is being tested per verification step.
Plan to also create tests against the data within the response. APIs return response data with specific data types, formatting and language. API response text returns in plain text, using JSON or XML. Most RESTful APIs are tested using JSON, while SOAP uses primarily XML.
Include a step to verify the response body contains the expected data types in every test. Many API defects occur due to bad data types in a request. If an invalid data type makes it into an accepted response, the application UI might crash or hang when attempting to save, or data might display incorrectly in the UI as well.
Testers must not only confirm the APIs function as expected but should also create negative testing conditions to attempt to generate errors. APIs should respond appropriately to invalid requests either for security, formatting or syntax issues. You don’t want APIs accepting bad data that saves into the application database.
How to approach manual API testing
There are several options for manually testing APIs. The first is to use a tool like Postman to create API tests and execute them when needed. The second option is to use existing manual or automated test suites.
Create individual manual API tests in Postman for the following:
Security. Verify security protocols are respected and enforced.
Endpoint validation (active or non-responsive). Verify the API endpoint is responsive and active for processing.
Data validity. Verify only messages with valid data are accepted or processed.
Database connectivity. Confirm data is saved as expected when being displayed or transferred.
Testers can enter defects against the API based on failures within the application workflow associated with the API. For example, if data displays differently in the mobile app than on the web app, that’s likely an API data issue. Likewise, if requests fail to process, the problem might indicate the API is rejecting previously valid requests for a specific reason — many times request data requirements change without the API being properly updated to handle it.
No time to use Postman to create API tests? Consider creating API test suites from existing manual or automation regression suites. Once a tester understands the interaction between APIs and application workflows, it can be possible to create a suite of functional and integration tests specifically to test each API. Add new additional API tests to cover any uncovered scenarios. Don’t forget to add some valid negative tests as well. Execute the regression tests and verify the application continues to function as expected.
For example, a user might encounter API failures in the application UI when a user saves new data or edits existing data. Applications also typically refresh automatically when data changes — any performance lags or system hangs may be the result of an API defect.
Review the data in forms, tables and visual charts. When changes are saved, do those changes display? Verify the same data displays between mobile and web platforms as well. Many defects arise because the mobile app handles the API data differently than the web app or uses different APIs entirely.
If you don’t have the bandwidth to validate these results in house, or prefer to validate them on real-world devices and networks, a crowdtesting partner like Applause can deliver those resources. Applause offers more than one million digital experts around the world, ready to uncover defects and issues with the user experience.
Creating reliable automated tests
One advantage of creating API tests individually in a tool like Postman is the ability to create API test automation easily. Automated API tests are typically more reliable, execute faster, and are easier to maintain without the cost overhead of functional test automation.
Using an API testing tool, organizations can leverage automated tests to validate each API during development cycles and even monitor API health post-release. Most API testing tools offer pre-built code snippets that can be edited to expand test coverage even without coding experience. Code snippets allow users to create valid APIs in various test coverage patterns for more thorough testing.
Before automating API tests, testers must have a dedicated instance or server, which removes interference from other test data or users developing an API. Next, prioritize test types. Determine which API tests are critical to run continuously to ensure the API functions as expected.
Common API test candidates for test automation include:
Endpoint validation. Is it functioning and only accepting valid messages?
Data validation. Is the application displaying the expected data?
API construct verification. Does the response contain the right data displayed correctly?
Security handling. Token receipt/response, and rejected message processing.
Communication failures. What happens to a failed message or data transfer?
Message format validation. Verify that messages meet formatting standards.
Keep in mind, automated API tests are fully editable and can be re-used to monitor ongoing API health. One test creation effort that yields two suites of relevant test automation is a great ROI.