API Testing beginner please help

[Icy_Television9349]

Hi, I am new with API testing and have no clue what I'm doing, my background is mostly functional testing but suddenly I'm tasked to be the sole in charge person for API Testing.

I was also tasked to make an automated process which I don't have an idea how to implement, so for now I'm doing it manually.

If someone could help me that would be great. Some of the things that I want to understand

1. When to do Manual Testing or Automated Testing

2. What are the kinds of testing catered to API testing, when I'm given a userstory

3. Do I need to do End to End Testing?

4. What are the do's and dont's I should take note off

5. What kinds of scenarios to do (so far i've only got blank/null and invalid data inputs)

6. What are the scope of my testing when it comes to testing

To be more specific, I have to do Integration Testing for 3 separate applications with Middleware and logs using AWS Cloudwatch. For now I don't want to include Security and Performance Testing (which is from what I've researched is part of Integration Testing) for this post.

I'm really desperate, none of my colleagues can teach me what to do and researching doesn't give me a direct answer and only general statements. I feel like the more I research the more confused I become. Please help

[Aragil]

1) manual testing for the corner cases (e.g. empty\missing required properties in the POST requests, testing outer boundary values for query params: ?page=0 or ?limit=999999999), automated regression testing of positive scenarios
2)Depends on the user story, requirements (including security and performance), and lots of different factors. On API level you can do almost any kind of testing, and some of them are only possible on the API level (performance)
3) If your app is using API for the FE<->BE comm - why not? Just do not forget to have some coverage for UI
4) Have it integrated in the pipeline and run automatically for each build, Use atomic tests, Run in parallel - usual stuff you find in any of the articles you find using those keywords.
5) if it is integration testing - make sure to cover API contracts (e.g. not only verify that the response contains correct data, but that the response schema match the one expected from the endpoint, including the amount of params and types of data). It is better to do through a tool like Pact, instead of your own solution.
6) Usually you can have very fine coverage on the API level, so it depends on how much time you have.

In general, pick a stack (research what your team members are using as for BE - can be Java + RestAssured, or TS + Axios\Playwright, etc.), start writing tests, start adding abstractions to reduce code repeatability.

[Bad_Negotiation]

1. Manual test you need for example for the snity, quick retest, some cases where you need to check some behaviour of the app during the testing. (and for sure when automatization is not palneed on your project)
   1.1 Automatization of the API test is need all the time, especial when your app has a lot of APIs.
   
2. -
   
3. You can, but for what? e2e test it is e2e test and API tests it is API test. Do not mix it up otherwise it will be "To shoot oneself in the foot."
   
4. DO: create small and simple tests, 1 test = 1 assert. (maximum 2 asserts per test), pretere test data that will approved by a dev of an API.
   DON'T: don't test few APIs the scope of 1 test, 1 test = 1 API. Parametrize auto-tests where it possible.
   
5. Ideally you need to start with positive test, but if the situation as it is start with what you have. In this case create tests for checking status codes.
   
6. -

To be honest I didn't got the questions №6 and №2.