Let’s imagine a restaurant. Diners check their dishes: how they are served and presented and how tasty they are. In the kitchen, chefs do their work. Somewhere in the middle, waiters communicate with both parties. Software products have a similar structure: dishes are the frontend, the point of interaction between users and the application; the kitchen is the backend, that is, the basis for everything to function well; the waiters are the Application Programming Interface (API). Can we guarantee that a dish is excellent only because of its presentation? Certainly not. Likewise, testing strategies must be comprehensive and not concentrate only on the frontend (that would be the basic format in the market). We must also make progress with the APIs and reach the backend.

Let’s focus on APIs. They are formal specifications that guarantee the interconnection between two pieces of software. In certain cases, they require the human presence: humans collect the data that come through User Interfaces (UI) and perform the corresponding calculations and transactions in the data layer; they re-submit the results at the UI. In other cases, they allow two IT systems to communicate and interchange data or services (e.g., a mobile application that takes data from a mapping application to trace the ideal logistical route).

The exponential growth of IT in the cloud elevated APIs to a new value dimension: the interconnection grows, provided the number of digital services also grows.

Meeting expectations

APIs play a fundamental role for organizations that need to create software using preexisting applications and services. If the API remains stable (it maintains the operations, the data formats, and behaviors), no matter the number of changes made to the API, the software products that use it will not need to develop upgrades.

Given the above, we can understand the relevance of incorporating APIs to the testing strategy. These tests imply that APIs are tested immediately to determine if they meet the requirements of functionality, reliability, performance, and safety required by the project. With every new release, API regression tests verify that the changes made did not “break” the interfaces, and the client applications that rely on them will keep working as they did before.

From the point of view of the quality team, the advantages of API tests are that they do not depend on the language used, they can run without a user interface, and they allow the evaluator to create automated tests with high coverage from the first sprint. Finding a test case that cannot be automated is difficult.

Benefits of comprehensive testing

Concerning the client’s perspective, one of the main benefits is accelerating execution times related precisely to the automation capacity. Additionally, errors are detected earlier than usual, so correcting them is less costly and has a far lower impact than they would have later in the development process or, even worse, if the software were already in production. The comprehensive coverage of tests and the fact that the product is viewed comprehensively from the backend to the frontend result in higher-quality software.

Errors often occur behind curtains and are challenging to detect with front-end tests. Additionally, often a modification “breaks” something that was working well, or there is a technical debt that hinders the coverage of all possible areas. Regression tests can also be conducted comprehensively to guarantee this does not happen.

In short, if API tests are avoided, the process will probably take longer, the spectrum of errors that are not detected will be broader, and there will remain frontend scenarios that have not been evaluated from end to end and will run the risk of failing during production. So, going back to our restaurant analogy, it is as if, after swallowing the first mouthful of food, the diner found out that the chef forgot to wash their hands today.