QAPage – Software Testing Jobs, QA Resources & Careers

QAPage Navigation & Directory
Type any keyword to search live pages, tools, or press Search to query site-wide.

Automation Testing Notes In PDF: Complete Guide for QA Beginners

Automation Testing Notes In PDF

Automation Testing Notes,  Automation Testing is a software testing technique in which testers use tools and scripts to execute test cases automatically instead of performing every testing step manually.

In simple words, automation testing means using a computer program to check whether an application is working as expected.

For example, imagine you are testing a login page. You need to enter a username and password, click the Login button, and check whether the user can log in successfully.

  • Manual Testing: A tester performs these steps manually.

  • Automation Testing: A script performs these steps automatically and verifies the result.

    Automation Testing Notes

1. What is a Test Automation Framework?

 A test automation framework is a collection of rules, reusable code, tools, and methods that help us write and run automated test cases in an organized way.
It helps us avoid writing the same code again and again. It also makes test scripts easier to manage and update.

Why do we need a framework?

  • To reuse the same code in different test cases.
  • To avoid writing duplicate code.
  • To keep test data separate from test scripts.
  • To generate test execution reports.
  • To handle errors and failures properly.
  • To make test scripts easier to maintain.
  • To run tests in a consistent way.

Types of automation frameworks

Framework
Simple explanation
Linear
Test steps are written one after another, with limited code reuse.
Modular
The application is divided into modules, such as Login, Search, and Checkout.
Data-driven
The same test script runs with different sets of test data.
Keyword-driven
Test actions use keywords such as CLICK, TYPE, and VERIFY.
Hybrid
A combination of two or more framework approaches.
BDD
Test scenarios are written in a business-friendly format, often using Given, When, and Then.

Practical example

Suppose you are testing a shopping website and need to test the login functionality for 50 users.
Without a framework, you might write separate scripts for all 50 users.
With a data-driven framework, you write one login test script and provide 50 different sets of usernames and passwords.

Interview question: What is a test automation framework?

Answer:
“A test automation framework is a collection of rules, reusable code, tools, and methods used to create and run automated test cases. It helps us reduce duplicate code, manage test data, generate reports, and maintain test scripts easily. Common approaches include data-driven, keyword-driven, modular, hybrid, and BDD frameworks.”
Follow-up question: What framework have you used?
Explain the framework you have actually worked with. For example, if you have used Selenium with Java and TestNG, explain how you organized page classes, test classes, reusable methods, test data, and reports.
Do not say you have practical experience with a framework if you have only studied it.

2. Automation Testing Tools Overview

Automation testing tools help us run test cases automatically instead of performing every step manually.
These tools perform actions such as opening a website, entering data, clicking buttons, and checking whether the actual result matches the expected result.

Common automation testing tools

Selenium
Selenium is used to automate web browsers. It supports programming languages such as Java, Python, C#, and JavaScript.
Playwright
Playwright is a modern browser automation framework. It provides automatic waiting for many actions and supports Chromium, Firefox, and WebKit.
Cypress
Cypress is commonly used for testing web applications. It provides an interactive test runner and useful debugging features.
Appium
Appium is used to automate mobile applications on Android and iOS, including supported native and hybrid applications.
Postman
Postman is used to send API requests and check API responses. It can also be used to automate API testing.

Quick comparison

Feature
Selenium
Playwright
Cypress
Main use
Web UI automation
Web UI automation
Web application testing
Language options
Multiple languages
Multiple languages
Mainly JavaScript/TypeScript
Browser support
Multiple browsers
Chromium, Firefox, WebKit
Supported browsers, with tool-specific limitations
Waiting
Explicit/implicit waits and other techniques
Built-in automatic waiting
Built-in retry and waiting behavior
Ecosystem
Large and mature
Modern and growing
Good experience for front-end testing

Interview question: Which automation tool is best?

