Where to start your test in Selenium?

Question

I had a question regarding Selenium philosophy and how the community generally implements their automated UI tests.

Let's say I had to test an app and make sure all the pages and links are working and responsive. For simplicity's sake, let's just say I'm working with 2 pages -- call them Page A and Page B.

Page A is your primary domain landing page. https://www.foo.com/

Page B is a link accessible once you are on Page A, and is generated depending on what the user inputted in Page A. https://www.foo.com/bar?param1=true&param2=abcd&param3=00:0001&param4=a

Now technically speaking, an end user will never be able to reach Page B without hitting Page A. Page B's URL is generated with params depending on what the user has elected during this flow.

Test case: Verify some thing on Page B

My question: Should I be starting the test at Page A and clicking through links until I get to Page B, and do my verification when I'm there?

OR does it make sense to just start my test at Page B (with a rather obscure URL) and do my verification there by using the API to generate some crazy URL?

I'm a little torn because in my mind, "user acceptance testing" is supposed to exactly mimic a user's behavior, but starting from ZERO (Page A) for every single test seems a bit excessive in terms of time.

Thanks for your time!

Answer 1

If it is just links through static content then no, I would validate each link in dependently on the page it is on. I might use a simple link checker program or routine for that.

If it is a workflow through pages with forms that collect data then the simplest approach does involve going through all the pages to reach the page under test.

I also divide the approach by tests of the happy path test which will visit all the pages and sad path tests that can, mostly, go directly to a specific page and when submitted will stay on that specific page to show the appropriate error that you check for as the main assertion of that test.

As you can imagine it's not that big a deal with 3 simple tests but with complicated (i.e. real world!) forms, often spanning many pages, this can become a run-time nightmare.

There are several approach to tackle this for the appropriate sad tests:

• Work with application to find out the backend logic to get to a given page in the workflow and use that knowledge to visit a given page in your workflow for a sad path test. How much you can do of this will depend on inter-form data dependencies and database record requirements. It is particularly useful for sad path tests as noted above

• Use some version of grey-box testing that sets up the data ahead of time so that when you visit the pages in question the data in forms is prepopulated.

• Use APIs to create the test objects required to get to a given Page Under Test in the workflow.

Answer 2

In my view, navigation to page C and verification of title will be covered in one of End to End scenarios which will also cover many other things in the user journey(transaction) from Page A to Page C and beyond.

Also verification of any page title is something which makes sense to be a part of constructor of any page object as the implicit default first check, which even need not to be explicitly called in the test script.

The thing which I will NOT do in any case, is to make a separate UI automation test just to verify an title of an page or any other single property of an object.

Answer 3

As with anything worth working, it depends. Let's break it down.

" "user acceptance testing" is supposed to exactly mimic a user's behavior"

No. UAT is suppose to check if the features are implemented so the users will be able, somehow, to complete their tasks and solve their problems.

When considering automated checks for user acceptance, one will never be able to mimic the user's behavior, because a machine cannot do it. Machines can help you in UAT on the point that they can check a lot of things with the whole system up (differently from unit checks), as an user would use - but never mimic an user.

"technically speaking, an end user will never be able to reach Page B without hitting Page A"

Being that one can have two approaches:

• Every time a check on Page B is needed, my program would land on Page A and move to Page B;

• One can understand the mechanisms (database states, service verification, etc) which are triggered by going from A to B and create checks (positive, negatives and extreme cases) for these mechanisms. With these mechanisms covered, one can land directly on the Page B, mocking/setting up any necessary condition which would be necessary to reach Page B.

Analysis:

First approach: Pros - simple and fast to implement; Cons - Longer scripts; unnecessary feature dependencies (if the mechanisms of moving from A to B are broken, checks in Page B cannot be performed); more difficult debugging, due un-specificity; longer run-time - which would limit checks in more basic cases.

Second approach: Pros - Shorter scripts, due specificity; no features dependencies; easier debugging; shorter run-time, because the more tests cases you have, the more you can execute in parallel. Cons - One would have to study (read code and pair with programmers) the implementation of the system[1].

Both are valid. So, you would have to analyze which one fits better under your circumstances.

[1] - This is a con just to the point of taking more time. Understand implementation surely can help you test better, because you can more easily spot risks and code smells.

Answer 4

If you want to verify the title of page3 or any texts then you can directly navigate to the page3 url directly and verify the title or text.

In case if you want to perform any functionality on page3 then as you said the "User acceptance testing" every users should navigate through the pages to perform the action. So you can navigate from the base url to navigate to page3 to perform the action.