0

This is an interview question. What points are they looking for when asking this question, you are using REST API. Check for errors, data accuracy, right status codes?

5
  • 1
    There is no such thing "testing", in the vacuum. Testing happens in a context and a tester has a testing mission. For your question (and for the interview), I suggest specifying what is the testing mission: What information do you want to extract, what risks do you want to explore, etc. Commented Sep 12, 2023 at 11:14
  • Can you give a bit more context? Is this a question you have been asked in an interview?
    – Kate Paulk
    Commented Sep 12, 2023 at 11:41
  • This is the question that was asked in the interview. Should I first ask the interviewer "Is there any API documentation?"
    – chris
    Commented Sep 12, 2023 at 14:45
  • Hey Chris! Seems like you are asking a lot of interview questions. To me, that's fine. The community would like to see more context. To help get answers to your interview questions, can you add how you answered them in the interview? This way, we can help pinpoint gaps or provide alternate ways to answer.
    – Lee Jensen
    Commented Sep 12, 2023 at 17:09
  • 1
    Lee Jensen, thanks a lot! this was really helpful. Appreciate it. I'm new to this interview process, and sometimes I feel so lost.
    – chris
    Commented Sep 12, 2023 at 18:11

1 Answer 1

1

First, I'd recommend to not assume. QA means "Quit Assuming." Assumptions lead to miscommunication and ambiguity, which leads to bugs in the software. Part of being a good tester/Quality Engineer is to ask questions and remove areas of ambiguity. The more context you can get, the better and easier your job will be.

Interviewers tend to give broad/general/open-ended questions, so it's up to you to ask for clarification. Some interviewers ask questions because they are in need of certain skill sets immediately. So, this allows you to pry into what problems they are having. If you are ever confused by a question an interview asks, you can and should ask them for clarification.

What are all the things you will check in API Testing?

All is subjective. Unfortunately, when testing software, we really can't ever get to "all." How can we find all the bugs? We can't; there's no way to guarantee we find them all. How can we find all the test cases? We can't. This is why context matters. All we can do is verify as much as possible in a given time, using testing techniques, and verify against the requirements / acceptance criteria. Requirements are the rules you judge against. And yes, at times, these rules can be wrong.

Is the interviewer giving you an example API? For example: "Here is an API for a weather app." Or, an example of their own API?

Ok, back to APIs specifically.

Check for errors, data accuracy, right status codes? Yes! "Check for errors" is a very generic answer. What errors are you looking for? Get more specific here.

Data accuracy is also generic. How are you verifying the data? Are you checking for data inputs or data returned? APIs utilize both input and output data.

right status codes. Yes, but what context? What does "right" mean? Are you verifying client-side status codes or server-side status codes? Both? What happens if you get a "status 200 with a message: not found?"

As an interviewer, I'm looking to see if you know the difference between 400-level and 500-level status codes. What are the most common status codes? Do you understand HTTP verbs/methods like GET, POST, PUT, HEAD, DELETE. This is bare minimum.

How are you interacting with the API? Are you using the UI/Web-app in the black-box fashion? Are you using tools like Postman or Insomnia? Accessing the API via code for integration testing or contract testing?

What does an end-to-end test look like for an API? Is the API performant? (See my answer to your performance question as it applies to APIs). Are you sending requests and receiving responses in a timely manner? How are errors handled? Are errors logged? Does the status code make sense with the response? What does the API documentation look like? Are you able to look in the codebase to see status codes and responses? Is authorization needed to use the API? What happens when authorization is not provided? Are there different types of users and different levels of user permissions to consider?

Will you test the API by itself as a single endpoint? As an integration test with the UI, database, messaging brokers/queues (ActiveMQ, RabbitMQ), event streams/processors (Kafka), or as part of other API endpoints? Is the API used in a distributed system? Are you checking for race conditions? How are async messages handled?

All these questions can be turned into test cases and test strategies; I'm just forming them as questions for areas to learn and consider as APIs can get very complicated very quickly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.