Answer:
“There is no single best automation tool for every project. Selenium is useful when we need support for different programming languages and a mature ecosystem. Playwright is useful for modern web applications and cross-browser automation. Cypress is useful for front-end testing and debugging. I would choose a tool based on the project requirements, browser support, team skills, and available integrations.”
Remember: A tool and a framework are not always the same thing. Selenium WebDriver helps automate browsers. TestNG or JUnit can help run tests and perform assertions. A complete automation framework combines different components in an organized way.

3. Selenium, Playwright and Cypress Introduction

A. Selenium

Selenium WebDriver is used to automate web browsers through programming languages and browser automation support.
It is commonly used with Java, TestNG, Maven, and Page Object Model (POM).
Example: Automatically log in to a shopping website, search for a product, add it to the cart, and check the checkout page.
driver.findElement(By.id("username")).sendKeys("tester");
driver.findElement(By.id("password")).sendKeys("Test123");
driver.findElement(By.id("login")).click();

B. Playwright

Playwright is a modern browser automation framework. It automatically waits for many elements to become ready before performing actions. It also supports browser automation across Chromium, Firefox, and WebKit.
Example: Find a login button, click it when it is ready, and check whether the dashboard appears.
await page.getByRole('button', { name: 'Login' }).click();await expect(page.getByText('Dashboard')).toBeVisible();

C. Cypress

Cypress is commonly used for front-end and end-to-end testing. It can automatically retry queries and assertions until they pass or a timeout occurs.
cy.get('#username').type('tester');
cy.get('#password').type('Test123');
cy.get('#login').click();
cy.contains('Dashboard').should('be.visible');

Interview question: What is the difference between Selenium, Playwright, and Cypress?

Answer:
“Selenium, Playwright, and Cypress are used to automate web application testing. Selenium supports multiple programming languages and has a mature ecosystem. Playwright provides automatic waiting and supports cross-browser automation. Cypress provides an interactive test runner and automatic retry features. I would choose the tool based on the project requirements, browser support, team experience, and integration needs.”
Follow-up: Does Selenium support mobile app automation directly?
Selenium WebDriver is mainly used for browser automation. Appium is commonly used to automate native and hybrid mobile applications.

4. Selenium WebDriver Architecture

What is Selenium WebDriver architecture?

Selenium WebDriver architecture explains how our automation script sends commands to a browser and receives the results.
1. Test Script
Java / Python / C# / JavaScript
2. Selenium WebDriver API
Receives automation commands
3. Browser Driver
Communicates with the browser
4. Web Browser
Chrome / Firefox / Edge / Safari
The response travels back through the same communication path.
Selenium WebDriver uses a standard browser automation interface. For remote execution, we can also use Selenium Server or Selenium Grid.

Components explained

  1. Test script: This contains the instructions we want the browser to perform, such as opening a website, entering text, clicking buttons, and checking results.
  2. WebDriver API: It provides methods such as get(), findElement(), click(), and sendKeys().
  3. Browser driver: It communicates with the browser and handles the requested automation commands.
  4. Browser: The browser performs the requested actions on the application.
  5. Response: The result or error is sent back to the automation script.

Practical example

When you write:
driver.get("https://example.com");
Selenium sends the command through its browser automation mechanism. The browser opens the requested website, and control returns to the script.

Interview question: Explain Selenium WebDriver architecture.

Answer:
“Selenium WebDriver architecture consists of the test script, WebDriver API, browser driver, and browser. The test script sends commands through the WebDriver API. The browser driver communicates with the browser, and the browser performs the requested action. The response then returns to the script. For remote execution, we can use Selenium Server or Grid.”

5. Client-Server Communication in Selenium

What is client-server communication?

Client-server communication means one component sends a request to another component, and the other component processes the request and sends back a response.
In Selenium, the client is generally our automation script. The browser automation endpoint receives the commands and returns the results.

How does communication work?

  1. The tester writes a Selenium script.
  2. The script sends a command, such as clicking a button.
  3. Selenium sends the command using the WebDriver protocol.
  4. The browser driver or remote WebDriver endpoint processes the command and communicates with the browser.
  5. The browser performs the action and sends back a response.
  6. The script continues running or reports an error if the command fails.

