0

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?

  • What's the reason of storing it as blob. Is it reused by any components ? – PDHide Jan 19 at 17:22
  • Yeah it's a file we need to retrieve again for record keeping. So I want to save the PDF in blob storage. – Euridice01 Jan 19 at 17:27
  • 3
    Your description only speaks about Product Elements. It doesn't speak about the users, risks, nor Product statements. Testing based solely on Product Elements is misleading because your product doesn't exist in a vacuum, but in a world with other products and with people. testingeducation.org/course_notes/bach_james/… – João Farias Jan 19 at 18:31
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 .

| improve this answer | |
  • Thank you for the tips. I have a question. So eventually, I will be taking these test cases and converting them to unit tests or integration tests but for the first 3. Is that testing done on the frontend side (e.g. mobile for me) or backend? I'm mostly looking for what test cases to write up on the backend side and I'm not sure how to write test cases that I'll run on the backend side for the first three mentioned above? @PDHide – Euridice01 Jan 19 at 20:55
  • @Euridice01 I don't what service u use in backend , is it an API , ? If so ask for API contract and see how to send file . Use inspect tool >network to see how the front end interact with the backend – PDHide Jan 19 at 21:05
1

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.

| improve this answer | |
1

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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