Popular Searches
Popular Course Categories
Popular Courses

Scheduled Test Runs

Selenium with CI/CD

<div class="selenium-notes">

<h1>Scheduled Test Runs in Selenium Automation</h1>

<p><strong>Scheduled Test Runs</strong> are automated test executions that are configured to start automatically at a specific time, on specific days, or according to a recurring schedule. Instead of manually starting Selenium tests every time, a scheduler or CI/CD tool can trigger the automation suite automatically.</p>

<p>Scheduled test execution is commonly used in Selenium automation frameworks for nightly regression testing, smoke testing, cross-browser testing, release validation, scheduled health checks, and continuous quality monitoring.</p>

<p>In a typical automation framework, Selenium WebDriver performs browser automation, TestNG manages test execution, Maven can build and execute the project, and a CI/CD tool such as Jenkins can schedule the complete test run.</p>

<p><strong>Course Resource:</strong> <a href="https://www.justacademy.co/course-detail/selenium-training" target="_blank" rel="noopener noreferrer">Selenium Training</a> | <a href="https://www.justacademy.co/register-for-course-demo" target="_blank" rel="noopener noreferrer">Register for Course Demo</a></p>

<hr>

<h2>1. What are Scheduled Test Runs?</h2>

<p>Scheduled Test Runs are automated executions that start according to a predefined schedule. The schedule may be configured to run tests once, daily, weekly, on selected days, or at recurring intervals.</p>

<p>For example, a Selenium regression suite can be configured to run every night at 11:00 PM. The automation tool starts the test suite, executes the tests, generates reports, and stores the results without requiring a tester to manually start the execution.</p>

<pre><code>Scheduled Time

      |

      v

Automation Server

      |

      v

Build Project

      |

      v

Run Test Suite

      |

      v

Selenium WebDriver

      |

      v

Application

      |

      v

Test Results

      |

      v

Reports / Notifications</code></pre>

<hr>

<h2>2. Why are Scheduled Test Runs Important?</h2>

<p>Scheduled execution is important because modern applications require continuous testing. Running automation manually for every regression cycle is time-consuming and can result in inconsistent execution.</p>

<ul>

<li>Reduces manual effort.</li>

<li>Enables automatic regression testing.</li>

<li>Supports nightly test execution.</li>

<li>Helps identify defects earlier.</li>

<li>Improves test consistency.</li>

<li>Supports CI/CD workflows.</li>

<li>Allows testing outside normal working hours.</li>

<li>Generates automated reports.</li>

<li>Supports repeated execution of large test suites.</li>

<li>Improves visibility into application stability.</li>

</ul>

<hr>

<h2>3. Scheduled Test Run Flow</h2>

<p>A scheduled Selenium test normally follows a sequence from scheduling to reporting.</p>

<pre><code>Schedule Created

      |

      v

Scheduled Time Reached

      |

      v

CI/CD Job Triggered

      |

      v

Source Code Checkout

      |

      v

Dependencies Installed

      |

      v

Application / Environment Prepared

      |

      v

TestNG / Test Runner Started

      |

      v

Selenium Tests Execute

      |

      v

Assertions Performed

      |

      v

Test Results Generated

      |

      v

Report Published

      |

      v

Notification Sent</code></pre>

<hr>

<h2>4. Common Tools for Scheduled Test Runs</h2>

<p>Several tools can be used to schedule Selenium automation.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Tool</th><th>Purpose</th></tr>

<tr><td>Jenkins</td><td>CI/CD automation and scheduled test execution</td></tr>

<tr><td>GitHub Actions</td><td>Cloud-based workflow and scheduled automation</td></tr>

<tr><td>GitLab CI/CD</td><td>Pipeline-based scheduled testing</td></tr>

<tr><td>Azure Pipelines</td><td>Scheduled and pipeline-based automation</td></tr>

<tr><td>Windows Task Scheduler</td><td>Scheduling scripts and commands on Windows</td></tr>

<tr><td>Linux Cron</td><td>Scheduling commands and scripts on Linux</td></tr>

<tr><td>Maven</td><td>Build and test execution through commands</td></tr>

<tr><td>TestNG</td><td>Test execution and test-suite management</td></tr>

</table>

<hr>

<h2>5. Scheduled Selenium Testing Architecture</h2>

<pre><code>                 Scheduler

                     |

                     v

                CI/CD Server

                     |

                     v

               Source Repository

                     |

                     v

                  Maven

                     |

                     v

                  TestNG

                     |

                     v

             Selenium WebDriver

                     |

                     v

                Web Browser

                     |

                     v

               Web Application

                     |

                     v

              Test Results

                     |

          +----------+----------+

          |                     |

          v                     v

       Reports              Notifications</code></pre>

<hr>

<h2>6. Scheduling Selenium Tests with Jenkins</h2>

<p>Jenkins is commonly used to automate Selenium test execution. A Jenkins job can be configured to execute a Maven command at a scheduled time.</p>

<p>A typical flow is:</p>

<pre><code>Jenkins

   |

   v

Scheduled Trigger

   |

   v

Checkout Source Code

   |

   v

mvn test

   |

   v

TestNG

   |

   v

Selenium

   |

   v

Browser

   |

   v

Application

   |

   v

Test Report</code></pre>

<hr>

<h2>7. Jenkins Build Trigger for Scheduled Testing</h2>

<p>Jenkins provides scheduled build triggers that allow a job to start automatically according to a schedule.</p>

<p>A schedule can be used for scenarios such as:</p>

<ul>

<li>Nightly regression testing.</li>

<li>Daily smoke testing.</li>

<li>Weekly full regression testing.</li>

<li>Weekend compatibility testing.</li>

<li>Periodic environment health checks.</li>

</ul>

<hr>

<h2>8. Jenkins Cron Syntax</h2>

<p>Jenkins uses cron-style scheduling syntax for scheduled builds.</p>

<pre><code>MINUTE HOUR DAY-OF-MONTH MONTH DAY-OF-WEEK</code></pre>

<p>For example, a conceptual schedule for 11:00 PM every day can be represented as:</p>

<pre><code>0 23 * * *</code></pre>

<p>This represents a daily execution at 23:00 according to the Jenkins server's configured time zone.</p>

<hr>

<h2>9. Common Jenkins Schedule Examples</h2>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Schedule</th><th>Example</th><th>Meaning</th></tr>