Example

driver.findElement(By.id("login")).click();
The script requests a click on the element with the ID login. The browser automation endpoint processes the request and returns the result.

What is the difference between local and remote execution?

Local execution
Remote execution
Browser automation runs on our local machine.
Browser automation runs on a remote machine or environment.
Usually easier to configure.
Requires a remote endpoint or Selenium Grid setup.
Useful for development and debugging.
Useful for distributed and cross-browser execution.

Interview question: What protocol does Selenium WebDriver use?

Answer:
“Selenium 4 uses the W3C WebDriver standard for browser automation. Commands and responses are exchanged between the client and the browser automation endpoint. For remote execution, Selenium Server or Grid can route commands to the appropriate browser environment.”
Important: Do not confuse Selenium client-server communication with the application’s own client-server communication. Selenium controls the browser, while the application may separately communicate with its backend through HTTP APIs.

6. Browser Drivers and Browser Automation

What is a browser driver?

A browser driver is a component that helps automation software communicate with a particular browser.
Common examples include:
  • ChromeDriver — Google Chrome.
  • GeckoDriver — Mozilla Firefox.
  • Edge WebDriver — Microsoft Edge.
  • Safari’s built-in WebDriver support — Safari.
The setup depends on the browser, operating system, and Selenium version. Selenium Manager can help find, download, and configure the required drivers automatically.

What is browser automation?

Browser automation means controlling browser activities through code instead of performing every action manually.
Examples include:
  • Opening a website.
  • Logging in.
  • Filling out forms.
  • Selecting dropdown options.
  • Moving between pages.
  • Taking screenshots.
  • Checking displayed results.

Example using Selenium with Java

WebDriver driver = new ChromeDriver();driver.get("https://example.com");System.out.println(driver.getTitle());driver.quit();
Explanation:
  • new ChromeDriver() starts a Chrome WebDriver session.
  • get() opens the requested URL.
  • getTitle() returns the page title.
  • quit() closes the browser session and its associated windows.

Difference between close() and quit()

close()
quit()
Closes the current browser window.
Closes all windows associated with the WebDriver session.
The session may remain active if other windows exist.
Ends the WebDriver session.

Interview question: What happens if the browser and driver versions are incompatible?

Answer:
“If the browser and driver versions are incompatible, Selenium may fail to start the browser session or show compatibility errors. I would check the browser version, driver version, Selenium version, operating system compatibility, and configuration. Then I would update or configure a compatible driver and run the test again.”

7. Locator Strategies

What is a locator?

A locator is a method used to find a web element on a page. For example, we use locators to find textboxes, buttons, links, checkboxes, and dropdowns.
Selenium provides different locator strategies through the By class.

Main Selenium locators

Locator
Example
When to use
ID
By.id("email")
When an element has a unique, stable ID
Name
By.name("username")
When an element has a useful name attribute
Class name
By.className("login-btn")
When an element has a single CSS class
Tag name
By.tagName("input")
When we want to find elements by HTML tag
Link text
By.linkText("Contact Us")
When we know the exact link text
Partial link text
By.partialLinkText("Contact")
When we know part of the link text
CSS selector
By.cssSelector("#email")
When we need a flexible CSS selector
XPath
By.xpath("//input[@id='email']")
When we need to find elements using attributes, text, or relationships

Example

Consider this HTML:
<input id="email" name="userEmail" type="text"><button id="login">Login</button>
Selenium code:
driver.findElement(By.id("email"))      .sendKeys("tester@example.com");driver.findElement(By.id("login"))      .click();

How to choose a good locator

  • Prefer unique and stable IDs when available.
  • Use meaningful attributes such as name or dedicated test attributes.
  • Keep CSS selectors and XPath expressions simple.
  • Avoid using changing CSS classes or long absolute XPath paths.
  • Check that the locator finds the correct element.

