API Testing on production - what requests shouldn't test?

Question

I've manage to get new job and what I can say so far - expectations for me are high. I never used to test API on production - usually I've been teached to test API on dev/test enviroment, but in currect job they got only production env.

My task now is to write requests with Postman, so I have prepared the Workspace, collection and folders and now I should start writing requests. My question is to more experienced guys - should I avoid testing DELETE, PATCH, PUT request and focus only on POST/GET requests because of production?

Answer 1

The answer depends on many other factors including the infrastructure.

1. Even POST requests can create unwanted changes in production DB so GET is mostly the only safe method, investigate if this is the case for your product.
2. Do you have a staging server where you do rest of the use cases (if you plan to use only POST and GET in production)
3. What is your team decision and what are their expectation
4. What is the product structure, is there test sandbox that you can access from the production environment so that you won't affect real users
5. What kind of product are you testing

So as in any test activity, the answer is:

1. The approach is context depended
2. You should have proper risk analysis on what happens if you don't test other http methods and stick to only http GET and POST
3. Is there a backup or restore option if something goes wrong.

Sometimes you won't be able to get answers for all those questions due to immature project stakeholders and process. In that case, I would stick to the below procedures:

1. Ensure to test all GET actions and validate the response schema
2. Check authentication and authorization test for test users. Make sure your test accounts have limited authorization and the test accounts have access only to test data. Don't test admin account use cases as it can cause unwanted changes
3. Don't use admin test accounts as account breaches can compromise the entire production environment
4. Check production environment response time
5. Run postman monitor to ensure health of the production API
6. Stay away from CRUD operations other than R (Read, means GET)
7. Discuss with the team on other use cases and be clear on the risk involved

Answer 2

If you have no other options except of performing your tests in prod, you should avoid using the methods which change the application state. Here are few sides you can look at the issue from:

1. HTTP standard defines so called "safe methods". They are basically the methods which imply read-only access to the data.
2. However the above is only the convention. So in your particular case the handlers dedicated for those methods might not follow the standard.
3. You also should understand there might be different types of testing. For example running performance tests on production is always bad idea no matter which HTTP methods you use and how safe they are.
4. If your application is designed to perform some limited testing in production you that will might be fine to test even the methods introducing the changes to application state (for example there might be a dedicated realm configured for testing)
5. Any sort of testing in production has to be performed very carefully. You have to understand what you're going to do exactly and why (e.g. test if hotfix has been properly applied). The testing has to have as narrow scope as possible.
6. Any sort of testing in production has to be performed only after the discussion with responsible dev lead that might advice what you can do and what you cannot do in every particular case.

Summing up there are two worlds: ideal world where everything is compliant to HTTP standard where you can perform limited testing using "safe" methods and real world where nobody can give you the right answer except of the people how develop the service.