“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.
The most simple API stubs must be built at that stage to get early feedback from users on the value provided.
These mocks can be done using a swagger description for a REST API for example. Make sure to integrate non-functional requirements such as authentication.
It’s on the API integration that most issues are discovered, generating significant rework and waiting-time between the teams.
Deliver the API with early end-to-end integration
We can fear publishing an API that is not fully finished. Users will get bugs, raise issues and question our competencies.
An early API integration can raise problems early to solve them faster with minimal costs. You may even discover that structuring changes are required.
That’s the reality the design has to be confronted with.
Face reality as it is, not as it was or as you wish it to be.
—Jack Welch
You therefore have to deploy your API in environments enabling it to directly interact with consumers in the production-like environment.
You will see and solve a whole set of problems fast with a simple API, improving the design and robustness of your product to keep iterating with speed.
Ensure systematic quality gates improvement
We don’t build walls once the foundations of a house are not set. So why do that when building APIs?
Implementing the software delivery chain for fast iteration on the API is necessary to continuously adapt the APIs in short-cycles afterward.
Don’t start by trying to implement all the APIs endpoints and use-cases.
Focus on implementing the CI/CD pipelines across all environments, including minimal quality gates that give you confidence to perform core changes.
That way you have all the foundations to perform rapid increments of your APIs to increase its functional and non-functional requirements.
Close the feedback loop by checking usefulness
Once your API is done, systematically deployed through quality gates in CI/CD, one question remains: Are we creating value?
APIs are there in the first place to solve the needs of the personas. It’s your job to ensure they are met, and that you are able to grow your value proposition.
That’s the area of APIs observability, analytics and growth.
The majority of APIs portal available provide you with a set of metrics of API usage. Your responsibility is to compute them but to make use of it.
It’s only the start of your API journey as you will need to iterate to improve your value proposition. That’s why you need Quality Engineering
Constraining your API pipeline to Quality at Speed
Quality Engineering is the paradigm to constrains the software lifecycle to continuous value delivery.
We covered the various steps involved in building APIs, from design to analytics, ending in the continuous improvement phases.
The elements implemented were not there for beauty or perfectionism; they are necessary to keep iterating with Quality at Speed in the long-run, if needed.
The early checks are minimal on documentation and stubs, sharing with the users, to quickly pivot if needed without consuming any development resources.
That’s the power of Quality Engineering, gradually constraining the software lifecycle to maximum Quality, Speed with minimal Complexity.
Simple things are not necessarily easy.