<tr><td>Every day at 10 PM</td><td>0 22 * * *</td><td>Runs daily at 10 PM</td></tr>

<tr><td>Every Monday at 9 AM</td><td>0 9 * * 1</td><td>Runs every Monday at 9 AM</td></tr>

<tr><td>Every Sunday at midnight</td><td>0 0 * * 0</td><td>Runs every Sunday at midnight</td></tr>

<tr><td>Every hour</td><td>0 * * * *</td><td>Runs at the start of every hour</td></tr>

<tr><td>Every 15 minutes</td><td>H/15 * * * *</td><td>Runs approximately every 15 minutes</td></tr>

</table>

<p>When configuring schedules, always consider the server time zone and the expected business execution window.</p>

<hr>

<h2>10. Scheduled Test Run Using Maven</h2>

<p>Maven can execute Selenium and TestNG tests through the command line.</p>

<pre><code>mvn test</code></pre>

<p>A scheduler such as Jenkins, Windows Task Scheduler, or Linux Cron can execute this command automatically.</p>

<hr>

<h2>11. Scheduled Test Run Using TestNG</h2>

<p>TestNG is responsible for managing test execution, while the scheduler controls when the test suite starts.</p>

<pre><code>&lt;suite name="Scheduled Regression Suite"&gt;

    &lt;test name="Regression Tests"&gt;

        &lt;classes&gt;

            &lt;class name="tests.LoginTest"/&gt;

            &lt;class name="tests.SearchTest"/&gt;

            &lt;class name="tests.CheckoutTest"/&gt;

        &lt;/classes&gt;

    &lt;/test&gt;

&lt;/suite&gt;</code></pre>

<p>The scheduler can invoke Maven or another test runner that executes this TestNG suite.</p>

<hr>

<h2>12. TestNG Suite Execution Command</h2>

<p>A TestNG suite can be executed through Maven configuration or a suitable command-line setup.</p>

<pre><code>mvn test -DsuiteXmlFiles=testng.xml</code></pre>

<p>This approach is useful when a scheduled job needs to execute a particular TestNG suite.</p>

<hr>

<h2>13. Nightly Regression Testing</h2>

<p>One of the most common uses of scheduled test runs is nightly regression testing.</p>

<p>During the day, developers may commit multiple changes. At night, the complete regression suite can be executed automatically against the latest build.</p>

<pre><code>Developer Changes

      |

      v

Source Repository

      |

      v

Latest Application Build

      |

      v

Nightly Scheduled Job

      |

      v

Regression Suite

      |

      v

Selenium Tests

      |

      v

Reports</code></pre>

<hr>

<h2>14. Scheduled Smoke Testing</h2>

<p>Smoke testing verifies that the most important application functionality is available and working.</p>

<p>A scheduled smoke suite can run at regular intervals or after a deployment.</p>

<pre><code>Scheduled Trigger

      |

      v

Application Availability

      |

      v

Login Test

      |

      v

Home Page Test

      |

      v

Search Test

      |

      v

Critical Workflow Test

      |

      v

Smoke Report</code></pre>

<hr>

<h2>15. Scheduled Cross-Browser Testing</h2>

<p>Scheduled jobs can execute the same Selenium test suite across multiple browsers.</p>

<pre><code>Scheduled Job

     |

     +---- Chrome

     |

     +---- Firefox

     |

     +---- Edge

     |

     +---- Other Supported Browser

             |

             v

       Test Results</code></pre>

<p>Browser selection can be controlled using TestNG parameters, Data Providers, environment variables, or CI/CD parameters.</p>

<hr>

<h2>16. Scheduled Test Runs with TestNG Parameters</h2>

<p>TestNG parameters can be used to provide configuration values such as browser, environment, and application URL.</p>

<pre><code>&lt;parameter name="browser" value="chrome"/&gt;

&lt;parameter name="environment" value="qa"/&gt;</code></pre>

<p>The test code can receive these values using the <strong>@Parameters</strong> annotation.</p>

<pre><code>import org.testng.annotations.Parameters;

import org.testng.annotations.Test;

 

public class ScheduledTest {

 

    @Parameters({"browser", "environment"})

    @Test

    public void executeTest(String browser, String environment) {

        System.out.println("Browser: " + browser);

        System.out.println("Environment: " + environment);

    }

}</code></pre>

<hr>

<h2>17. Scheduled Test Runs with DataProvider</h2>

<p>Data Providers are useful when the scheduled suite needs to execute the same test with multiple test-data combinations.</p>

<pre><code>@DataProvider(name = "users")

public Object[][] users() {

    return new Object[][] {

        {"admin", "admin123"},

        {"manager", "manager123"},

        {"employee", "employee123"}

    };

}

 

@Test(dataProvider = "users")

public void loginTest(String username, String password) {

    System.out.println(username);

}</code></pre>

<p>A scheduled job can trigger the complete Data Provider-based test suite automatically.</p>

<hr>

<h2>18. Scheduled Test Runs and Environment Configuration</h2>

<p>Different environments may require different URLs and configuration values.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Environment</th><th>Example Purpose</th></tr>

<tr><td>Development</td><td>Developer testing</td></tr>

<tr><td>QA</td><td>Functional and regression testing</td></tr>

<tr><td>Staging</td><td>Pre-production validation</td></tr>

<tr><td>Production</td><td>Controlled smoke or health checks</td></tr>

</table>

<p>A scheduled job should clearly identify which environment it is testing to avoid accidental execution against the wrong system.</p>

<hr>

<h2>19. Scheduled Test Runs with Environment Variables</h2>

<p>Environment variables can be used to make scheduled automation configurable.</p>

<pre><code>String browser = System.getenv("BROWSER");

String environment = System.getenv("ENVIRONMENT");

 

System.out.println("Browser: " + browser);

System.out.println("Environment: " + environment);</code></pre>

<p>The CI/CD server can provide these values when starting the test.</p>

<hr>

<h2>20. Parameterizing the Application URL</h2>

<p>Instead of hard-coding an application URL, the framework can obtain the URL from configuration.</p>

<pre><code>String baseUrl = System.getProperty(

    "baseUrl",

    "https://qa.example.com"

);

 

driver.get(baseUrl);</code></pre>

<p>A scheduled job can then supply a different URL when required.</p>

<pre><code>mvn test -DbaseUrl=https://qa.example.com</code></pre>

<hr>

