I work with e-commerce websites and I am wondering how much of the tests should be automated. I plan on automating the login and check out functionalities but what about clicking links to navigate throughout the website? I am using Selenium webDriver so it takes time to collect the web elements and coding it into Java.

  • 2
    42 - to be honest that depends on so much points. I vote this as too broad – bish Nov 14 '15 at 14:45
  • 42 is correct answer to way too many questions, but not sure is blin92 will get the reference – Peter M. - stands for Monica Nov 16 '15 at 13:19

You cannot automate 100% if it’s a large application. Instead of relying totally on automation, it is better use a combination of automation and manual testing. Just like with any tool Selenium Webdriver also has some limitations such as automation in the IE browser.

As for which tests to automate (in terms or functionality), it should be generally tests that have been identified as regression tests and areas that are considered to be stable. In companies that I worked in that’s what they chose to automate (i.e regression test cases)

The cost of automation can be high at the start in terms of setup, training the resources and maintaining the tests. It is also important to have a well-designed framework in place.

Login and checkout functionalities are generally good scenarios to start with provided that these pages/functionalities will not change for a while. So how much should be automated? We need to pick and choose wisely. Keep in mind that maintenance of the test will accumulate overtime.

Apart from that, if you have you have thousands of users visiting you website simultaneously, testing this would require a load testing tool (e.g jmeter)


You've implied UI automation in your question, however testing should be seen within the broader context of unit - integrated - performance - exploratory - testing.

Every situation is different and you should combine your efforts in the above 4 areas as appropriate for the situation at hand.

With the former in mind, I also like the well-known concept of the testing pyramid whereby a few single end to end UI test automation cases can sit on top of a code base that, at the bottom layers has hundreds or thousands of unit test cases for the backend logic.

As to "how many test cases to automate in selenium" as opposed to manual testing and the like, you may find doing a risk based assessment will help. It will get you to think about:

  • what are the potential losses if functionality if broken?
  • how much effort will it take to automate core cases
  • how many times you want to do the testing, i.e. how many and how often you do new versions
  • what other issues or desired features exist that would provide greater revenue

At a different tack, you may find What kind of test cases can we not automate in selenium webdriver - java interesting. It talks about functionality that you literally cannot easily automate with current tools, for things like captcha, gestures, video, payment gateway timeouts, etc.


Read about the test pyramid, find a good balance between the different types of testing. Not to much not to little :)

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