Interview question: Which locator is best in Selenium?

Answer:
“There is no single best locator for every situation. I generally prefer a unique and stable ID because it is easy to read and maintain. If an ID is unavailable, I consider name attributes, CSS selectors, or XPath. I always check that the locator identifies the correct element.”

Follow-up: What is the difference between findElement() and findElements()?

  • findElement() returns the first matching element. If no element matches, it throws NoSuchElementException.
  • findElements() returns a list of matching elements. If no elements match, it returns an empty list.
WebElement login = driver.findElement(By.id("login"));List<WebElement> buttons =    driver.findElements(By.tagName("button"));

8. XPath and CSS Selectors

XPath and CSS selectors are two common ways to find web elements. Both are important for automation testing interviews.

A. XPath

XPath is used to find specific elements in an HTML or XML document.
Common XPath examples
Assume the page contains a username field and a login button.
//input[@id='username']
1. Find an element using its ID.
//input[@name='email']
2. Find an element using its name attribute.
//button[text()='Login']
3. Find a button with the exact text Login.
//button[contains(text(),'Submit')]
4. Find a button whose text contains Submit.
//input[@id='username' and @type='text']
5. Find an element that matches both conditions.
//label[text()='Email']/following-sibling::input
Find an input that comes after a matching label as a sibling, assuming the HTML has this relationship.

Absolute vs relative XPath

  • Absolute XPath: Starts from the document root and describes the complete path, such as /html/body/div/form/input.
  • Relative XPath: Starts with a search expression such as //input[@id='username'].
Relative XPath is generally easier to maintain because it does not depend on the complete page structure.

B. CSS selectors

CSS selectors help us find elements using IDs, classes, attributes, and relationships.
#username
1. Find an element with the ID username.
.login-btn
2. Find elements with the class login-btn.
input[name='email']
3. Find an input with the name email.
input[type='password']
4. Find password input fields.
form input
Find input elements inside a form.

XPath vs CSS selector

Feature
XPath
CSS selector
Find by ID/class
Yes
Yes
Find by attributes
Yes
Yes
Find by visible text
Supports text-based expressions
No direct general text-matching selector
Navigate to parent
Supported
No general parent selector in traditional CSS
Navigate relationships
Supports rich navigation
Supports standard relationships
Readability
Can become complex
Often concise

Interview question: Which is faster, XPath or CSS?

Answer:
“CSS selectors are often shorter and easier to read, but CSS is not always faster than XPath. Performance depends on the browser, selector, DOM structure, and implementation. I choose whichever selector is simple, reliable, and uniquely identifies the element.”

Follow-up: What is dynamic XPath?

Dynamic XPath is an XPath expression used when some element attributes or text values can change.
Example:
//button[contains(@id,'submit')]
This finds a button whose ID contains submit, provided the expression matches the intended element uniquely.
Important: Do not make the locator too broad. It should handle expected changes without finding the wrong element.

9. Handling Dynamic Web Elements

What is a dynamic web element?

A dynamic web element is an element whose attributes, position, visibility, text, or presence can change while the application is running.
For example, a button may have a changing ID, search results may appear after an API response, or a popup may appear after clicking another button.

Common types of dynamic elements

  1. Elements with changing IDs or class names.
  2. Elements that appear after an API response.
  3. Elements that disappear after an action.
  4. Elements inside dynamically loaded tables.
  5. Autocomplete dropdown suggestions.
  6. Popups, modals, and notifications.
  7. Elements that are replaced when part of the page updates.

How to handle dynamic elements

Method 1: Use stable attributes
Prefer stable IDs, names, accessible roles, or dedicated test attributes instead of changing generated IDs.
Method 2: Use dynamic XPath or CSS
By submitButton =    By.xpath("//button[contains(@id,'submit')]");
Method 3: Use explicit waits
Wait until the element becomes visible, clickable, or present, depending on what you need to do.
Method 4: Find the element again
If the application replaces an element in the DOM, locate it again instead of using the old reference.