<h2>21. Scheduled Selenium Login Test</h2>

<pre><code>import org.openqa.selenium.By;

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;

import org.testng.Assert;

import org.testng.annotations.AfterMethod;

import org.testng.annotations.BeforeMethod;

import org.testng.annotations.Test;

 

public class LoginTest {

 

    WebDriver driver;

 

    @BeforeMethod

    public void setup() {

        driver = new ChromeDriver();

        driver.manage().window().maximize();

        driver.get("https://example.com/login");

    }

 

    @Test

    public void loginTest() {

        driver.findElement(By.id("username"))

                .sendKeys("testuser");

 

        driver.findElement(By.id("password"))

                .sendKeys("password");

 

        driver.findElement(By.id("loginButton"))

                .click();

 

        Assert.assertTrue(

            driver.getTitle().contains("Dashboard")

        );

    }

 

    @AfterMethod

    public void tearDown() {

        if (driver != null) {

            driver.quit();

        }

    }

}</code></pre>

<p>This test can be included in a scheduled regression suite.</p>

<hr>

<h2>22. Scheduled Regression Suite</h2>

<p>A regression suite can contain multiple test classes.</p>

<pre><code>&lt;suite name="Nightly Regression"&gt;

    &lt;test name="Regression Suite"&gt;

        &lt;classes&gt;

            &lt;class name="tests.LoginTest"/&gt;

            &lt;class name="tests.SearchTest"/&gt;

            &lt;class name="tests.ProductTest"/&gt;

            &lt;class name="tests.CartTest"/&gt;

            &lt;class name="tests.CheckoutTest"/&gt;

        &lt;/classes&gt;

    &lt;/test&gt;

&lt;/suite&gt;</code></pre>

<hr>

<h2>23. Scheduled Test Run After Deployment</h2>

<p>Scheduled tests can also be used after application deployment. A deployment pipeline can trigger a smoke or regression suite after the application becomes available.</p>

<pre><code>Build

  |

  v

Deploy

  |

  v

Application Available

  |

  v

Smoke Tests

  |

  v

Regression Tests

  |

  v

Report

  |

  v

Notification</code></pre>

<hr>

<h2>24. Scheduled Test Runs in CI/CD</h2>

<p>Scheduled testing is an important part of CI/CD automation because test execution does not have to depend on a tester manually starting the suite.</p>

<pre><code>Source Code

    |

    v

Build

    |

    v

Deployment

    |

    v

Scheduled / Automated Trigger

    |

    v

Selenium Test Suite

    |

    v

Results

    |

    v

Report

    |

    v

Notification</code></pre>

<hr>

<h2>25. Jenkins Scheduled Selenium Job</h2>

<p>A Jenkins job can be configured to run Selenium tests on a recurring schedule.</p>

<p>A typical configuration contains:</p>

<ol>

<li>Source code repository.</li>

<li>Build environment.</li>

<li>Required Java and Maven configuration.</li>

<li>Test execution command.</li>

<li>Scheduled build trigger.</li>

<li>Report publishing.</li>

<li>Notification configuration.</li>

</ol>

<hr>

<h2>26. Example Jenkins Build Command</h2>

<pre><code>mvn clean test</code></pre>

<p>A scheduled Jenkins job can execute this command when its configured trigger fires.</p>

<p>For a specific TestNG suite:</p>

<pre><code>mvn clean test -DsuiteXmlFiles=testng.xml</code></pre>

<hr>

<h2>27. Scheduled Test Runs Using Jenkins Pipeline</h2>

<p>Jenkins Pipeline allows test execution to be represented as code.</p>

<pre><code>pipeline {

    agent any

 

    stages {

        stage('Checkout') {

            steps {

                checkout scm

            }

        }

 

        stage('Run Selenium Tests') {

            steps {

                sh 'mvn clean test'

            }

        }

    }

}</code></pre>

<p>A schedule can be configured for the pipeline so that the pipeline starts automatically at the required time.</p>

<hr>

<h2>28. Jenkins Pipeline with Scheduled Trigger</h2>

<pre><code>pipeline {

    agent any

 

    triggers {

        cron('0 23 * * *')

    }

 

    stages {

        stage('Run Tests') {

            steps {

                sh 'mvn clean test'

            }

        }

    }

}</code></pre>

<p>This example represents a scheduled pipeline that runs every day at 11 PM according to the Jenkins server time zone.</p>

<hr>

<h2>29. Publishing Test Results</h2>

<p>Scheduled execution is much more useful when the results are stored and presented in a readable format.</p>

<p>Reports can contain:</p>

<ul>

<li>Total tests.</li>

<li>Passed tests.</li>

<li>Failed tests.</li>

<li>Skipped tests.</li>

<li>Execution duration.</li>

<li>Failed test names.</li>

<li>Exception information.</li>

<li>Screenshots for failed Selenium tests.</li>

<li>Browser information.</li>

<li>Environment information.</li>

</ul>

<hr>

<h2>30. TestNG Reports in Scheduled Execution</h2>

<p>TestNG can generate test execution information that can be consumed by CI/CD reporting systems.</p>

<p>A scheduled automation framework should preserve test results so that the team can investigate failures after the scheduled job completes.</p>

<pre><code>Scheduled Execution

       |

       v

TestNG

       |

       v

Test Results

       |

       v

XML / HTML Report

       |

       v

CI/CD Report

       |

       v

Team Notification</code></pre>

<hr>

<h2>31. Maven Surefire Reports</h2>

<p>Maven Surefire can execute TestNG tests and collect test results. It is commonly used as part of Maven-based Java automation projects.</p>

<pre><code>mvn test</code></pre>

<p>Typical Maven test result files are stored under the target directory, depending on the project configuration.</p>

<hr>

<h2>32. Scheduled Test Reports</h2>

<p>A scheduled test run should produce enough information to understand what happened during execution.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Report Information</th><th>Purpose</th></tr>

<tr><td>Execution Date</td><td>Identifies when the test ran</td></tr>

<tr><td>Environment</td><td>Identifies the application environment</td></tr>

<tr><td>Browser</td><td>Identifies browser coverage</td></tr>

<tr><td>Total Tests</td><td>Shows suite size</td></tr>

<tr><td>Passed</td><td>Shows successful tests</td></tr>

<tr><td>Failed</td><td>Shows unsuccessful tests</td></tr>

<tr><td>Skipped</td><td>Shows tests not executed</td></tr>

