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!

4 Answers 4


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.

  • 1
    Thanks Michael! Appreciate your answer, but I'd also love some input regarding this: If I was tasked to "automate our regression suite", and this is describing an end-to-end test (A -> B -> C), would you still stand by your answer? Would you still consider starting at Page C a valid "regression" of the app?
    – qaNoob
    Commented Jun 18, 2018 at 21:23
  • 1
    I use an end to end test for the happy path - visiting all pages in the workflow. For sad paths I will usually see if most of those can be done with direct page access to reduce what otherwise can be horrific travel times. At my current org we have 10 forms to go through, so every sad case on page 9 has to go through all those forms... or go directly when appropriate. 'When appropriate' depends on the specifics of the situation. Commented Jun 19, 2018 at 18:12
  • 1
    I would also push back with 'so lets verify:you want me to add value through the use of carefully selected and crafted test cases?' Just "Automate our regression suite" is not a good idea. Some manual test cases will not be suitable for automation and many if not most should be unit or integrated tests, not UI tests. Otherwise you are testing data combinations through the front end not back end and this is a disastrous route in my experience at several companies. Commented Jun 19, 2018 at 18:15
  • Added this info to the answer itself. Commented Jun 19, 2018 at 18:22

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.


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.


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.

  • 1
    Appreciate the in-depth detailed answer. I'd to hear your thoughts here: As QA, my job to do regression would be to test end-to-end; verify that a user can go through, say, this purchase flow, and I am simply trying to automate my regression suite. If this was a e-commerce checkout flow, do you still think it's ideal to set up that "grey-box state", where the user input's are generated programmatically rather than organically in order to start there? I just find it difficult to characterize such a test as a "regression test".
    – qaNoob
    Commented Jun 18, 2018 at 20:56

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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