Example: Handling an autocomplete dropdown

Suppose you type Pun into a city field. The application displays Pune, Punjab, and other suggestions.
driver.findElement(By.id("city")).sendKeys("Pun");WebDriverWait wait =    new WebDriverWait(driver, Duration.ofSeconds(10));WebElement pune = wait.until(    ExpectedConditions.elementToBeClickable(        By.xpath("//li[normalize-space()='Pune']")    ));pune.click();
This code waits until the Pune suggestion becomes clickable before selecting it.

Important exception: StaleElementReferenceException

This error occurs when the script uses an old element reference that is no longer connected to the current DOM.
Possible solutions:
  • Find the element again.
  • Wait for the updated element.
  • Check whether the page was re-rendered.
  • Avoid storing element references for too long when the page changes frequently.

Interview question: How do you handle dynamic web elements in Selenium?

Answer:
“I handle dynamic elements by using stable attributes, suitable XPath or CSS selectors, and explicit waits. If the DOM changes and an element reference becomes stale, I locate the element again. I also check whether the issue is caused by timing, a locator change, or the application’s behavior.”

10. Synchronization and Wait Strategies

What is synchronization in automation testing?

Synchronization means making sure that the automation script and the application are ready at the right time.
For example, a page may open before its API responses, images, search results, or buttons are ready. If the script acts too early, the test may fail even when the application is working correctly.

Types of waits in Selenium

1. Implicit wait
An implicit wait applies to element-location operations. Selenium waits up to the configured time for an element to be found.
driver.manage().timeouts()      .implicitlyWait(Duration.ofSeconds(10));
2. Explicit wait
An explicit wait waits for a particular condition, such as an element becoming visible or clickable.
WebDriverWait wait =    new WebDriverWait(driver, Duration.ofSeconds(10));wait.until(    ExpectedConditions.visibilityOfElementLocated(        By.id("dashboard")    ));
3. Fluent wait
Fluent wait lets us configure the maximum waiting time, polling interval, and optionally which exceptions to ignore.
Wait<WebDriver> wait = new FluentWait<>(driver)    .withTimeout(Duration.ofSeconds(15))    .pollingEvery(Duration.ofMillis(500))    .ignoring(NoSuchElementException.class);
4. Hard wait
A hard wait pauses execution for a fixed amount of time.
Thread.sleep(3000);
This is usually less useful because the script waits for the full duration even if the element becomes ready earlier.

Implicit wait vs explicit wait

Implicit wait
Explicit wait
Applies to element-location operations.
Waits for a specific condition.
Configured globally for the driver.
Configured where needed.
Does not directly wait for a specific state such as clickability.
Can wait for visibility, clickability, or other supported conditions.
Mixing it with explicit waits can cause confusing timeout behavior.
Often preferred when waiting for a particular condition.
Best practice: Prefer explicit waits for specific UI conditions. Avoid mixing implicit and explicit waits without understanding the effect on timeout behavior. Use fixed sleeps only when there is a good reason.

What is a timeout?

A timeout is the maximum time allowed for an operation or condition to complete.
For example, if the dashboard does not become visible within 10 seconds, an explicit wait can fail with a timeout exception.

Interview question: Why do we use waits in Selenium?

Answer:
“We use waits to make sure the automation script works at the right time. They help us handle delayed elements, API responses, and dynamic page updates. I generally prefer explicit waits because they wait for a specific condition instead of waiting for a fixed amount of time.”

11. Assertions and Validations

What is an assertion?

An assertion checks whether the actual result matches the expected result. It helps us decide whether a test condition has passed or failed.

What is validation?

Validation means checking whether the application works according to the requirements. Assertions are commonly used to perform these checks in automated tests.

Types of assertions

Assertion
Example
Title assertion
Check the page title
URL assertion
Check the destination URL
Text assertion
Check the welcome message
Visibility assertion
Check whether the dashboard is visible
Value assertion
Check the value in a textbox
State assertion
Check whether a checkbox is selected
Negative assertion
Check whether an error message is absent