<tr><td>Duration</td><td>Shows execution time</td></tr>

<tr><td>Failure Details</td><td>Helps troubleshoot failures</td></tr>

</table>

<hr>

<h2>33. Screenshots for Scheduled Selenium Tests</h2>

<p>When a scheduled Selenium test fails, screenshots can help identify the application state at the time of failure.</p>

<pre><code>Test Failure

     |

     v

Capture Screenshot

     |

     v

Save Screenshot

     |

     v

Attach to Report

     |

     v

Review Failure</code></pre>

<p>Screenshots are particularly useful when scheduled tests run outside normal working hours because there may not be a tester observing the browser session.</p>

<hr>

<h2>34. Failure Handling in Scheduled Tests</h2>

<p>A scheduled test framework should distinguish between application failures, test failures, environment problems, and infrastructure problems.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Failure Type</th><th>Example</th></tr>

<tr><td>Application Failure</td><td>Login button does not work</td></tr>

<tr><td>Test Failure</td><td>Incorrect locator or assertion</td></tr>

<tr><td>Environment Failure</td><td>Application is unavailable</td></tr>

<tr><td>Browser Failure</td><td>Browser cannot start</td></tr>

<tr><td>Infrastructure Failure</td><td>Execution server is unavailable</td></tr>

<tr><td>Network Failure</td><td>Connection timeout</td></tr>

</table>

<hr>

<h2>35. Retry Failed Tests</h2>

<p>Some automation frameworks use retry mechanisms for transient failures. A retry should be used carefully and should not hide genuine application defects.</p>

<pre><code>Scheduled Test

      |

      v

Test Fails

      |

      v

Check Retry Policy

      |

      +---- Retry Allowed ----&gt; Execute Again

      |

      +---- Retry Not Allowed -&gt; Mark Failed

      |

      v

Final Report</code></pre>

<p>Retries are most appropriate for known transient infrastructure problems rather than persistent functional defects.</p>

<hr>

<h2>36. Notifications After Scheduled Tests</h2>

<p>Automated notifications help teams learn about scheduled test results without manually opening the CI/CD system.</p>

<p>Possible notification channels include:</p>

<ul>

<li>Email.</li>

<li>Slack.</li>

<li>Microsoft Teams.</li>

<li>Other team collaboration systems.</li>

<li>CI/CD dashboard notifications.</li>

</ul>

<hr>

<h2>37. Scheduled Test Notification Flow</h2>

<pre><code>Scheduled Test

      |

      v

Test Execution

      |

      v

Result Generated

      |

      v

Pass / Fail Decision

      |

      v

Notification

      |

      +---- Email

      |

      +---- Slack

      |

      +---- Teams

      |

      +---- Dashboard</code></pre>

<hr>

<h2>38. Scheduled Test Runs and Test Reports</h2>

<p>A useful scheduled automation framework should connect execution, reporting, and notification.</p>

<pre><code>Scheduler

   |

   v

Test Execution

   |

   v

Test Results

   |

   +---- Screenshots

   |

   +---- Logs

   |

   +---- XML Results

   |

   v

Report

   |

   v

Notification</code></pre>

<hr>

<h2>39. Scheduled Regression Testing Strategy</h2>

<p>A large organization may divide scheduled testing into different levels.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Frequency</th><th>Test Type</th><th>Purpose</th></tr>

<tr><td>Several times per day</td><td>Smoke</td><td>Verify critical functionality</td></tr>

<tr><td>Daily</td><td>Regression</td><td>Validate recent changes</td></tr>

<tr><td>Weekly</td><td>Full Regression</td><td>Broader application validation</td></tr>

<tr><td>Before Release</td><td>Release Suite</td><td>Validate release readiness</td></tr>

</table>

<hr>

<h2>40. Scheduled Test Runs and Parallel Execution</h2>

<p>Large test suites can take a significant amount of time. Parallel execution can reduce total execution time when the framework is designed for concurrency.</p>

<pre><code>Scheduled Job

      |

      v

Parallel Execution

      |

      +---- Browser 1

      |

      +---- Browser 2

      |

      +---- Browser 3

      |

      +---- Browser 4

      |

      v

Combined Results</code></pre>

<p>WebDriver instances should be isolated between parallel executions to prevent test interference.</p>

<hr>

<h2>41. Scheduled Test Runs with Selenium Grid</h2>

<p>Selenium Grid can be used when scheduled tests need to run across multiple browser and platform combinations.</p>

<pre><code>Scheduled Job

      |

      v

TestNG

      |

      v

Selenium Grid

      |

      +---- Chrome / Windows

      |

      +---- Firefox / Windows

      |

      +---- Edge / Windows

      |

      +---- Other Configurations

      |

      v

Results</code></pre>

<hr>

<h2>42. Scheduled Test Runs with RemoteWebDriver</h2>

<p>When browsers run on remote machines or a Selenium Grid, the test can use RemoteWebDriver.</p>

<pre><code>WebDriver driver =

    new RemoteWebDriver(

        new URL("http://localhost:4444"),

        new ChromeOptions()

    );</code></pre>

<p>The exact remote endpoint and capabilities depend on the Selenium Grid or cloud execution environment.</p>

<hr>

<h2>43. Scheduled Tests on Headless Browsers</h2>

<p>Scheduled CI environments commonly run browsers in headless mode when a visible desktop session is not required.</p>

<pre><code>ChromeOptions options = new ChromeOptions();

 

options.addArguments("--headless");

 

WebDriver driver = new ChromeDriver(options);</code></pre>

<p>Headless execution can be useful on CI servers without a graphical desktop environment.</p>

<hr>

<h2>44. Scheduled Tests and Browser Configuration</h2>

<p>Browser selection can be controlled through a system property.</p>

<pre><code>String browser = System.getProperty(

    "browser",

    "chrome"

);

 

System.out.println("Running on: " + browser);</code></pre>

<p>The scheduler can provide the browser value:</p>

<pre><code>mvn test -Dbrowser=firefox</code></pre>

<hr>

<h2>45. Scheduled Tests and Environment Selection</h2>

<p>A framework can use a system property to select the environment.</p>

<pre><code>String environment = System.getProperty(

    "environment",

    "qa"

);

 

