What test cases should I consider when testing this flow?

Question

I have an endpoint that when it gets called, a pdf is generated based on parameters that are coming in from the frontend and then that pdf is returned back to the client side for rendering. In the middle of this, the file itself also gets stored in blob storage before going back to the frontend.

I was wondering, what test cases should I consider writing and what conditions I should be looking for or testing in this scenario?

I'm just looking for a list of things to test for (not the code or anything), just to make sure I hit the right things.

Some things I have thought of are:

-Test that the data coming in from frontend is not null (or at least the required ones).

-Check that File render is not null

-Mock blob storage and test saving file to blob exists there?

What else should I be testing or looking into?

Answer 1

There are many negative scenarios you could test like :

1. Send a non PDF to client and observe client behaves

2. Send some corrupted pdf.

3. Send some exe file and verify that the app does not insecurely deserialise it

4. Send non supported parameters and see if PDF is getting generated or proper error message is thrown .

5. Try converting blob to PDF and see you are getting the expected file .

6. Try storing some executable file or unsupported file as blob and check behavior when system tries to convert it back to pdf

7. Try updating or downgrading the app and see the blob is still reusable .

Answer 2

Testing for edge cases like corrupted files and null values is obviously important, but I wouldn't focus my tests on that.

I would try to focus on actual possible values for the parameters coming from the frontend. If you have access to some actual values that will be used by your users or can access some real usage data samples, that would be best.

The edge-cases-first approach might lead to skewed prioritization of the opened bugs, and what actually matters is making sure that our real users will find this feature useful and not broken.

Answer 3

It's been mentioned in the comments, but to make it more visible + add something to it, you can ask yourself a couple of questions:

• By whom is it going to be used? E.g. internal vs. external users is one thing that makes a difference. Internal users might be given more training in how to use this interface, so you might expect fewer variations as input values. So it tells you where to focus more. (Not that negative cases are not important at all).

• Do you have some other requirements? Performance could be one thing. How many users should be able to use this interface at a time? Are there gonna be some peak times during which you can expect many users using this interface?

• What other systems are going to consume the data stored in the blob storage? Can they use it or do they expect something else? Some integration testing would be appropriate.

• How does the blob storage look like? Can it get unavailable? Most systems get unavailable at some point, so what happens when this one fails so accept new data? Will the rest of the process work just fine? Will you lose some data, or can you store the data later when it storage gets available? How does it work? Do you need to notify the used when the storage is not available? Someone else should be notified? How?

• ...and of course some cases with the values coming from the FE. Do you even get all the values? Talk to your business people, sometimes someone just forgets to add something into requirements, so don't assume the requirements are correct.

Focusing on the functionality itself is one thing, but many more dangers/bugs could be found in the ecosystem, in integrations.