Example using TestNG

String actualTitle = driver.getTitle();
Assert.assertEquals(
    actualTitle,
    “Dashboard”
);
This checks whether the actual page title matches Dashboard.
Another example:
WebElement message = driver.findElement(By.id("welcome"));
Assert.assertTrue( message.isDisplayed(), "Welcome message should be visible");

Hard assertion vs soft assertion

Hard assertion: Stops the current test method when an assertion fails.
Soft assertion: Records assertion failures and allows the test method to continue until the recorded failures are checked using assertAll().
Example:
SoftAssert soft = new SoftAssert();
soft.assertEquals(actualTitle,"Dashboard");
soft.assertTrue(message.isDisplayed());
soft.assertAll();
If assertAll() is not called, recorded soft assertion failures may not cause the test to be reported as failed.

Practical example: Login testing

Expected behavior:
  • Correct credentials should open the dashboard.
  • Incorrect credentials should display an error message.
For valid login:
Assert.assertTrue(    driver.getCurrentUrl().contains("dashboard"));
For invalid login:
Assert.assertTrue(    driver.findElement(By.id("error")).isDisplayed());
The assertion should match the application’s requirements. Checking only part of a URL may not be enough to fully verify a successful login.

Interview question: What is the difference between verification and assertion?

Answer:
“Verification means checking whether the actual result matches the expected result. An assertion is a way to perform that check in an automated test. In TestNG, a hard assertion generally stops the current test method when it fails, while a soft assertion can collect multiple failures until assertAll() is called.”

12. Reusable Methods

What are reusable methods?

Reusable methods are functions that we write once and use in multiple test cases.
They help us avoid duplicate code, make test scripts easier to read, and simplify maintenance.

Example without reusable methods

Suppose five test cases need to log in to an application.
If we write all the login steps separately in each test case, we must update five places whenever the login process changes.

Example with a reusable method

public void login(String username, String password)
{
driver.findElement(By.id("username")).sendKeys(username); driver.findElement(By.id(“password”)) .sendKeys(password);
driver.findElement(By.id(“login”)) .click();
}
Now we can call the method from any test case:
login("tester", "Test123");
The method accepts different usernames and passwords, so we can use it for different test scenarios.

Common reusable methods

  • login()
  • logout()
  • searchProduct()
  • selectDropdownValue()
  • waitForElement()
  • takeScreenshot()
  • verifyPageTitle()

What is the Page Object Model (POM)?

Page Object Model is a design pattern that organizes automation code based on application pages or components.
For example:
  • LoginPage.java contains login page locators and actions.
  • DashboardPage.java contains dashboard interactions.
  • LoginTest.java contains login test scenarios and assertions.
This approach reduces repeated UI code and makes maintenance easier.

Interview question: Why do we use reusable methods?

Answer:
“Reusable methods help us avoid duplicate code, improve maintenance, and make test cases easier to understand. For example, I can create one login method and use it in multiple test cases with different credentials. In larger projects, I can organize page-related locators and actions using Page Object Model.”
Follow-up: What is the difference between a reusable method and POM?
A reusable method is a function that we can call multiple times. POM is a design pattern that organizes page-related locators and methods into separate classes or objects.

13. Test Data Management

What is test data management?

Test data management means preparing, storing, organizing, and maintaining the data needed to execute test cases.
Examples include usernames, passwords, customer details, product IDs, addresses, account balances, and API request data.

Why is test data management important?

  • To test positive and negative scenarios.
  • To run data-driven tests.
  • To avoid hardcoding values in test scripts.
  • To make tests repeatable.
  • To keep test logic separate from test data.
  • To manage data across different environments.
  • To protect sensitive information.

Common test data sources

Source
Example use
Excel or CSV
Store multiple input combinations
JSON or XML
Store structured test data and API payloads
Database
Get existing records or prepare test data
Properties or configuration files
Store environment-specific settings
Test data providers
Supply multiple datasets to test cases
API setup utilities
Create data before a test starts