switch (environment.toLowerCase()) {

    case "qa":

        System.out.println("QA environment");

        break;

 

    case "stage":

        System.out.println("Stage environment");

        break;

 

    default:

        throw new IllegalArgumentException(

            "Unsupported environment: " + environment

        );

}</code></pre>

<hr>

<h2>46. Scheduled Tests with Maven Profiles</h2>

<p>Maven profiles can provide environment-specific configuration for different execution scenarios.</p>

<pre><code>&lt;profiles&gt;

    &lt;profile&gt;

        &lt;id&gt;qa&lt;/id&gt;

        &lt;properties&gt;

            &lt;environment&gt;qa&lt;/environment&gt;

        &lt;/properties&gt;

    &lt;/profile&gt;

 

    &lt;profile&gt;

        &lt;id&gt;stage&lt;/id&gt;

        &lt;properties&gt;

            &lt;environment&gt;stage&lt;/environment&gt;

        &lt;/properties&gt;

    &lt;/profile&gt;

&lt;/profiles&gt;</code></pre>

<p>The scheduled job can select the required profile.</p>

<pre><code>mvn clean test -Pqa</code></pre>

<hr>

<h2>47. Scheduled Test Runs and Source Control</h2>

<p>A scheduled job should normally retrieve the intended version of the automation code from a source-control repository before executing tests.</p>

<pre><code>Repository

    |

    v

Checkout Code

    |

    v

Install Dependencies

    |

    v

Build

    |

    v

Run Tests

    |

    v

Generate Report</code></pre>

<p>Using source control ensures that the scheduled execution is based on a known version of the automation framework.</p>

<hr>

<h2>48. Scheduled Test Runs and Dependency Management</h2>

<p>Maven can download and manage project dependencies before test execution.</p>

<pre><code>mvn clean test</code></pre>

<p>The project should use compatible versions of Selenium, TestNG, Maven plugins, Java, and other framework dependencies.</p>

<hr>

<h2>49. Scheduled Test Runs and Clean Builds</h2>

<p>A clean build removes previous build output before executing the current test run.</p>

<pre><code>mvn clean test</code></pre>

<p>This can help reduce problems caused by stale build artifacts.</p>

<hr>

<h2>50. Scheduled Test Runs and Logs</h2>

<p>Logs are important because scheduled tests may execute when no tester is watching the run.</p>

<p>A useful log should contain information such as:</p>

<ul>

<li>Test start time.</li>

<li>Test end time.</li>

<li>Environment.</li>

<li>Browser.</li>

<li>Test method name.</li>

<li>Important test steps.</li>

<li>Failure information.</li>

<li>Exception details.</li>

<li>Execution identifier.</li>

</ul>

<hr>

<h2>51. Scheduled Test Execution Flow with Logs</h2>

<pre><code>Scheduler

   |

   v

Test Started

   |

   v

Execution Logs

   |

   v

Selenium Actions

   |

   v

Assertions

   |

   v

Pass / Fail

   |

   v

Final Logs

   |

   v

Report</code></pre>

<hr>

<h2>52. Handling Application Downtime</h2>

<p>A scheduled test may fail because the application is unavailable during the scheduled execution window.</p>

<p>The framework should clearly distinguish application downtime from functional test failures.</p>

<pre><code>Test Starts

    |

    v

Application Available?

    |

    +---- No ----&gt; Environment Failure

    |

    +---- Yes ---&gt; Execute Test Suite

                       |

                       v

                    Results</code></pre>

<hr>

<h2>53. Scheduling Around Maintenance Windows</h2>

<p>Scheduled test execution should consider planned application maintenance. Running tests while an environment is intentionally unavailable can create unnecessary failures.</p>

<p>Teams should coordinate test schedules with deployment and maintenance windows.</p>

<hr>

<h2>54. Scheduled Test Runs for Regression</h2>

<p>Regression testing verifies that existing functionality continues to work after changes.</p>

<p>A scheduled regression suite can include:</p>

<ul>

<li>Login.</li>

<li>Registration.</li>

<li>Search.</li>

<li>Product selection.</li>

<li>Cart.</li>

<li>Checkout.</li>

<li>Payment workflow.</li>

<li>Logout.</li>

</ul>

<hr>

<h2>55. Scheduled Test Runs for E-Commerce Applications</h2>

<pre><code>Scheduled Regression

       |

       +---- Login

       |

       +---- Search

       |

       +---- Product

       |

       +---- Cart

       |

       +---- Checkout

       |

       +---- Payment

       |

       +---- Order History

       |

       v

    Test Report</code></pre>

<hr>

<h2>56. Scheduled Test Runs for Login Monitoring</h2>

<p>A lightweight scheduled login test can be used to verify that a critical application entry point remains functional.</p>

<pre><code>Scheduled Job

      |

      v

Open Application

      |

      v

Login

      |

      v

Verify Dashboard

      |

      v

Logout

      |

      v

Report</code></pre>

<hr>

<h2>57. Scheduled Test Runs for Application Health</h2>

<p>Scheduled browser automation can also validate critical user journeys.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Health Check</th><th>Example</th></tr>

<tr><td>Availability</td><td>Application opens successfully</td></tr>

<tr><td>Authentication</td><td>User can log in</td></tr>

<tr><td>Navigation</td><td>Important pages load</td></tr>

<tr><td>Search</td><td>Search returns results</td></tr>

<tr><td>Transaction</td><td>Critical workflow completes</td></tr>

</table>

<hr>

<h2>58. Scheduled Test Runs and Report Retention</h2>

<p>Scheduled jobs may generate a large number of reports over time. The CI/CD system should have an appropriate retention strategy.</p>

<p>Retention can consider:</p>

<ul>

<li>Number of builds to keep.</li>

<li>Age of reports.</li>

<li>Storage limitations.</li>

<li>Compliance requirements.</li>

<li>Historical debugging needs.</li>

</ul>

<hr>

<h2>59. Scheduled Test Runs and Historical Trends</h2>

<p>Historical results can help teams understand how test stability changes over time.</p>

<pre><code>Day 1  - 95% Passed

Day 2  - 96% Passed

Day 3  - 93% Passed

Day 4  - 97% Passed

Day 5  - 91% Passed

Day 6  - 98% Passed</code></pre>

<p>Trend information can help identify recurring failures, unstable tests, and changes in regression-suite behavior.</p>

<hr>

<h2>60. Scheduled Test Runs and Test Stability</h2>

<p>A scheduled suite should not be considered reliable simply because it executes automatically. Tests should also be stable and maintainable.</p>

