Why advanced skills handle complex scenarios in Selenium Java - Automation Benefits in Action

Verify user can complete a multi-step form with dynamic content

Preconditions (2)

Step 1: Fill in the first step fields with valid data

Step 2: Click the 'Next' button to go to the second step

Step 3: Wait for dynamic content to load on the second step

Step 4: Fill in the second step fields with valid data

Step 5: Click the 'Next' button to go to the third step

Step 6: Fill in the third step fields with valid data

Step 7: Click the 'Submit' button

Step 8: Wait for confirmation message to appear

✅ Expected Result: The confirmation message 'Form submitted successfully' is displayed

Automation Requirements - Selenium WebDriver with Java

Assertions Needed:

Verify each step loads correctly before interacting

Verify dynamic content is present before filling fields

Verify confirmation message text after submission

Best Practices:

Use explicit waits to handle dynamic content loading

Use Page Object Model to organize page interactions

Use clear and maintainable locators (id, name, css selectors)

Avoid Thread.sleep; prefer WebDriverWait

Use assertions from a testing framework like TestNG or JUnit

Automated Solution

Selenium Java

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
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.AfterClass;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;
import java.time.Duration;

public class MultiStepFormTest {
    private WebDriver driver;
    private WebDriverWait wait;

    @BeforeClass
    public void setUp() {
        driver = new ChromeDriver();
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
        driver.get("https://example.com/multi-step-form");
    }

    @Test
    public void testCompleteMultiStepForm() {
        // Step 1: Fill first step
        wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("firstName"))).sendKeys("John");
        driver.findElement(By.id("lastName")).sendKeys("Doe");
        driver.findElement(By.id("nextBtn")).click();

        // Step 2: Wait for dynamic content
        wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("dynamicField")));
        driver.findElement(By.id("dynamicField")).sendKeys("Dynamic Data");
        driver.findElement(By.id("nextBtn")).click();

        // Step 3: Fill third step
        wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("email"))).sendKeys("[e-mail]");
        driver.findElement(By.id("submitBtn")).click();

        // Verify confirmation message
        WebElement confirmation = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("confirmationMessage")));
        Assert.assertEquals(confirmation.getText(), "Form submitted successfully");
    }

    @AfterClass
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

This test uses Selenium WebDriver with Java and TestNG for assertions.

We start by opening the multi-step form page in the @BeforeClass setup.

Each step waits explicitly for the required elements to be visible before interacting. This avoids timing issues with dynamic content.

We fill fields by locating them with By.id, which is clear and stable.

We click the 'Next' or 'Submit' buttons to move through the form steps.

After submission, we wait for the confirmation message and assert its text matches the expected success message.

The @AfterClass method closes the browser to clean up.

This approach shows advanced skills by handling dynamic waits, using good locators, and structuring the test clearly.

Common Mistakes - 3 Pitfalls

Using Thread.sleep() instead of explicit waits

Using brittle XPath locators with absolute paths

Not verifying that each step loaded before interacting

Bonus Challenge

Now add data-driven testing with 3 different sets of form input data

Show Hint

Practice

1. Why are advanced Selenium skills important when testing complex web applications?

easy

A. They help handle dynamic elements and unexpected delays reliably.

B. They make tests run faster by skipping validations.

C. They allow tests to ignore errors and continue blindly.

D. They reduce the need for writing any assertions.

Solution

1. Step 1: Understand dynamic web elements

   Complex apps often have elements that load or change after some delay.

2. Step 2: Importance of handling delays and exceptions

   Advanced skills like waits and exception handling ensure tests wait for elements and handle errors gracefully.

3. Final Answer:

   They help handle dynamic elements and unexpected delays reliably. -> Option A

4. Quick Check:

   Advanced skills = handle dynamic elements [OK]

Hint: Think about handling delays and changes in web pages [OK]

Common Mistakes:

• Assuming tests should skip validations
• Ignoring errors instead of handling them
• Believing assertions are unnecessary

2. Which of the following is the correct way to wait for an element to be clickable in Selenium Java?

easy

A. new WebDriverWait(driver, 10).until(ExpectedConditions.elementToBeClickable(By.id("submit")));

B. driver.wait(10).until(ExpectedConditions.clickable(By.id("submit")));

C. WebDriverWait wait = new WebDriverWait(10); wait.until(clickable(By.id("submit")));

D. driver.findElement(By.id("submit")).waitUntilClickable(10);

