How do you test a backend API?

Question

I was applying for QA position and the SDET asked me this question:

How do you test a backend API?

In the interview.

I wasn't sure I answered it correctly. Just wondering if I can get some input from someone.

Answer 1

How you approach testing an API depends on a lot of things. Will the API be a public API that will be consumed by some external people/systems, or is it a part of a larger product's infrastructure? API is a general term that is sometimes used to describe anything from a COM interface, to a DLL or JAR you can reference, to a REST web service. Different approaches can be applied to testing these different things.

Often, if the API is part of your infrastructure you can test it pretty thoroughly through unit testing and the use of the product that consumes it.

If it is an externally consumable API then you need to be much more thorough because people could use it in different ways than you might expect and send data in much different formats, etc. It also usually needs to make sense, be intuitive and be well documented if it is externally consumable. You would also need to be more cautious about what is private and public, which may not be as important for an API that is only used by a single product.

Testing an API nearly always requires you to create some sort of consumer for testing purposes. You have to be able to interact with the API. The consumer is usually very simple - or an existing tool - and driven by automated test cases and not manual user interaction, although I have seen cases where people created a complex GUI app for testing purposes, and cases where the testing was still mostly manual through exercising that app.

If the API has dependencies, you may choose to mock those dependencies out so you can more thoroughly test all of those interactions and hit all of the positive and negative code paths. For instance, if the API interacts with a database and has the ability to create, modify and delete data you may want to mock the interaction with the database to more easily test cases such as deleting a record when it does not exist, or when it is the final record, or when it is unable to be deleted because of dependencies or even when the connection to the database is unavailable - you can then see how your API would handle these situations.

Answer 2

Choosing the tool is not the only decision you need to make when testing an API. As for any testing task you need to decide:

1. What aspects of the program are you testing? What application features do you want to cover with API testing? Are you going to verify some stateful scenarios (e.g. when user is logged in)? Or maybe you want to verify how an API behaves for different configurations?
2. What types of problems are you looking for? What part of application is most probable to fail? In what conditions? Are there functional or performance problem? This should help you understand what are scenarios that are easier/faster/cheaper to test with API instead of using frontend.
3. How will you tell whether a test passed or failed? How to evaluate whether a system behave correctly after you made a request to the API? Will you evaluate only explicit API response (e.g. it confirms it has sent an email) or you want also to verify whether it actual did what it says (the email was actually sent your account)? Furthermore, how do you know what is an expected result for a given API call?
4. What tasks, specifically, will you do? Depending on the directions taken in the previous answers, you can think of exploratory testing, when you just explore API behaviour, hunt for some particular bugs, or define thorough test cases in advance? Whether you perform the manually or you automate them? Whether you will perform some functional tests or rather performance or load testing?
5. Who will do the testing? Will you be the one who will test API, or maybe you will have some people who will write customer applications to test different parts of the API? How much do you know about API related technologies to automate the tests? The answer will help you to choose the right tools to test.

Now you probably have too little information to make definitive decisions that could satisfy you, your interviewer and stakeholders in a company. So, you could ask interviewer more questions about the nature of the backend API:

• Who or what is the consumer of the API? Front-end tier being a part of SUT or an external client app? Maybe there is no frontend? Is this a public API or internal used only by a few people? The answer will tell you how thoroughly you should test the API?
• What scenarios have been covered in end-to-end test with frontend included and what scenarios have not been? What are the challenges when testing via frontend? The answers will guide you to the type of scenarios you should cover and those you should not. For instance, if invalid input validation functionality is implemented only on the backend side, this is one area to stress in API tests.
• What technology is used to expose an API? SOAP or REST Web service, RMI, CORBA, command-line, COM, etc. The answer will imply what kind of tool or programming language you should use to implement test cases.
• Is there some formal specification for API? Or you need to guess an expected behavior somehow, e.g., from specification for UI?
• Does the backend talks to other components in the system? To database? Does it contacts external services?

Answer 3

In general I think you should not expect a mocked front-end that's hooked up to the API calls for testing (however if you have one lucky you!). Instead, API functions are generally tested with unit and integration tests.

You'll need visibility into the API function calls themselves, so the testing will be white-box or at least grey-box. You should be provided with a Specifications Document which should list the signatures of each API function (the input parameters, the function or method name, and the return type). Then from the Spec Doc you'll write unit tests (in my case I prefer PHPUnit) to sanity check the input and returns for each API function, such as testing for boundary values and null inputs.

Lastly, if the API is part of a service you'll also want to to integration testing. These tests will be similar to "end to end" tests for the service where you test entire features that include calls to the API functions. You'll typically begin an integration test at a customer entry point, and verify the return as valid if it's correct for the customer. Personally I prefer Behat Mink or Cucumber for my feature tests.

That's my high level overview of how I would go about testing an API, hope that helps!

Answer 4

There are a couple of areas that you will have to understand and provide focus in testing.

• Understand the Purpose of the API that you are testing. What is it for? How is this going to be used? Answering these questions should provide you with test ideas related to your context.
• Here are Sample Test ideas based on my personal experience in testing:
  1. Input Data
     • where is your data coming from? a database, another api, etc.?
  2. Data/Application Logic
     • How is the Data Parsed?
     • Is there a required schema or format so the data can be parsed?
     • How is the parsed data stored?
     • Does the data need further "massaging" for the output?
  3. Data Output
     • What are the API endpoints?
     • What are the value types for each endpoint (string, integer, etc.)?
     • What determines the correctness of the value in each endpoint?
     • What is the API protocol that's used? (REST, SOAP, etc.)
  4. Delivery
     • Are there special rules regarding account access?
     • Are there usage limits?

There are a bunch of tools that you can use. Various chrome and firefox plugins will make your life easier when it comes to functional testing. SOAPUI is a pretty handy desktop client as well. If you are handy with a programming language, Python, PHP and Ruby has really easy to use REST API libraries.

Mocking is also a way to minimize dependencies, but this can get out of hand if not used properly. I've always liked using mocky.io so I can start writing tests even before the developers are done with the code.

Answer 5

Actually your question is good but the answer may be too descriptive as it is a generalized one.

We are in the domain of Online Media. The part of backend API testing that we used to do includes :

• First of all we understood the functionality of the system where the role of API comes in.

• Then we developed the end-to-end tests using JS and those API which are working in backend.

• Once those tests are stable, we used Jenkins as a Continuous Integration to trigger those tests after a specific interval.

• Then we used to observe the results in the output of Jenkins test. If the tests is pass we are green to go, but if it failed then we used to investigate that and then a bug can be filed on that.

In this way we used to test backend API.

Answer 6

In back end API testing, the tools you use depend on the type of API that needs to be tested.

• REST services: for HTTP GET method you can simply use Web browser, for other HTTP methods you may need a separate tool, e.g. Postman add-on for Chrome, curl Unix command or SOAPUI.
• SOAP services: you need dedicated software, e.g., SOAPUI.

Answer 7

There are different ways one could answer this question:

1. Start by naming 1-2 tools that could be used for API testing e,g, swagger, postman, soap etc.
2. Use an example to present how you would approach an API testing problem e.g. use-case: logging onto a page redirects the user to another page - what is the POST command, review payload response and note check for whether there is any sensitive information that gets exposed during redirection etc.

Most often the interviewer is trying to assess your approach to a problem and whether you are aware of existing tools that could be used for the test.