<p>Common causes of unstable Selenium tests include:</p>

<ul>

<li>Hard-coded waits.</li>

<li>Unstable locators.</li>

<li>Timing issues.</li>

<li>Shared test data.</li>

<li>Browser compatibility problems.</li>

<li>Environment instability.</li>

<li>Network failures.</li>

</ul>

<hr>

<h2>61. Explicit Waits in Scheduled Selenium Tests</h2>

<p>Explicit waits can help synchronize Selenium with dynamic web applications.</p>

<pre><code>WebDriverWait wait =

    new WebDriverWait(driver, Duration.ofSeconds(10));

 

WebElement loginButton =

    wait.until(

        ExpectedConditions.elementToBeClickable(

            By.id("loginButton")

        )

    );

 

loginButton.click();</code></pre>

<p>Reliable synchronization is particularly important for scheduled unattended execution.</p>

<hr>

<h2>62. Scheduled Tests and Page Object Model</h2>

<p>The Page Object Model helps separate Selenium interaction logic from test execution logic.</p>

<pre><code>Scheduled Job

     |

     v

Test Class

     |

     v

Page Object

     |

     v

WebDriver

     |

     v

Application</code></pre>

<p>This separation makes scheduled test suites easier to maintain as the application changes.</p>

<hr>

<h2>63. Practical Scheduled Login Project Structure</h2>

<pre><code>selenium-project

|

|-- pom.xml

|

|-- testng.xml

|

|-- Jenkinsfile

|

|-- src

|   |-- test

|       |-- java

|           |-- tests

|           |   |-- LoginTest.java

|           |   |-- SearchTest.java

|           |   |-- CheckoutTest.java

|           |

|           |-- pages

|           |   |-- LoginPage.java

|           |   |-- SearchPage.java

|           |   |-- CheckoutPage.java

|           |

|           |-- utilities

|               |-- DriverFactory.java

|               |-- ConfigReader.java

|               |-- ScreenshotUtil.java

|

|-- reports

|

|-- screenshots</code></pre>

<hr>

<h2>64. Complete Practical Scheduled Test Example</h2>

<p>The following example demonstrates a basic Selenium TestNG test that can be executed through Maven and scheduled by a CI/CD system.</p>

<pre><code>import java.time.Duration;

 

import org.openqa.selenium.By;

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;

import org.openqa.selenium.support.ui.ExpectedConditions;

import org.openqa.selenium.support.ui.WebDriverWait;

import org.testng.Assert;

import org.testng.annotations.AfterMethod;

import org.testng.annotations.BeforeMethod;

import org.testng.annotations.Test;

 

public class ScheduledLoginTest {

 

    WebDriver driver;

 

    @BeforeMethod

    public void setup() {

        driver = new ChromeDriver();

 

        driver.manage().window().maximize();

 

        driver.get("https://example.com/login");

    }

 

    @Test

    public void loginTest() {

 

        driver.findElement(By.id("username"))

                .sendKeys("testuser");

 

        driver.findElement(By.id("password"))

                .sendKeys("password");

 

        WebDriverWait wait =

                new WebDriverWait(

                    driver,

                    Duration.ofSeconds(10)

                );

 

        wait.until(

            ExpectedConditions.elementToBeClickable(

                By.id("loginButton")

            )

        ).click();

 

        Assert.assertTrue(

            driver.getTitle().contains("Dashboard")

        );

    }

 

    @AfterMethod

    public void tearDown() {

        if (driver != null) {

            driver.quit();

        }

    }

}</code></pre>

<hr>

<h2>65. Jenkins Pipeline for Scheduled Selenium Tests</h2>

<pre><code>pipeline {

    agent any

 

    triggers {

        cron('0 23 * * *')

    }

 

    stages {

 

        stage('Checkout') {

            steps {

                checkout scm

            }

        }

 

        stage('Build and Test') {

            steps {

                sh 'mvn clean test'

            }

        }

    }

 

    post {

        always {

            echo 'Scheduled test execution completed'

        }

    }

}</code></pre>

<p>The pipeline can be expanded to publish reports, archive screenshots, and send notifications according to the project's CI/CD configuration.</p>

<hr>

<h2>66. Scheduled Test Runs with TestNG Reports</h2>

<p>When TestNG results are generated in a CI environment, the reporting stage can publish those results for later analysis.</p>

<pre><code>TestNG Execution

      |

      v

XML Results

      |

      v

CI/CD Report Publisher

      |

      v

Passed / Failed / Skipped

      |

      v

Historical Results</code></pre>

<p>For Jenkins, TestNG result publishing can be configured to consume the generated TestNG XML result files.</p>

<hr>

<h2>67. Scheduled Test Runs and Jenkins Result Publishing</h2>

<p>Jenkins can publish TestNG XML results and display information about passed, failed, and skipped tests. This allows scheduled executions to be reviewed after the job finishes.</p>

<p>A typical report publishing flow is:</p>

<pre><code>Test Execution

      |

      v

TestNG XML Result

      |

      v

Jenkins

      |

      v

Test Result Report

      |

      v

Trend / Failure Details</code></pre>

<hr>

<h2>68. Scheduled Test Run Best Practices</h2>

<ul>

<li>Use a stable and dedicated test environment.</li>

<li>Choose execution times carefully.</li>

<li>Avoid known application maintenance windows.</li>

<li>Keep test data isolated.</li>

<li>Use reliable Selenium locators.</li>

<li>Use explicit waits for dynamic elements.</li>

<li>Use Page Object Model for maintainability.</li>

<li>Keep credentials outside source code.</li>

<li>Generate useful reports.</li>

<li>Capture screenshots for important failures.</li>

<li>Store execution logs.</li>

<li>Configure appropriate report retention.</li>

<li>Use retries carefully.</li>

<li>Monitor test stability.</li>

<li>Notify the appropriate team after failures.</li>

<li>Use parallel execution only when the framework is thread-safe.</li>

</ul>

<hr>

<h2>69. Common Mistakes in Scheduled Test Runs</h2>

<ul>

<li>Scheduling tests without verifying the server time zone.</li>

<li>Running tests during planned application maintenance.</li>

<li>Using unstable test data.</li>

<li>Hard-coding passwords and tokens.</li>

<li>Sharing WebDriver instances between parallel tests.</li>

<li>Not storing screenshots or logs.</li>

