A Micro Manifesto on API Testing to Inspire and Recharge Your Organization

A Micro-Manifesto on API Testing to Inspire and Recharge Your Organization

In this paper, Software Development Technologies Founder and CEO Ed Kit decrees it’s time for everyone, everywhere, to accept the need for API testing, and provides us with 13 tips of inspiration to build the energy to get it done.

After 25 years of leading many software engineering projects at small and large Fortune 200 companies, I have come to a major realization. Application Program Interface (API) testing is more important than User Interface (UI) testing. In manifesto terms, API testing over UI testing. This is not to diminish the value of UI testing – I simply wish to inspire you to value the item on the left (API testing) more!

We can finally close the API testing productivity gap and offer development and test teams the equivalent or better level capabilities than have been experienced with UI and unit testing. A comparison can be made between API testing and UI testing to fairly criticize how far behind API testing is in being productively performed within the overall life cycle. Every level of testing presents unique challenges, unique design approaches, and unique tools, but current insights, technology, training and new third party services have changed that for API testing.

We will get to the important inspirational facts and recommendations soon, but first, here’s a quick overview of why API testing is so important now.

API testing Overview

Applications efficiently and powerfully communicate with each other using a common language, or Application Program Interface. Testing at the API level is a critical part of technical software testing, between User Interface Testing and Unit Testing. With API testing, APIs are tested directly to determine if they meet expectations for functionality, reliability, performance, and security. When an API has not been adequately tested and does not behave as it should, (potentially very significant) quality, privacy, and security defects ensue.

At the API level, we can automate testing for:

  • SOA (XML, WSDL, SOAP, GZIP, etc.) Web Services
  • RESTful (JSON, RAML, Swagger / Open API, WADL) Web Services
  • Microservices (Kafka, RabbitMQ, MQTT, WebSockets, etc.)
  • Protocols (HTTP, JMS, MQ, TCP/IP, SMTP, Tibco, etc.)
  • SQL (JDBC, ODBC, etc.)
  • Message Formats (Swift, EDI, etc.)

Sound overwhelming? Testing APIs is technical, and therefore can feel a bit scary at first – that is, until we understand what is really involved. I believe that API testing is the most important type of testing that has been routinely underperformed in most organizations.

The good news is that as an industry, we are considering the API from a testing perspective now – we don’t have to decide on RESTful versus SOAP. We just have to uncover the information related to the specific API under test.

As the CEO of a testing firm that has been in business and watched trends for 25 years, I am happy to report that API testing is now the most requested form of testing coming into my company, Software Development Technologies (SDT). This year marks a tipping point for SDT, actually. I never predicted it, but after 25 years of providing every type of testing service possible, this is the first year we are doing more API testing for clients than any other type of testing.

It may sound obvious, but since application communication occurs at the API level, this is the most efficient level at which to perform testing. The tests that are designed, implemented, and executed at the API level will interact directly with the underlying APIs. Duh. And yet so many teams aren’t testing APIs – sometimes the result is the customer does the testing for us, much to their chagrin.

So here are my 13 points of inspiration and recommendations about API testing, which I’ve categorized below.

API testing: Critical for the Customer

1. The Internet of Things (IoT) touches everyone today and, since the typical user interface doesn’t exist there, API testing is critical. API testing is required to get the IoT testing job done well.

2. Hackers will attack vulnerable software at the API level, so security testing must be done at the API level. We protect the customer by performing malicious penetration attack testing, etc. at the API level.

3. With Agile, fast feedback beats slower feedback. API testing provides fast feedback, so the customer does not have to wait for a quality delivery.

API testing: Critical for Lifecycle Efficiency

4. API tests can be designed earlier in the development process, before the UI is known. Testing against the UI takes longer than testing at the API level. Who can afford the Build cycle delays due to the longer UI test execution time?

5. When we perform API test cases before the UI test cases, we can skip the unneeded UI test cases that add no value.

