Once the API has been made available in the testing environment a subsequent part of the life cycle is executed.
API Test Case Design
Generally the design of API test cases is run in parallel with other activities such as requirements analysis or the design of the specifications and is a process which requires a large amount of input from the owners or responsible persons of the endpoints which the API will be interacting with.
This is predominantly because the process of testing an API is a potentially destructive test where despite the best of intentions something could still go wrong which results in impact to the API or to other systems.
Therefore a good test case will generally outline testing procedures and expected results which provides coverage across both the Southbound and Northbound interfaces.
System Acceptance Tests
Officially per known nomenclature the system acceptance tests are designed to provide coverage over the interaction between systems and is often used to test back-end systems or other systems which do not require interaction from customers or users. With respect to the life cycle of an API the system acceptance tests usually govern the testing of the endpoints on the Southbound interface, that being the interaction of the API with its back-end or third-party information providers.
User Acceptance Tests
In the traditional sense user acceptance tests outline the test cases and procedures for aspects which require user interaction. Typically relevant to software with graphical interfaces or web and mobile interfaces, the user acceptance tests play a role in the life cycle of an API to provide coverage for tests relating to the Northbound interfaces.
Given that the Southbound interface is tested during SAT (Systems Acceptance Testing) a higher degree of confidence should exist that back-end systems and third-party providers are returning correct data to requests for use in subsequent orchestration of the API.
Therefore the UAT (User Acceptance Testing) places emphasis on the interaction on the Northbound interface such as between a mobile application and the API or a web front-end and the API. These tests and procedures are written to provide coverage of the requests and responses between calling applications and the API and should align with the API specifications document as designed.
In more extreme cases organizations will have a stringent requirement for the API to provide and maintain a set level of performance governed by metrics such as transaction times and the amount of transactions per second (concurrency) to be available.
During load testing the API is bombarded by requests under a variety of different scenarios for an extended period of time the purpose of which is to assess the API’s ability to sustain the required operational workload. Each request and response is automatically recorded by the software suite in use and then analyzed in a number of ways to provide insight and analysis in to the performance of the API.
During the more exhaustive tests software developers, analysts and operational persons also simulate the effects of a wide-scale outage to gain understanding and mitigate the effects of any particular system or process being unavailable for operation.
Generally such tests provide additional test coverage not otherwise captured by SAT or UAT tests as these are usually done in singularity rather than holistically.
An API is, in essence, a piece of software and particularly where it is exposed to the Internet has the propensity to attract trouble. Malformed payloads, buffer exploits, injection attacks, denial-of-service attacks and brute-force hacking attempts are just a few of the malicious activities you an look forward to.
Penetration testing is designed to assess whether the API’s security mechanisms are suitable to prevent such attempts and if the API contains a good DNA sufficient mechanisms should exist. Whether the API is designed a self-standing application or is hosted on an API gateway the penetration tests will assess the API’s readiness and capabilities to mitigate attack and prevent the unauthorized access to information.
After all testing is complete the API is promoted to production. Managing and monitoring an API in production is an extensive topic which will be covered in a future article.
Life cycles take on various shapes and forms depending on organizations and their internal processes but the quintessential aspect to remember is that one must exist in order to govern the design and development of the API.