I keep seeing API testing listed on nearly every Quality Engineering job description I come across. And the API requirements have climbed to the top of the list. I’ve been recruiting since 2016….has it always been this way?
What does API testing actually look like? And how do I know whether a candidate genuinely understands it or has simply used Postman to send a request?
I sat down with my engineering manager, Ryan, to talk through it.
Here’s what I learned:
Why API testing has become so important
To understand why API testing matters, it helps to understand how modern applications work.
An API, or Application Programming Interface, allows different software systems to communicate with one another.
Ryan explained that modern applications increasingly rely on distributed systems and microservices. Instead of one large application handling everything, different services handle different responsibilities and communicate with one another through APIs.
Think about booking a flight. Your application might need to communicate with several different systems to retrieve available flights, calculate pricing, check seat availability, and process payment.
Each of those interactions may involve an API.
Ryan pointed out that this is a major reason API testing has become so important.
Twenty years ago, many applications were desktop-based and relied heavily on local libraries. Today, web and mobile applications frequently depend on multiple services communicating with one another.
And that creates more opportunities for things…to go wrong.
What can actually go wrong with an API?
When I asked Ryan about the biggest challenges, three areas stood out: timing, performance, and data integrity.
1. Timing and asynchronous behavior
Imagine an application communicating with five different systems.
Each system is responding to a request, but the responses don’t necessarily arrive in the same order every time.
One system might respond immediately. Another might take several seconds. A third might fail or return information after the application has already moved forward.
If the application depends on those responses being available in a particular order, unexpected behavior can occur.
This is where quality engineers need to think beyond whether an API returned a successful response.
They need to understand how the application behaves when responses arrive late, out of order, or not at all.
2. Performance and latency
A system can return the correct information and still deliver a terrible user experience.
Ryan used the example of requesting a quote.
The API might technically work, but if a user has to wait three minutes for a response, something isn’t right.
Quality engineers need to consider how long requests take and whether the system can deliver information within an acceptable timeframe.
3. Data integrity
APIs exchange structured data. If that data is malformed, incorrectly formatted, or missing information, the receiving system may not handle it correctly.
Imagine one system sends information to another system.
The receiving system expects a specific structure, but the information arrives incorrectly formatted.
What happens next?
Does the system reject the request? Does it process the information incorrectly? Does that data end up in a database or get passed along to another service?
Or worse, does the user end up seeing incorrect information?
Ryan explained that this is why formatting, structure, and security around API communication matter.
API testing isn’t just about making sure a request works.
It’s about understanding what happens when the request doesn’t behave as expected.
How teams incorporate API testing into automation
I also asked Ryan how teams can incorporate API testing into their automation strategy.
He shared three approaches.
Postman
Postman is commonly used for direct API testing.
Engineers can send requests, inspect responses, and sequence multiple calls to mimic how an application interacts with different services.
This is useful for exploring API behavior and testing how different requests depend on one another.
Playwright
API testing can also be incorporated into Playwright automation suites.
Ryan explained that engineers can create separate API tests or use API calls to prepare data before running an end-to-end test through the browser.
For example, instead of manually creating a customer through the user interface every time an automation test runs, an engineer could use an API call to create that customer first.
This is one way API testing can support a broader automation strategy.
Artillery
Ryan also mentioned Artillery, a load-testing framework that can be used to simulate traffic against an application.
Imagine hundreds of users attempting to log in at the same time.
How does the system respond?
Can it handle that level of demand? At what point does performance begin to degrade?
Load testing helps teams understand how their systems behave under pressure and where performance bottlenecks might exist.
How AI can help with API testing
When I asked Ryan how AI is changing API testing, he brought up data permutations.
Essentially, AI can help engineers generate different variations of the data being sent between systems.
Think about an API that expects a specific data structure.
What happens if you send it something unexpected?
An engineer could manually create different payloads, but AI can help generate additional scenarios to explore.
For example, an engineer could ask AI to generate boundary conditions or variations of a payload to see how the receiving system handles the information.
What happens when the data is malformed? What happens when the receiving system can’t interpret the structure correctly?
The goal is to explore how the system behaves when it receives information that doesn’t look the way it expects.
This is an interesting area for quality engineers because AI can help expand the number of scenarios they explore.
Recruiters: Stop looking for the API keyword
As recruiters, it’s easy to search a resume for the word “API” and assume that tells us something meaningful about a candidate’s experience.
But Ryan made an important distinction between someone who has basic exposure to API testing and someone who understands how APIs behave as part of an entire system.
For example, a candidate might have experience using Postman to send a request and verify that it works.
That’s useful experience.
But what happens when the engineer needs to test a sequence of API calls?
Ryan shared an example involving authentication.
An engineer might need to retrieve a token, pass that token into another request, and then use the information to complete a login.
Those calls depend on one another.
Does the candidate understand how to test that sequence? Can they explain what happens when one of those calls fails?
This is the kind of thinking Ryan wants to see.
Not just someone who knows how to call an API, but someone who can think through how different APIs interact and what could go wrong.
So what should recruiters look for?
Instead of simply searching for API testing on a resume, I want to understand:
- Has the candidate tested APIs independently or as part of a larger system?
- Have they tested sequences of API calls?
- Can they explain how different systems communicate with one another?
- Have they explored what happens when requests or responses don’t behave as expected?
A candidate who genuinely understands API testing should be able to explain what they were testing, why it mattered, and what could go wrong.
Thanks to Ryan Anderson for helping me understand the difference.