Let’s look into how API testing helps reduce churn rate and quicker time to market and how to cope with it in the Agile environment.
API testing is often under-rated in the fast-paced Agile world. With frequent changes and early time to market, testing application with a UI interface is more acclaimed then testing API with only from a functional point of view. Since the world is more biased about looks these days then the internal functioning, API testing is usually been put at the back seat. But API testing not only helps reduce the churn rate of software lifecycle with bugs encountered early in the software development lifecycle but also helps in speedier project/product shipping to market.
API stands for Application Programming Interface. Lets first understand where does the API fit in an application. An application consist of three layers:
Data Layer– Data is retrieved from the database and file-systems and then stored.
Logic Layer– This is the brain of the application which processes the data between the layers in which it is sandwiched. Complete business logic resides in this layer and processes the data and send the required information to the application layer. This layer is made up of API
Presentation Layer- Also known as the client layer. This layer is visible to the end user and helps in accessing the several web pages of the application. This layer communicates with the logic layer and passes the information provided by the end user.
Therefore, whenever we come across people that talks about API not having a User Interface is because it lies in the logic layer and takes care of the functionality part of the application. Testing those API’s is known as API testing.
Testing the API’S
API testing is not a rocket science. It is equivalent to a tester testing an application but without a user interface. The approach towards testing it from the functionality perspective still remains the same. For example, if the user is testing a sign-up(create user) API, the approach of testing across the different parameters(fields) remains the same. Let’s say for creating user one needs to provide an email address and password. As a tester, you may tend to look out for the mandatory check across those fields, email format, password complexity etc. The same should be looked while performing API testing and verifying the response(result) with these scenarios. API testing can be performed via various tools available in the market like POSTMAN, SOAPUI, SWAGGER etc
Testing API before UI is built, helps uncover functionality issues earlier, which leads to fixing them earlier and hence leads to lesser bugs discovered post UI is built. Once UI is available a tester can focus more towards UI/UX of the application and thereby providing faster closure of testing cycle. Thereby leading to smaller churn cycle of SDLC, and quicker time to market. Having said so, as a tester it’s important to perform a quick cycle of functionality check post UI is been developed.
Please Note– API testing can also help perform security testing, performance testing and data volume creation. Since this article deals with coping up with API testing in agile, I would be focussing more towards that front. My upcoming articles on API testing will talk about performing security or performance via API testing in detail.
Agile is a fast-paced incremental development methodology, where smaller chunks of functionalities in forms of user stories are built and delivered in iterations to the end user. With its nature been fast paced and iterative the scope of testing as an activity keeps on shrinking due to multiple issues encountered by Testers in agile(Refer my article Agile Testing Challenges and their Remedies ) and hence bringing API testing into the picture is even more difficult and painstaking.
As a key point in agile its important that development and testing teams work parallelly and all stories in a sprint are closed and delivered. To encourage smoother workflow teams can collaborate and coordinate together such that each story can have backend and frontend tasks defined. As testers, we should create test cases taking into account both the backend(API) and frontend perspective of the application. As the back-end task get ready we can kick-start with API testing and with the completion of the UI part, we can take over the full fledge testing.
Some projects or organizations tend to perform testing across technical tasks which are API by QA. But it’s important to remember those will never be accounted as part of a deliverable from an end user perspective owing to its lack of visibility to the customer. Hence it’s a good approach to split your user stories into backend task and frontend task so that both API and UI issues can be logged across the same story and helps create better statistics at the end of the sprint for your sign-off reports and defect analysis reports.
Since API testing takes a certain amount of effort in testing, it’s important to ensure no redundancy in terms of testing is performed post UI is ready. Owing to this nature major of the organization do not encourage API testing. For example, I have come across testers who test the functionality deep driven at the API level and the same set of tests all over again once the UI is ready. Of course, this may help to provide you double checks of any possibilities of bug leakage but adds on to the testing efforts and does not serve any major purpose for performing API testing initially. In fact, it somehow defeats the purpose. It’s important to ensure the same sets of tests are not repeated at both API and UI testing. A quick functionality check though is recommended once the story is full fledge ready with the User Interface.
As part of user story testing, API testing is encouraged but as part of the regression cycle, opting out API testing suits to both the testing team and the whole agile world. Since deep driven testing is already performed at the system level, regression can be performed at the frontend level with various functionality checks performed along with it.
Once API testing becomes part of a process of the testing lifecycle, all other activities of agile will accommodate accordingly. It’s important to understand where to introduce API testing in your Agile project and where not to. API testing seems a fancy word to many testers out there but having the visibility of its usage and its benefits should be weighed upfront. There may be scenarios where lack of time, project needs/ budget, meeting all ends to perform testing is required then choosing a harder parameter of quality i.e API testing may seem insane. But having said so, API testing does add to your quality levels and uncovering bugs earlier with faster time to market over the time as we learn to go along with it.
Quote of the day-
. “Testing is a skill. While this may come as a surprise to some people it is a simple fact.”
Author: Sadhvi Singh
About Author: http://www.theqavibes.com/p/about-author.html