API Testing for Effective Regression

API Testing for Effective Regression:

While using your phone, have you ever wondered why it’s easy to use ecommerce apps and not their sites from the phone browsers? Because mobile applications work best when they are lightweight and faster. And what makes them so? It’s the APIs developed using protocols such as REST.

The meteoric rise in the no of smartphone and tablet users demanded a new way of software delivery. Bulky software was okay to consume on desktops but not on handhelds. Also, delivering software as service enabled a plethora of developers to consume the services and build their applications without having to re-design the common functionality.

I will use a personal experience to explain what this means. My organization has been traditionally producing desktop based applications. In the recent years, we saw a growing demand for mobile applications as more and more customers were using smartphones for their daily business. Since business logic was already coded we wanted to re-use this and build mobile applications. We used REST protocol to develop APIs which were then consumed by our mobile applications. APIs act as a bridge between the business logic in the legacy system and frontend on your devices.

Our developers created a large no of APIs and started using them to build mobile applications. These APIs performed 4 operations:

1. GET – Perform read operation on a resource and fetch data in the form of XML or JSON
2. POST – Create a new resource in the system
3. PUT – Update an existing resource with new values
4. DELETE – Delete a resource

All that was good and our business problem was solved but we wanted to make sure that when something broke in our system, we were the first ones to know and as early as possible. When you make calls to these APIs they respond via certain response codes and also a response body sometimes depending upon the use case. So whenever a certain resource is down or broken, we would find out if we check these response codes and the response body.

With Go-to-market in sight and Continuous Innovation as our goal, we decided to automate the API Testing. Because you can’t test the health of 100s of APIs manually on daily basis. We chose to do it with soapUI. It’s an open-source tool to automate SOAP and REST services.

We had multiple teams working on mobile apps for different modules in our product. Each team created a soapUI project and added as many REST Services as developed by their respective teams. With the help of Groovy scripts it was easy to build scenarios. Once the projects were tested and ready we started running them on daily basis. This helped us with the daily view of how different services were performing. It was crucial in providing early feedback.

On the contrary, UI Automation is a tedious and time consuming process. I am not saying UI shouldn’t be automated. Both types of automation are important. But UI automation can wait because, APIs are developed and then the UI. If your APIs are not working, app functionality will be hampered and end users will be frustrated. Also, in comparison to UI scripts, API scripts are easier to build and faster to execute. Because they don’t involve UI elements whose attributes are liable to change.

In the competitive environment of today’s software industry, it’s important to have API automation done. It gives early feedback and is easy to maintain.