Example: Data-driven login testing

Suppose you need to test these cases:
Username
Password
Expected result
Valid user
Valid password
Login succeeds
Valid user
Invalid password
Error displayed
Invalid user
Any password
Login fails
Empty
Empty
Required-field validation
You can store this data separately and run the same test logic with each set of inputs.
Example JSON:
[  {   
"username": "validUser",
"password": "ValidPassword",
"expected": "success"
},
{
"username": "validUser",
"password": "WrongPassword",
"expected": "failure"
}
]
This is example data, not a real account.

Interview question: What is data-driven testing?

Answer:
“Data-driven testing is an approach where the same test logic runs with different sets of input data and expected results. The data can come from Excel, CSV, JSON, a database, or a test framework’s data provider. It helps us test more scenarios without writing a separate script for every input.”

Follow-up: How do you handle sensitive test data?

  • Do not save real passwords, API keys, or tokens in source code.
  • Use test accounts or sample data approved for testing.
  • Store secrets in environment variables or an approved secret manager.
  • Follow data masking and access-control rules.
  • Keep test data separate between environments when required.

14. Automation Test Execution

What is automation test execution?

Automation test execution means running automated test scripts against an application and collecting the results.

Typical execution workflow

1. Prepare test cases and test data
2. Configure browser and environment
3. Execute the automation suite
4. Perform assertions and validations
5. Capture logs, screenshots, and results
6. Analyze failures and report defects
7. Fix issues and rerun affected tests

Different ways to execute automation tests

1. IDE execution
Run an individual test or test class using an IDE such as IntelliJ IDEA or Eclipse.
2. Command-line execution
Run tests using a build tool such as Maven.
Example:
mvn test
This command runs the tests configured for Maven’s test lifecycle. The actual results depend on the project configuration.
3. Test suite execution
Run multiple test cases together using a framework such as TestNG or JUnit.
4. CI/CD execution
Run tests automatically as part of a continuous integration pipeline using tools such as Jenkins or GitHub Actions.
5. Parallel execution
Run independent tests at the same time using multiple browser sessions or environments, provided the framework and test data support parallel execution.

Types of execution

  • Smoke testing: Checks whether the application’s main functions are working.
  • Sanity testing: Focuses on a specific change or area after a modification.
  • Regression testing: Checks whether existing functionality still works after changes.
  • Cross-browser testing: Checks application behavior across supported browsers.
  • Data-driven execution: Runs the same test with different sets of data.

How do you analyze an execution report?

Check the following:
  1. Total number of tests executed.
  2. Number of passed, failed, and skipped tests.
  3. Failure messages and stack traces.
  4. Screenshots and logs.
  5. Whether the problem is caused by the application, test script, environment, or test data.
  6. Whether rerunning the test is justified and what the new result shows.

Interview question: How do you execute an automation test suite?

Answer:
“First, I check that the test environment, browser configuration, and test data are ready. I run the tests using the IDE, build tool, or CI/CD pipeline. After execution, I review the reports, logs, screenshots, and failure messages. I identify the reason for each failure, report genuine application defects, fix script issues when necessary, and rerun the affected tests.”

15. Common Automation Errors and Debugging

Automation errors are common in real projects. Interviewers often ask what an exception means, why it occurs, and how you would fix it.

Common Selenium exceptions

Exception
Simple meaning
Common solution
NoSuchElementException
The element could not be found.
Check the locator, page state, frame, and timing.
TimeoutException
A wait condition did not finish within the allowed time.
Check the condition, locator, application state, and timeout.
StaleElementReferenceException
The old element reference is no longer attached to the current DOM.
Find the element again after the page updates.
ElementNotInteractableException
The element cannot be used in its current state.
Check visibility, enabled state, and the intended target.
ElementClickInterceptedException
Another element is blocking the click.
Check overlays, popups, loading screens, or layout issues.
NoSuchFrameException
The requested frame could not be found.
Check the frame locator and page structure.
NoAlertPresentException
No browser alert is available when the script tries to handle one.
Check whether the alert appeared and wait if needed.
SessionNotCreatedException
A WebDriver session could not be started.
Check browser/driver compatibility, configuration, and environment.
InvalidSelectorException
The locator syntax is incorrect.
Correct the XPath or CSS selector.
NoSuchWindowException
The referenced browser window or tab does not exist.
Check window handles and switching logic.

