With the use of APIs rising across the software development world, it's now more important than ever to make sure they're working as expected. Nowadays, many applications expose useful functionality that allows developers and customers to use these systems as they see fit, without relying on a predetermined interface. This flexibility has made APIs an essential part of organizations everywhere. If your team develops or manages an API — whether for internal use in a single application or a publicly available service with thousands of consumers around the globe — it's crucial to ensure everything works as intended.

Typically, accessing an API is a relatively straightforward process. One application sends a request to the API, and it gets a response in return. The response will vary depending on the type of request made. Maybe the application sent some required parameters or authentication headers to receive a valid response. Sometimes you'll send optional data to filter out some of the information. On a basic level, testing this kind of functionality should be easy, right? It is mostly simple — but only if you know what the API has to offer.

In an ideal world, each API you need to consume or test will have a complete set of documentation, showing each endpoint and ways to use it. But the real world isn't as rosy as we'd like. It's not rare to encounter an active API that doesn't have the appropriate documentation or no documentation at all. API developers are pretty bad at documenting their work (I should know — I've built my fair share of APIs with zero documentation for others). Also, external factors like deadlines or organizational issues can lead to this critical step getting pushed aside.

If you find yourself in a situation where you have to validate an API's functionality without any notes or information about how it works, what can you do? While it's a bit of a struggle to get to the point of understanding the API's functionality, it's not a completely lost cause. With a bit of probing and investigating, you can gather enough pieces of the puzzle to allow you to get on with your testing. Here are a few ways you can move forward with testing HTTP-based APIs even if you have zero documentation available to you.

Check the API's current usage

If you or someone on your team is responsible for testing an API, it's presumably because it's still in use and likely under active development. That means you'll have plenty of opportunities to get a glimpse at what the API does and gain the knowledge to begin your path towards discovery. There's no better way to know precisely how an API should work than seeing it in the wild, getting put through its paces.

Thankfully, we have all the tools needed to gather the types of requests and responses necessary to test your APIs. For APIs used in a web application, your browser provides everything you need to collect this information. Most modern web browsers have ways to inspect network activity, like Chrome's DevTools, Firefox's Network Monitor, and Safari's developer tools. Using these tools, you can discover requests and responses sent to an API and examine the data and headers used throughout the process.

For non-web applications, like desktop or mobile apps, it's not as straightforward to capture its network activity, but it's still possible. First, check if your organization's development team provides test builds of the application. Most companies developing desktop or mobile applications will create early builds to help with early testing. These test builds come with various debugging settings switched on that may include logging its interactions with an external service.

If you don't have access to a test build or the test builds don't provide you the information you need, not all hope is lost. You can set up a tool that can intercept network requests made from any source on your computer. One such tool is Telerik Fiddler, a web debugging proxy tool that will collect tons of information from your network traffic and allows you to inspect everything that happens when an application is running locally. These types of network inspecting services will give you enough details to get started with your testing.

Look around the API's source code repository

For some testers, particularly those without programming experience, it might feel intimidating to dive into the source code of an application. However, the code repository is a gold mine of information that can give you what you need to begin with your tests without any documentation. If an API is still under active development, it's the place where you can find the most up-to-date information about any application.

For testers who can understand the basics of programming, digging into the codebase and poking around can help you learn the structure of an API. For example, web application frameworks like Ruby on Rails and Django typically have a single place that defines how requests get dispatched to different methods in the codebase. Scanning these files can show available endpoints and their individual actions, which you can use as a guide to explore further. Depending on how much of the code you can grasp, it can provide almost everything you need to get you moving.

If you don't have much comprehension when it comes to programming, you can still find tons of valuable information inside the code repository. The developers may have a pull request workflow, which keeps a record of new functionality or important bug fixes made throughout the software development lifecycle. Some teams keep a list of updates and write release notes for each deployment to production. You can also scan the list of code commits for useful messages for each change (be careful, though - many developers aren't the best when it comes to writing commit messages).

