Why Centralize API Testing?

The Benefits of Centralizing API Testing

When we started building API Fortress in 2014 there was a single word we kept returning to – centralization.

Centralization.
cen·tral·i·zation
Noun. The action or process of bringing activities together in one place.

At the time (and still today) the most common tools for API testing were desktop applications. APIs, at their core, help define what it means to be cloud. So we believed it was necessary to be able to test those APIs from the cloud as well. It was the only manner to guarantee true centralization of the work and tests. Since our initial concept there have been some small adjustments, but the core goal has remained the same. What we didn’t necessarily realize at the time was how this centralization touched so many different parts of common problems faced by companies. Problems resolved by centralization:

  • Team Siloing
  • Redundancies
  • Automation
  • On-Premises
  • Data/Result Sharing

Team Siloing
Every day we speak with a company dealing with this specific pain point. Large companies, and even some SMBs, leave the testing of APIs to the teams that create them. This makes a lot of sense, but ultimately leads to every team using their own tooling or process when it comes to testing. It is expensive to buy a bunch of seats to a desktop application, and that doesn’t help with the siloing. Furthermore, creating your own testing suite from scratch requires time, a lot of money, and is very hard to maintain and scale. Ultimately, this silo effect keeps organizations from saving time with collaboration, costs money due to redundancy, adds complexity when shifting personnel between teams, and makes data and result collection with 3rd party platforms a huge headache.

Redundancies
We thought this problem was straightforward, but its effects can be much more nuanced. It seems reasonable for there to be a single place where all tests related to the API program, no matter what team created the APIs or the tests, can be found and easily used. What we didn’t expect is the shocking amount of redundancies between developers, QAs, automation engineers, and DevOps. What we’ve learned is that in some companies each team is testing in their own manner. Going back to the silo issue, but even worse was the incapability to hand off the tests that were created. A team of testers would often not be able to leverage tests created by developers, and then the testers would mainly do manual exploratory testing. When it came time to build/deploy and monitor those APIs, the automation team created their own suites of tests, and DevOps would setup basic ping/APM monitors for API uptime.

All of these tests can and should be the same. One testing language, leveraged by every stage of the lifecycle. It seems crazy, but most companies are writing/building the same API tests 3/4 times.

Automation
This one was slightly unexpected. In 2014 CI/CD wasn’t as common as it is today. The switch for companies wanting to innovate faster, and therefore deploy faster, really caught on shortly after. This left manual testing of APIs as the last remaining bottleneck, as Selenium and Appium had made automation of website and app testing simple. With the shift to centralization, to us that meant creating a cloud platform dedicated to API testing. Interacting with that platform from the browser, or command-line requires APIs. That’s the key to unlocking a seamless method of API testing automation. A platform built on APIs, for APIs. This creation of a cloud platform also led us to…

On-Premises
There is one fact when it comes to working with large organizations – security is paramount. Every hack is millions in lost revenue, or billions in lost stock valuation. Building a cloud platform to allow for centralization is great, but that data needs to be secure. This was a shift we didn’t expect to be as serious as it is today. Over 70% of our customers are using our platform on-premises. Deploying our Docker/Kubernetes entirely behind their firewall in their environment. This gives them complete control over every aspect of API testing.

What is interesting is that this also solved for another headache – environments. Dev and staging environments are typically enclosed behind a firewall for security purposes, and a cloud platform can’t hit those environments unless it is also behind that firewall. By being capable to be deployed 100% on-premises, we solved both items at the same time.

Data/Result Sharing
This problem touches on the silo effect, and the benefits of a platform with APIs. It seems straightforward, but companies rarely consider the effects until it is too late. Every test and test result generates useful data, and can help a company recognize trends in overall product health. That data should be easy to read and in a single place. The problem is that every different method of API testing has their own unique method of reporting. Many have limited test result information, and most don’t even have APIs that allow for real-time data to be sent to platforms like Splunk, Tableau, or Datadog. The saying is that “Data is King,” but that data is useless if it can’t be compared and unlocked for greater insights.

Our goal since 2014 was to help solve for the one problem that we found in almost every company – a lack of centralization. We have dedicated 4+ years to building a platform that can help fix this for API testing. We did our part, so now the next choice is yours.

We asked three recent customers why they chose API Fortress at the time they did. Here’s what they said:

  • “I want to fix this before it gets too big.”
  • “We’ve been wasting too much time and money by putting this off. It’s time.”
  • “It will take years to fix this across every department, but I want it to start with us.”