Should I test multiple paths to a webpage in this case?

Question

Here is an example. Say you are testing an ebook reader web app. The app lets users highlight text, add notes to highlighted text, view all their highlights & notes in the book, search for specific text in the entire book and more.

There are two test cases to validate the highlighting & adding notes to a web page. One test simply picks any page from the table of contents and checks if you can do highlights and notes there. The other test searches a word, goes to any page containing that word and then checks if you can do highlights & notes there.

The question is do we really need both of the above tests to validate highlighting & notes ?

I believe that the first test is enough because the goal is to validate highlighting & notes on a web page, and not different ways to get to a web page. You can have a separate test that checks for ways to get to a web page. What do you think ?

Answer 1

Both are needed.

You may theoretically have a problem that can be reproduced only if you take actions in a specific order. For instance, if you would search for a word, go to a page and then see that highlighting does not work. But, if you would get to a page taking a different path, you would see that highlighting is working.

In an ideal world, you should try to check all the possible ways navigating to a page and all the required highlighting and notes to work there, but in reality, generally speaking, covering all the possible combinations is not practical (Combinatorial Explosion of test cases combinations). This is where the Pareto principle, customer demands, the importance of a feature, regression history, complexity, stakes and stakeholders might help to figure out the sufficient number of test cases for a feature.

Answer 2

Well, that depends on what types of testing you're responsible for.

Of course there are a lot of possible issues which might arise if you go by different paths: highlighting might not work

• if you go to the word by search
• if you're on odd page number
• if you list the page 1 ahead
• or backward,
• or go to some specific page directly
• or navigate to a page using book index
• or nearly infinite number of other paths.

However if you're doing just a functional test of a highlighting feature and you're in tight timings, I would recomend to ignore the paths (to narrow the context), but concentrate on them later when you're about to perform E2E tests for example. This (as I believe) will let you catch more this-particular-feature-code-specific defects on early stages.

Answer 3

My views:

If you want to test only highlighting and making notes then it does not matter from which path you come to page on which you want to do highlighting and notes making. Because highlighting and notes making does not have anything to do with navigation. You can check either one path.

But, If you want to check full end to end scenario i.e. from starting point(list of contents OR entering text into search box) to end point(saving highlighted text and notes on page) then you should check both ways as they are two different end to end scenarios.

Answer 4

I would first find out if the code behind for the highlighting and adding notes are indeed the same. If this is an in house product, review the source code and check with the developers to find out if the code is the same, and if not, find out exactly what are the differences and design your tests to exploit those differences precisely. Bonus point - if the code is different, have a further discussion to see if it can be refactored into a more unified code base in the interest of scalability, maintainability and of course testability.

The following only applies to web pages, not e-readers. Unfortunately I don't know how to verify the source on e-readers.

If this is a 3rd party product that you have no access to the code or devs, then examine the html source and javascripts to see if you can tell if it's calling the same code. For example, under Chrome dev tools:

1. Check the Network traffic, especially when performing the highlight and adding notes to see is any api calls are being made. Compare them on both paths.
2. Review the Sources tab and compare the scripts being called.

If the code is exactly the same, then the argument for not duplicating the test is stronger.