Even with documentation available for an API, it's still a good practice for testers to scan the codebase or repository if possible. Tight deadlines, time crunches, and other problems within an organization can make documentation out-of-date or misleading. For instance, I once built an API for a web application and incorrectly documented some attributes with a different data type. A frontend engineer using the API followed my documentation without verification, only to discover a few bugs after completing their work due to my oversight. It's always helpful to double-check straight from the source.

"Borrow" a developer for a few days

In the case that you don't have access to the code repository, can't use test builds, or can't get tools to intercept network requests, one of the few remaining options is to seek the assistance of one of the application's developers. For applications built within your organization, try to reach out to the development team so they can shed some light on the API. They know the ins and outs of the system and should have the answers you need.

When you need help from a developer, try to be mindful about how you ask for assistance. Two mistakes I've seen many testers when reaching out to developers is asking questions without attempting to resolve the issue themselves or sending them a barrage of questions at once. These ways of communicating will make others defer or avoid your requests altogether. If you show that you tried to figure out the issue and are still stuck, you won't receive any push back, and they'll take the time to help.

One trick that can speed up this process is to "borrow" a developer to explain the API so you can have enough details for testing. This idea comes from the book The Experience Maker by Dan Gingiss. Dan is a speaker and customer experience coach and discusses some of his work with a large organization. His team collected data on the pain points the organization's customers experienced while using their website. Most of the issues were minor in scope but had a significant impact on customer satisfaction. Instead of writing tons of small tickets that would likely get ignored, he scoped out a two-week project and "borrowed" a programmer. Together, they tackled all the problems, and it significantly boosted their customer satisfaction scores.

I know that in some organizations, testers and developers don't interact much with each other for various reasons. Still, it's in the interest of both teams to help each other, so don't be afraid to reach out for help. Don't expect others to write detailed documentation or build automated tests for you, though. The key is to collaborate with the development team to point out the areas that you and the rest of the testing team need to focus on with your work.

Remember to leave things better than you found them

As you progress through the journey of gathering and organizing information to test an API thoroughly, don't keep these details to yourself or the testing team. Whenever you pick up a new piece of the puzzle that isn't written down somewhere, make it your goal to document it somewhere for others to access. This practice will not only make it easier for you to keep track of the things you've discovered, but it will also help the rest of your team far beyond your testing work.

Writing down API documentation doesn't have to become a formalized process that will take tons of time you could better use for testing. You can begin with writing unstructured notes in a text file on your computer or a shared document on the cloud. As the information surrounding the API usage becomes clearer, you or someone else on the team can begin structuring this information in a more formalized manner. If you're responsible for writing automated tests for the API, this documentation can even take form inside a fairly self-documented test suite.

Some testers reading this article now might scoff at the idea that they should use their time on writing documentation, thinking it's not their responsibility. My argument is that quality is the responsibility of everyone on your team. Quality doesn't happen only in development or testing — it happens in everything the team does, including documentation. Without a clear guide, it's almost impossible to expect a high level of quality across every role in the project.

Summary

With the rise of APIs in modern applications, testing them is not an optional, "nice-to-have" task - it's a necessity. We would all be happier testers if the APIs we're responsible for testing had all the information we need at our disposal. Unfortunately, it's not a given on many teams or organizations. It's not uncommon to work with systems that don't have any documentation available, leaving us to dig for the details ourselves. But how can you even start when there's nothing to guide you? It can feel like an impossible task, but you have some options to collect the information to ensure your essential APIs get the testing they need.

You can look at any existing API usage in real-world scenarios to understand how it's getting put to work. If you have access to the source code for the application serving the API, poke around since it might contain notes and other details that can paint a clearer picture. If you've run out of ways to learn about the API, enlist the services of one of the application's developers for a short period and help each other build a high-quality service together.

More importantly, don't forget to assemble your findings to help your fellow team members. Take the time to organize and fill in the missing gaps of the API's documentation with the information you gathered along the way. Even if it's not your direct responsibility, it's up to you to help everyone build a culture of quality in your organization, and your documentation will help with those efforts. You can make your work environment a better place for everyone around you, piece by piece.

What other tips help you test an API when you lack enough information about the service? Share any advice that can help your fellow testers by leaving a comment below!