<li>Ignoring failed scheduled executions.</li>

<li>Running an unnecessarily large suite too frequently.</li>

<li>Not distinguishing environment failures from application failures.</li>

<li>Not maintaining the scheduled automation code.</li>

<li>Failing to clean old reports and artifacts.</li>

<li>Not validating that the application is available before starting the suite.</li>

</ul>

<hr>

<h2>70. Scheduled Test Runs vs Manual Test Runs</h2>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Feature</th><th>Manual Run</th><th>Scheduled Run</th></tr>

<tr><td>Trigger</td><td>Tester starts execution</td><td>Scheduler starts execution</td></tr>

<tr><td>Automation</td><td>Partially dependent on user</td><td>Highly automated</td></tr>

<tr><td>Recurring Execution</td><td>Requires manual action</td><td>Automatic</td></tr>

<tr><td>Nightly Testing</td><td>Less convenient</td><td>Well suited</td></tr>

<tr><td>CI/CD Integration</td><td>Limited</td><td>Strong</td></tr>

<tr><td>Reporting</td><td>May require manual collection</td><td>Can be automated</td></tr>

<tr><td>Notifications</td><td>Usually manual</td><td>Can be automated</td></tr>

</table>

<hr>

<h2>71. Scheduled Test Runs vs Continuous Testing</h2>

<p>Scheduled testing and continuous testing are related but not identical.</p>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Scheduled Testing</th><th>Continuous Testing</th></tr>

<tr><td>Runs at predefined times</td><td>Runs as part of continuous delivery workflows</td></tr>

<tr><td>Often used for nightly regression</td><td>Often triggered by development and deployment events</td></tr>

<tr><td>Predictable execution windows</td><td>Frequent automated feedback</td></tr>

<tr><td>Useful for large regression suites</td><td>Useful for rapid feedback</td></tr>

</table>

<hr>

<h2>72. Scheduled Test Runs and Security</h2>

<p>Scheduled automation often runs without direct human supervision, so security must be considered carefully.</p>

<ul>

<li>Do not expose passwords in logs.</li>

<li>Do not commit API tokens to source control.</li>

<li>Use CI/CD credential management where available.</li>

<li>Restrict access to reports containing sensitive information.</li>

<li>Protect test environments from unauthorized access.</li>

<li>Avoid logging authentication secrets.</li>

</ul>

<hr>

<h2>73. Scheduled Test Runs and Credentials</h2>

<p>Instead of storing credentials directly in Selenium source code:</p>

<pre><code>String username = System.getenv("TEST_USERNAME");

String password = System.getenv("TEST_PASSWORD");</code></pre>

<p>The CI/CD environment can provide the required values securely according to the organization's credential-management approach.</p>

<hr>

<h2>74. Scheduled Test Run Checklist</h2>

<ul>

<li>Application environment is available.</li>

<li>Source code is available.</li>

<li>Dependencies can be resolved.</li>

<li>Browser is installed and compatible.</li>

<li>WebDriver setup is working.</li>

<li>TestNG suite is configured.</li>

<li>Test data is available.</li>

<li>Credentials are configured securely.</li>

<li>Scheduler uses the correct time zone.</li>

<li>Reports are generated.</li>

<li>Screenshots are captured where required.</li>

<li>Notifications are configured.</li>

<li>Historical results are retained appropriately.</li>

</ul>

<hr>

<h2>75. Interview Questions on Scheduled Test Runs</h2>

<h3>1. What is a Scheduled Test Run?</h3>

<p>A Scheduled Test Run is an automated test execution that starts according to a predefined schedule without requiring manual execution.</p>

<h3>2. Why are scheduled Selenium tests useful?</h3>

<p>They allow regression, smoke, monitoring, and other automated tests to execute repeatedly at predefined times.</p>

<h3>3. Which tools can schedule Selenium tests?</h3>

<p>Tools such as Jenkins, GitHub Actions, GitLab CI/CD, Azure Pipelines, Windows Task Scheduler, and Linux Cron can be used depending on the project environment.</p>

<h3>4. Can Jenkins schedule Selenium tests?</h3>

<p>Yes. Jenkins can trigger jobs according to a configured schedule and execute Selenium tests through commands or pipelines.</p>

<h3>5. What is cron syntax?</h3>

<p>Cron syntax is a scheduling expression used to define recurring execution times.</p>

<h3>6. What does 0 23 * * * represent?</h3>

<p>It represents a daily execution at 11:00 PM according to the scheduler's configured time zone.</p>

<h3>7. Can TestNG be used with scheduled tests?</h3>

<p>Yes. TestNG can manage the test suite while Jenkins or another scheduler controls when the suite is executed.</p>

<h3>8. Can Maven execute scheduled Selenium tests?</h3>

<p>Maven itself is primarily a build and test execution tool. A scheduler can invoke Maven commands such as <strong>mvn clean test</strong>.</p>

<h3>9. Can scheduled tests run in parallel?</h3>

<p>Yes. Parallel execution can be configured when the framework and test data are designed for thread-safe execution.</p>

<h3>10. Why are reports important for scheduled execution?</h3>

<p>Reports provide execution results when tests run unattended and help identify failures, skipped tests, and execution details.</p>

<h3>11. Why are screenshots useful?</h3>

<p>Screenshots provide visual information about the browser state when a Selenium test fails.</p>

<h3>12. Can scheduled tests run on multiple browsers?</h3>

<p>Yes. Browser parameters, Data Providers, Selenium Grid, or CI/CD matrix configurations can be used for cross-browser testing.</p>

<h3>13. What is nightly regression testing?</h3>

<p>It is a regression suite that is automatically executed during a scheduled nighttime window.</p>

<h3>14. What should be considered before scheduling tests?</h3>

<p>Teams should consider environment availability, maintenance windows, test duration, browser availability, test data, credentials, reports, and notifications.</p>

<h3>15. How should failures be handled?</h3>

<p>Failures should be logged, reported, and classified so that application, test, environment, and infrastructure problems can be distinguished.</p>

<h3>16. Can Jenkins publish TestNG results?</h3>

<p>Yes. Jenkins can publish TestNG XML results through its TestNG reporting functionality.</p>

<h3>17. Why should WebDriver not be shared between parallel tests?</h3>

<p>Sharing a WebDriver instance can cause concurrent tests to interfere with each other's browser state.</p>