A. NoSuchElementException

Example situation: The script tries to find the login button but cannot find it.
Possible reasons:
  • The ID or XPath is incorrect.
  • The element has not loaded yet.
  • The element is inside an iframe.
  • The application has opened a different page.
  • The page structure has changed.
How to debug it: Inspect the DOM, verify the locator, check the current URL, and confirm whether a wait or frame switch is needed.

B. StaleElementReferenceException

Example situation: You locate a product row. After refreshing the search results, the script tries to use the old row reference.
Solution: Find the row again after the update. Do not assume an old element reference will remain valid after the DOM changes.

C. ElementClickInterceptedException

Example situation: You click the Submit button, but a loading overlay is covering it.
Solution:
  1. Check the overlay and page state.
  2. Wait for the overlay to disappear.
  3. Wait until the intended button becomes clickable.
  4. Try the action again.
  5. If it still fails, investigate the page layout or application defect.
Do not immediately use JavaScript clicks to bypass the problem, because this might hide a real usability issue.

D. TimeoutException

Example situation: The dashboard should appear within 10 seconds, but the explicit wait expires.
Solution:
  • Check whether the page loaded correctly.
  • Verify the locator and expected condition.
  • Check backend/API response delays and browser logs when relevant.
  • Check whether the timeout is reasonable.
  • Increase the timeout only when the application’s expected behavior supports it.

E. InvalidSelectorException

Example: An XPath expression contains mismatched brackets or quotes.
Incorrect:
By.xpath("//button[@id='login'");
Correct:
By.xpath("//button[@id='login']");

A systematic debugging process

  1. Read the complete exception message and stack trace.
  2. Identify the exact test step that failed.
  3. Check the current page, browser state, and locator.
  4. Check waits, frames, windows, overlays, and test data.
  5. Review screenshots, browser logs, and application/API responses when available.
  6. Reproduce the issue and identify the root cause.
  7. Fix the script or report an application defect, depending on the evidence.
  8. Run the failed test again and execute relevant regression tests.

Interview question: How do you debug a failed automation test?

Answer:
“When an automation test fails, I first read the exception message and stack trace to understand which step failed. I check the locator, current page state, waits, browser session, test data, and relevant logs or screenshots. Then I identify whether the problem is caused by the application, test script, environment, or test data. After fixing the root cause, I rerun the affected test and relevant regression tests.”

Final Interview Revision: Module 3

Use these questions to check your understanding of the complete module.
1. What is a test automation framework?
2. What is Selenium WebDriver?
3. What is a locator?
4. What is the difference between XPath and CSS?
5. What is an explicit wait?
6. What is an assertion?
7. What is POM?
8. What is data-driven testing?
9. What is regression testing?
10. How do you debug automation failures?
Reveal all answers

Practical learning recommendation

For automation interviews, focus on understanding the concepts and explaining them with examples. Practise writing small scripts instead of memorizing definitions alone.
A good learning order is:
  1. Java basics and Selenium WebDriver.
  2. Locators, XPath, and CSS selectors.
  3. Waits, dynamic elements, and exceptions.
  4. Assertions and TestNG.
  5. Reusable methods and Page Object Model.
  6. Test data, reporting, and Maven execution.
  7. A small end-to-end project, such as login, search, and checkout testing.

Official documentation for further study

Interview tip: When answering a technical question, follow this simple structure: definition → why we use it → practical example → common problem or limitation. This helps you give clear answers, even as a fresher.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top