APIs are probably the best way to deal with the flow of data from one end to another. They provide a JSON based response that is easier to handle and read rather than fetching the same values with backend calculations. They not only help us in our own application flow but help in inter-application communication too. For example, If you want to fetch data from another application or a third-party database like Oxford dictionary, you can do that by leveraging their APIs and processing at your end. Since you do not need any GUI for this, they become an easy-to-implement feature for developers. The result of this high acceptance is 24400 publicly listed APIs on ProgrammableWeb alone.
Something this important needs to be as secure as possible too, so that the data does not end up in the wrong hands. As a tester, keeping in mind the best approaches for API testing can help us secure our servers and provide quality APIs to our clients, individual third-party developers or our own developers. If you are unaware of what API testing actually means, the next section will help you brief out.
What is API testing?
API testing is a process of testing the Application Programming Interface for its scalability, security, reliability and functionality. Since APIs have now become an integral part of software development and a lot of things rely on them, API testing has a lot of weight when it comes to the SDLC.
In the absence of a GUI and global data flow notation standard as JSON or XML, API testing does seem a bit easier to perform than other GUI/programming language based testing.
Performed at the business layer, API testing can easily cope with the application aiming to scale big with frequent modifications in the backend. This can facilitate the release cycle timelines.
API testing may seem a bit straightforward but APIs contain a lot of confidential data sometimes which makes them vulnerable to attacks. As a tester, we can never risk the quality of APIs and compromise on its testing process. Therefore, the best path to choose is to consider the best approaches in the game and follow them for effective results.
Plan before implementing
If you have tested APIs in the past or have done any other type of testing, it is quite tempting to start writing code (scripts) as soon as the task is given to us. This can prove to be a rash decision and ultimately cost us in the testing department.
The best approach in this area is to create a requirement analysis of the API tests that may contain every information you may need. First, plan the API tests. These need not be extremely strict for practical purposes but will give an idea while refining them later. Once you have created a basic plan, analyze the boundaries and focus especially on them. Boundary cases sometimes do fail when the application starts to grow to a large scale and APIs start carrying more data.
Lastly, refine the plan/test cases that you have documented. A thumb rule in refining test cases is to ask questions related to the APIs, their purpose of development and your application’s goals. For example, what are the types of data your application is serving through the APIs? What are the API dependencies in the application? Which API depends on which other APIs etc.
Once you have thought about all these questions and their answers, the test cases won’t take too much time.
Do not write complicated tests
Complicated test cases sometimes seem like they are solving complex problems. This is a myth. Neither development nor testing needs to be so complicated that your peers cannot understand it.
Complicated tests work fine when executed along with other cases. The only problem is the debugging and future prospects related to these tests. Complicated tests are not easier to remember even by those that write them. Two months down the line, the writer of that test will also take some time to understand the logic behind it. If he leaves the company, the person now working on the project will take even more time to get the idea.
The best approach is to ditch complicated tests as much as possible. If you can write multiple test cases in place of a single, nested and complicated one, please proceed towards it. Also, remember that each such test case cannot be simplified or broken down into pieces. Some test cases would either lose their relevancy or will start meaning something else which we don’t want. Keep those ones intact for a better API testing experience. But keep the number as minimum as possible.
Always create negative test cases
A lot of the time when we are accustomed to the functionality of the system, we aim to only “verify” it through testing. In other words, we check if it actually works like what we think or not. With this approach, we ignore a possible case of what would happen if it also works successfully in scenarios when it should not?
For example, let’s say we have an API that provides weather information based on the location we pass in the form of latitudes and longitudes. Verifying this information based on practical latitude and longitude is alright. But what if some user inputs a latitude value as -192, hits the API and still gets some random response?
APIs have a wonderful feature of working on various status codes representing various types of responses. Make test cases that take the invalid values and verify that they do not work. This is called negative testing and is a good approach for API testing to look forward to.
It is not just about functionality
One of the things we as testers need to keep in mind is that APIs are a bit different than something like the user interface of a website. If a user interface is not rendered on the screen properly and elements are all misaligned, the end-user is very quick to notice the server/network problem. Hardly there will be any user who will believe that to be the actual UI of the web application.
APIs are different. If some data is not populated on the UI or APIs are not able to transfer the data from the presentation layer to the business layer, the user won’t be able to point out the API directly. The end-user might think that the web application has faulty functionality.
The problems in APIs are hidden and for a tester, therefore, API testing becomes a responsible job. There can be numerous reasons for it, for example, you scaled pretty well but you are using the same low-bandwidth server to cater to all the million requests. This needs to be tested. Another good example is the environment in which you tested and in which the server is and again in which the user is. A change in environment can raise a few errors and we should always be prepared for that.
The best approach is to look beyond the functionality. Do not just limit yourself to data verification and testing various endpoints. Environments, the system under tests and anything in between can help you create a reliable system for the end-users.
Use a complete API testing tool
Lastly, once you have planned and learnt every aspect of approaching the API testing correctly, you need a complete tool that will help you from start till the end. Here, the definition or listing down the characteristics of a complete tool is not justifiable. Everyone faces different scenarios and works in different environments. For you, maybe just a simple manual API testing tool is enough because of the low scale or budget etc. For me, I might not be able to settle without bringing automation into the picture.
To give you a starting reference and help you experience quality API testing, I am going to introduce you to a unique and efficient API testing tool – Testsigma.
Testsigma has been a frontrunner in popularizing the shift-left methodology in automation testing. It provides a simple to use interface that takes English based input. As a tester, you don’t need to worry about writing complex programming codes to create and run API tests.
Testsigma also provides methods to validate APIs using different HTTP methods or combining them to one integrated test. It helps store parameters as data profiles helping testers run the API tests on different data without making any changes to the script. This helps save a lot of time and test APIs on large inputs.
Along with this, this open-source tool offers even more to its testers such as validating API responses with different methods and reusing API response data automatically. The best way to know all the strengths of a tool is to use it. If you like this small feature list, there is a lot more to explore by signing up for a free plan!!
What’s your approach?
I hope these approaches will enhance your API testing strategies and bring fruitful results in your next project.
But with experience comes wisdom and I am sure you must have created your own approaches purely based on your professional experience. We, at Testsigma, would surely love to hear some professional experiences that can help community members throughout the world. Hope to see some great comments. Till then, happy testing!!