<h3>18. Can scheduled tests use environment variables?</h3>

<p>Yes. Environment variables can provide browser, environment, URL, and other runtime configuration values.</p>

<h3>19. What is the role of CI/CD in scheduled testing?</h3>

<p>CI/CD systems can automate source checkout, build, test execution, reporting, artifact storage, and notifications.</p>

<h3>20. What is an important best practice for scheduled Selenium tests?</h3>

<p>Scheduled tests should be stable, maintainable, independently executable, properly reported, and configured to handle failures clearly.</p>

<hr>

<h2>76. Quick Reference Table</h2>

<table border="1" cellpadding="8" cellspacing="0">

<tr><th>Concept</th><th>Description</th></tr>

<tr><td>Scheduled Test Run</td><td>Automated test execution at a predefined time</td></tr>

<tr><td>Jenkins</td><td>CI/CD server that can trigger scheduled jobs</td></tr>

<tr><td>Cron</td><td>Schedule expression used for recurring execution</td></tr>

<tr><td>TestNG</td><td>Test execution and suite management framework</td></tr>

<tr><td>Maven</td><td>Build and test execution tool</td></tr>

<tr><td>Selenium WebDriver</td><td>Browser automation technology</td></tr>

<tr><td>DataProvider</td><td>Supplies multiple test-data sets</td></tr>

<tr><td>@Parameters</td><td>Supplies configuration parameters</td></tr>

<tr><td>Page Object Model</td><td>Separates page interaction logic from tests</td></tr>

<tr><td>Test Report</td><td>Provides execution results</td></tr>

<tr><td>Screenshot</td><td>Captures browser state during failures</td></tr>

<tr><td>CI/CD</td><td>Automates software delivery and testing workflows</td></tr>

</table>

<hr>

<h2>77. Learning Roadmap for Scheduled Test Runs</h2>

<ol>

<li>Learn Selenium WebDriver fundamentals.</li>

<li>Learn TestNG test execution.</li>

<li>Understand TestNG suites.</li>

<li>Learn Maven test execution.</li>

<li>Learn command-line test execution.</li>

<li>Understand CI/CD concepts.</li>

<li>Learn Jenkins fundamentals.</li>

<li>Learn Jenkins job configuration.</li>

<li>Understand cron scheduling.</li>

<li>Configure scheduled Selenium execution.</li>

<li>Generate TestNG and Maven reports.</li>

<li>Capture screenshots for failures.</li>

<li>Configure notifications.</li>

<li>Learn parallel browser execution.</li>

<li>Integrate Selenium Grid when required.</li>

<li>Build a complete scheduled regression framework.</li>

</ol>

<hr>

<h2>78. Practical Exercises</h2>

<ol>

<li>Create a Selenium login test and execute it using Maven.</li>

<li>Create a TestNG regression suite containing five test classes.</li>

<li>Configure a Jenkins job to execute the suite.</li>

<li>Schedule the job for a nightly execution.</li>

<li>Configure browser selection using a system property.</li>

<li>Configure environment selection using a system property.</li>

<li>Generate and store test reports.</li>

<li>Capture screenshots when tests fail.</li>

<li>Configure email or team notifications.</li>

<li>Run the same suite against Chrome and Firefox.</li>

<li>Configure parallel execution.</li>

<li>Store historical execution results.</li>

</ol>

<hr>

<h2>79. Real-World Scheduled Automation Architecture</h2>

<pre><code>                 Source Control

                       |

                       v

                  Jenkins

                       |

              Scheduled Trigger

                       |

                       v

                  Maven Build

                       |

                       v

                    TestNG

                       |

          +------------+------------+

          |            |            |

        Login       Search      Checkout

          |            |            |

          +------------+------------+

                       |

                       v

                Selenium WebDriver

                       |

                       v

                  Web Browser

                       |

                       v

                 Application

                       |

          +------------+------------+

          |            |            |

        Logs      Screenshots     Results

          |            |            |

          +------------+------------+

                       |

                       v

                    Report

                       |

                       v

                 Notification</code></pre>

<hr>

<h2>80. Complete Scheduled Test Execution Strategy</h2>

<p>A mature Selenium automation framework can combine scheduling, TestNG, Maven, Page Object Model, Data Providers, Selenium Grid, reporting, and CI/CD.</p>

<pre><code>Scheduled Trigger

       |

       v

Source Checkout

       |

       v

Environment Configuration

       |

       v

Maven Build

       |

       v

TestNG Suite

       |

       +---- DataProvider

       |

       +---- Parameters

       |

       v

Page Object Model

       |

       v

Selenium WebDriver

       |

       +---- Chrome

       |

       +---- Firefox

       |

       +---- Edge

       |

       v

Application

       |

       v

Assertions

       |

       +---- Logs

       |

       +---- Screenshots

       |

       +---- Test Results

       |

       v

Report

       |

       v

Notification</code></pre>

<hr>

<h2>81. Summary</h2>

<p>Scheduled Test Runs are an important part of modern Selenium automation. They allow automated tests to execute at predefined times without requiring a tester to manually start the test suite.</p>

<p>Jenkins and other CI/CD systems can trigger Selenium automation using scheduled jobs. Maven can execute the project, TestNG can manage the test suite, Selenium WebDriver can automate browsers, and reporting tools can collect and present the results.</p>

<p>Scheduled testing is especially useful for nightly regression testing, smoke testing, cross-browser testing, application health checks, release validation, and recurring quality checks.</p>

<p>A reliable scheduled automation framework should include stable test cases, isolated test data, secure credentials, environment configuration, useful reports, screenshots, logs, notifications, and appropriate failure handling.</p>

<p><strong>Final Takeaway:</strong> Scheduled Test Runs transform Selenium automation from manually triggered testing into a repeatable and unattended testing process. When combined with TestNG, Maven, Page Object Model, reporting, and CI/CD tools, scheduled execution can become an important part of a scalable automation framework.</p>

<hr>

<h2>82. Course Resources</h2>

<p>Learn more about Selenium automation and related testing concepts:</p>

<ul>

<li><a href="https://www.justacademy.co/course-detail/selenium-training" target="_blank" rel="noopener noreferrer">Selenium Training</a></li>

<li><a href="https://www.justacademy.co/register-for-course-demo" target="_blank" rel="noopener noreferrer">Register for Selenium Course Demo</a></li>

</ul>

</div>

Previous Next
whatsapp