One Tests or Multiple Separate Test Automation BDD

Question

How the system works (UI) Registration Form > Redirect to Another Page with Products (based on the submitted in the registration form)

(backend) API will check the validity > Valid or not it will push to database > Only Valid will be recorded in our CRM (salesforce)

When testing this manually, we would just usually do it in one flow: Register > Check Redirected in Products Page > Check in Database > Check in CRM

However, in Automated Test, I think of two options right now

a. One Test (like manual) - this is fastest

b. Multiple Separate Test - slower, but easier to identify where the test has failed

Is there an option C? And how would you organise it?

Most of the things I find online are always "IT DEPENDS" or the sample projects I find are too small (only login).

(I'm just starting with automation. Automating is easy but as the Automation Tests are getting bigger and a lot of tests need to be refactored, structures need to be fixed, hierarchy, not sure what to do really)

Answer 1

This is just from personal experience.
As you say; It indeed depends. Mostly on how reusable, manageable or scalable you need it to be.

However, unless this is a one-off automation project, having separate tests (one per action/step/...) gives you lot more control.

• It indeed allows you to more easily see where the issue is located. Instead of having to go in each failed test case and look at which part failed, you can simply look at which test case failed.
• It makes it easier to implement standards or structures since you're only working on small blocks per test.
• Once you have some structure and rules, separate tests can be reused as a form of building blocks to build flows you might need in the future or to simply be reused in different tests you might need. Especially if you also make use of clearly defined/agreed upon variables, you could keep your actual steps a bit more general while filling in some specifics using these variables - Preventing you from needing to rewrite tests for each new specific scenario that gets added.
• Speed shouldn't be too big of a factor here since the automation tool will still have to go through each step, regardless of if you write them as separate tests or one big test/flow. A possible exception here being some app that may need starting/shutting down with each test.

A very general example of this might be that you have a general test (and code behind it for automation) to open a specific app or site. If you use a variable here to define which app/site is desired, you could use this same test as a starting step/test for each flow where you want to start from an app/site.

Since you also mentioned the project was growing, written/documented naming conventions and rules for you tests (structure, name, variables, ...) is also very important.

Again this is mostly just from experience but the more my team leaned into this, the more manageable and easy our automation project became.