6. API tests are less brittle than UI tests and thus stand up better to software changes over time.

7. API tests tend to be easier to debug, because of their focus.

8. Far fewer UI tests are required when you have a sufficient number of API tests. UI test cases still have their important place.

9. API tests have a longer shelf life than UI tests. When API testing has been put in place, it tends to stay current longer than UI tests. This is because the current approaches and technologies lead to more maintainable solutions over the long run.

10. You can incorporate API testing with CI/CD/CT (Continuous Integration / Continuous Delivery / Continuous Testing) into your development process – at SDT we usually use Jenkins.

API testing: Critical to Do, and Do it Right

11. Find the right owner for your API testing. In a recent study, 80% of developers said that the Test Organization is responsible for API testing, and 70% of testers said that the Development organization is responsible for API testing! Sounds like a joke – but it’s not a joke.

In most organizations, it’s not realistic to expect the developers to own API testing. If your developers have taken ownership of this and are doing a great job – fantastic – let them have it, but in my experience, in most organizations, they are not doing it now and are not going to start doing it anytime soon. Their plate is full – if they are doing Unit testing well, be grateful.

Maybe the test team should own API testing, but my experience has shown that testers don’t know how to test APIs – technically it is far beyond the capabilities and bandwidth of the average person on the average test team.

Consider partnering with an experienced, independent third party services provider specialized in API testing – someone who can demonstrate their skills and experience with API testing and related technologies. A partner, passionate about API testing and the process and the technology, can design and implement the testing framework and get you up and running fast. At the very least, it is worth having a conversation with a potential partner to determine the value they can bring to the table.

12. It is important to find the right tools for API testing. API testing tools have been weak in the past, but that has since been addressed.

Manual testing tools can get you started on API testing. Our SDT testing services teams have used Postman for initial manual testing – to explore the API and assist with API test design. But manual testing without automation is a formula for failure – repeatedly running the same tests manually will not meet the demands of today’s Agile world and will not give sufficient coverage for the complexities of today’s software.

Many are familiar with using Keyword Testing for key test enterprise challenges associated with Cloud, Web, Client/Server, Java, Mainframe, Embedded devices, Mobile, and Desk, but this excellent approach also works for API testing!

Keywords are the basic, reusable building blocks for Keyword-Driven test design. A Keyword Test Case is a sequence of Keywords with parameters, and Keywords define actions that drive or get information from application elements. A higher-level Keyword usually consists of lower-level Keywords. Reuse of Keywords ensures rapid test development and easier maintenance. APIs can be viewed as building blocks, much like Keywords.

The open source tool Robot Framework adds a Keyword-Driven test case paradigm to provide significant reuse of artifacts (low level Keywords, high level Keywords, test cases, and test sets) and a built-in library to reduce test development effort and to simplify maintenance.

Just as Selenium is a plug-in to Robot Framework that drives web application behavior and validates results using a rich library of methods (low level Keywords), HTTPLibrary and the Requests Library are plug-ins that drive API testing. The Python language is often used to create custom low level keywords.

13. When you’re ready, you will find key drivers that signal it’s time to consider an enterprise solution.

First and foremost is a desire to achieve higher levels of test coverage for more complicated use cases, e.g. non-SOAP and REST interfaces, Microservices, ESBs, or databases. At this maturity stage, organizations look to enterprise API testing solutions. When you are ready for a full-feature commercial solution for API testing, check out SOAtest from Parasoft.  Parasoft SOAtest is widely recognized as the leading enterprise-grade solution for API testing, and will help you get to the next-level of API testing, for scaling via next-level technologies and features.


API testing is experiencing a surge that UI testing has already been through. Perhaps your single current greatest opportunity for improving software quality is API testing. Want to do something great for your company? Tackle API testing – be the champion – use this blog to help make your case – write your own micro-manifesto for your company, and let me know how it’s going. I’m serious – email me at kit@sdtcorp.com.