About Shield34

This content is brought to you by Shield34: Automatic AI deep reporting. Eliminate flaky tests. Integrate seamlessly with existing tests & write new tests 500% faster. Learn more

We all know by now that the benefits of test-automation are clear. Many QA projects start small and gradually gain complexity due to new features flowing in, and by then you find yourself handling a test suite that only increases in terms of the # of tests that you need to run in a given period, as well as the time it takes to complete them. 

In agile environments, this phenomenon is accelerated. 

That’s where automation comes in. Still, having a test automation operation doesn’t mean having an optimal one. We’ve already written about Selenium automation faults that impact the bottom line, present and future test automation trends, how to get rid of flaky test and even shared some good laughs about how a day in the life of a Selenium coder looks like. But we haven’t yet talked about Selenium framework.

By the way, this topic gets attention in communities such as Github, StackOverflow and alike. It is a topic that is interesting for Selenium coders, beginners or experienced.
An efficient automation framework, just like a good cooking recipe, provides testers with guidelines to leverage reusable automated tests, rapidly and reliably, to achieve specific testing goals.

If you are not using Shield34 (not even the free version, god knows why), which means that you are not enjoying a ready-to-use framework every time you start a project, you will need to roll up your sleeves and follow the instructions below! 


So, where should you start?

Here is my ‘9-step guide’ for getting started with an efficient automation framework:

  • POMs:
    • Use a page object model (POM). Why? cause it’s easy to use, reliable, readable and most importantly, reusable.
    • If there are some changes in your UI, you’ll have to make the changes only in one class that represents the changed component, instead of changing it in 10 separate tests that use the same page (which you’ll find yourself doing if you don’t use a POM).
    • Separate between locators, actions on elements and the test itself.
    • Tests become shorts as we reuse POMs and its methods.


  • Driver Manager
    • Build a class to manage drivers with multiple threads, for example:
      public class LocalDriverManager {
          private static ThreadLocal<WebDriver> webDriver = new ThreadLocal<WebDriver>();
          public static WebDriver getDriver() {
              return webDriver.get();
          static void setWebDriver(WebDriver driver) {


  • To use driver in tests you can use:


  • Abstract POM
    • Build an abstract POM that all your POMs will extend
    • Initialize Webdriver in your abstract POM:
      protected WebDriver driver = LocalDriverManager.getDriver();
    • Initialize Webdriver Wait
      protected Wait<WebDriver> wait = new FluentWait<WebDriver>(driver).withTimeout(20, TimeUnit.SECONDS).pollingEvery(900, TimeUnit.MILLISECONDS);
    • Initialize Page factory, for example:
      PageFactory.initElements(new AjaxElementLocatorFactory(driver, 4), this);
    • Add abstract isDisplayed function that every derived class must implement, for example:
      public abstract boolean isDisplayed();


  • Waits
    • Use waits wisely: It’s better to use explicit wait instead of implicit waits
    • Avoid using Thread.sleep(), sometimes this sleep is sufficient but when the application is too slow, it’s not enough, so using explicit wait is much more efficient


  • Make your code generic
    • As I mentioned earlier, build your POMs and tests to be generic and reusable
    • Keep using common classes and common methods and don’t duplicate your code


  • Suites
    • Create an XML suite for every section in your website so when you want to test that section you can run only that specific suite instead of running all the tests
    • Create a Sanity suite and a Full Regression suite. The Sanity should test all sections but should be a fast run to test that your website isn’t broken, and the Full Regression is there to test all the sections deeply.


  • Use CI/CD tools
    • Run all your tests at night-time, everyday, so in the morning you’ll have the report ready for you
    • Run your tests every few hours so you can keep your tests stable for a longer period of time


    • After every action, I suggest you add an assert so most of the failures are on assertion
    • Don’t assume anything. Before using every POM always use assert with pom.isDisplayed()
    • Always add informative assert message so that everyone can understand the cause of the failure


  • Screenshot
    • If the assert didn’t help you, the screenshot could help
    • Add ‘take screenshot’ to @aftermethod, but only on failure. For example:
      @AfterMethod(alwaysRun = true)
      public void screenshot(ITestResult result){
              if (result.getStatus() == ITestResult.FAILURE){
      public static void takeScreenshot(WebDriver driver) {
              File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
              //Now you can do whatever you need to do with it, for example copy somewhere
              FileUtils.copyFile(scrFile, new File("c:\\tmp\\screenshot.png"));


To sum it up…

If you build your automation framework based on these 9 steps you’re most likely to find yourself gaining more accurate automated tests, reducing the product release time and most importantly, you’ll improve the products’ time-to-market. A win-win for everyone.





Deeb Andrawis

Senior Automation Developer @Shield34 - Deeb is an experienced automation developer, leading QA automation development and execution @Shield34. In his past, Deeb established an automation framework from scratch to up-to a 3K tests with fully automated CI for SimilarWeb.


Featured Articles