Solution

1. Step 1: Recall correct WebDriverWait syntax

   WebDriverWait requires driver and timeout, then calls until with ExpectedConditions.

2. Step 2: Check each option's syntax

   new WebDriverWait(driver, 10).until(ExpectedConditions.elementToBeClickable(By.id("submit"))); matches correct syntax; others have wrong method calls or missing driver.

3. Final Answer:

   new WebDriverWait(driver, 10).until(ExpectedConditions.elementToBeClickable(By.id("submit"))); -> Option A

4. Quick Check:

   Correct WebDriverWait syntax = new WebDriverWait(driver, 10).until(ExpectedConditions.elementToBeClickable(By.id("submit"))); [OK]

Hint: Remember WebDriverWait needs driver and ExpectedConditions [OK]

Common Mistakes:

• Using driver.wait() which does not exist
• Missing driver parameter in WebDriverWait constructor
• Incorrect method names like waitUntilClickable

3. What will be the output of the following Selenium Java code snippet?

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(5));
WebElement button = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("login")));
System.out.println(button.isDisplayed());

medium

A. false if element is not visible, else true

B. Always prints true regardless of element visibility

C. true if element with id 'login' is visible within 5 seconds, else TimeoutException

D. Compilation error due to wrong WebDriverWait usage

Solution

1. Step 1: Understand WebDriverWait with ExpectedConditions

   wait.until waits up to 5 seconds for element visibility or throws TimeoutException if not found.

2. Step 2: Analyze System.out.println output

   If element is visible, isDisplayed() returns true; if not found in time, exception occurs before print.

3. Final Answer:

   true if element with id 'login' is visible within 5 seconds, else TimeoutException -> Option C

4. Quick Check:

   Wait returns element or throws exception [OK]

Hint: Wait returns element or throws exception, no false return [OK]

Common Mistakes:

• Thinking wait returns false instead of exception
• Assuming isDisplayed() runs if element not found
• Confusing compilation errors with runtime exceptions

4. Identify the error in this Selenium Java code snippet that tries to click a button:

driver.findElement(By.id("submitBtn")).click();
Thread.sleep(5000);

medium

A. Missing import for By class causes compilation error.

B. Using Thread.sleep causes unnecessary fixed wait; better to use explicit wait.

C. click() method is not valid for WebElement.

D. findElement should be replaced with findElements for clicking.

Solution

1. Step 1: Analyze use of Thread.sleep

   Thread.sleep pauses test for fixed time, which is inefficient and unreliable for dynamic waits.

2. Step 2: Suggest better approach

   Explicit waits like WebDriverWait wait for conditions dynamically, improving test stability.

3. Final Answer:

   Using Thread.sleep causes unnecessary fixed wait; better to use explicit wait. -> Option B

4. Quick Check:

   Use explicit waits, not Thread.sleep [OK]

Hint: Avoid Thread.sleep; prefer explicit waits for stability [OK]

Common Mistakes:

• Thinking Thread.sleep is best for waiting
• Confusing findElement and findElements usage
• Believing click() is invalid method

5. You need to write a Selenium Java test that waits for a list of dynamic elements to appear, clicks each visible one, and logs failures without stopping the test. Which advanced skills should you combine?

hard

A. Use JavaScriptExecutor to click elements without waits or error handling.

B. Use Thread.sleep for fixed waits, no exception handling, and hard assertions to stop on failure.

C. Use implicit waits only, no exception handling, and no assertions.

D. Use explicit waits for visibility, try-catch blocks for exceptions, and soft assertions for logging failures.

Solution

1. Step 1: Handle dynamic elements with explicit waits

   Explicit waits ensure each element is visible before interacting, avoiding errors.

2. Step 2: Use try-catch to handle exceptions without stopping test

   Try-catch blocks catch errors per element, allowing test to continue and log issues.

3. Step 3: Apply soft assertions to log failures without halting

   Soft assertions record failures but let the test finish, improving test reporting.

4. Final Answer:

   Use explicit waits for visibility, try-catch blocks for exceptions, and soft assertions for logging failures. -> Option D

5. Quick Check:

   Combine waits, exception handling, soft assertions [OK]

Hint: Combine waits, try-catch, and soft assertions for robust tests [OK]

Common Mistakes:

• Using fixed waits causing flaky tests
• Not handling exceptions causing test stops
• Using hard assertions stopping tests early