How to identify scope of end-to-end automation testing?

Question

We are struggling in deciding scope of end-to-end tests. As per our understanding, we have automated the form exactly the way users interact with it. below are the steps user perform while submitting the form.

Step 1. User fills the form

Step 2. If all the validation passes. We submit the form using an API.

Step 3. We show success/failure message to the user

In automation, Success and failure of the form is decided by the message we showed in step 3

Now, here are the questions

1. How do we ensure that all the information filled by the user is passed to an API? Relying on the success/failure message may not be enough specially in case of optional fields.
2. Should we worry about this case at all?
3. Should this case be covered in E2E tests at all? Or can this be verified with any other kind of testing?

We are using Cypress for automation(If this helps)

Answer 1

Your tests is incomplete. It shouldn't stop there.

Step 4. Find the entity created by step 1-3. Made easier if Step 3 also return ID of a created entity.

Step 5. Open details of the entity.

Step 6. Compare the returned values with the ones that were input.

This is answer to your question 1.

Question 2 and 3 really depend on your expected level of confidence in your tests. I would expect this kind of test to be exist. But it's main purpose should be to verify that all pieces fit and work together when running in as close to production environment as possible. This test shouldn't verify that all the possible combinations of validations and data can be saved. Those are tested by tests lower on the test pyramid. E2E tests should verify your deployment, setup and configuration and that all pieces can talk with each other. Anything more and things will get slow and complicated.

Answer 2

You should change your thinking slightly. Instead of working from the form as a starting point, work from the specifications.

Presumably these optional fields have some purpose - to fullfill a requirement. E.g. "The use can optionally provide a delivery address different from the invoice address." So you test this scenario: If the user supplies this delivery address, will the product be delivered there instead? You will probably test this by inspecting a receipt or shipping list in the system or something like that.

Answer 3

The clue is in the name, End to End.

Now its not unusual to have a case like yours where the end product of a UI interaction is not easily testable via an exposed interface.

However, if there is literally no effect of filling in the form there is nothing to test. You should take it a step further and search for that effect, whether its an email sent, a report changing, a parcel being mailed out, whatever. You have to test all the way to the end of the process if you want your test to be end to end.