“This API is simple, no need for that much testing”.
Everyone is happy. The product owner can ship quickly, the developer tests alone, and no need to involve QA or an architect.
While this approach works for localized APIs, it does not for more critical ones.
APIs are the tires on the road: the only link ensuring processes between your company and others in the ecosystem.
Some of them can support internal operations running 24/7, and many will directly support the user experience.
Any degradation makes you lose a potential user, hence the need for continuous API testing with Quality Engineering to remain with Quality at Speed.
Follow the QE Unit for more exclusive Quality Engineering.
Start with the why, for whom, then the what
APIs are usually seen as mere technical and intermediary layers.
But APIs are used everywhere to solve an end-user problem: sending data to an analytics platform, retrieving a list of products, and passing an order.
APIs must therefore answer the needs of personas.
The first step before coding is to identify target users, their needs and associated use-cases. Only from there technical design can start.
First verification of Quality Engineering can already be done at that stage: ensuring the use-cases, data dictionary, API standard and endpoints design.
Build and validate the minimum valuable API
Development can start from well defined users and associated use-cases. But results must appear quickly.
A tunnel implementation of the full API will create a distance between the APIs producer and consumer, increasing the risk of divergence.
