Automation Tester interview questions and answers

Selenium follows the W3C WebDriver standard. Your script uses a language binding, such as the Java or Python client, which turns each command into an HTTP request with a JSON body. The request goes to a browser driver, like ChromeDriver or GeckoDriver, which controls the real browser through the browser's own automation support, finds the element and sends back a response: an element reference, or an error such as NoSuchElementException.

WebDriver is an interface in Java, and ChromeDriver or FirefoxDriver implement it. In recent Selenium 4 versions, Selenium Manager can download the matching driver automatically, so you rarely manage driver files by hand. With Selenium Grid, the same requests go to a remote machine instead.

Selenium supports id, name, className, tagName, linkText, partialLinkText, cssSelector and xpath. I prefer a unique, stable id or a dedicated test attribute like data-testid, then CSS selectors, which are short and fast. XPath is useful when I need something CSS can't do, mainly finding an element by its visible text, for example //button[text()='Submit'], or moving up to a parent or across to a sibling, such as a row's Delete button in a table.

I avoid absolute XPaths like /html/body/div[3]/div[2], and auto-generated ids that change on every load, because they break when the page changes. Asking developers to add test ids is a good habit to mention.

An implicit wait is set once on the driver and makes every findElement keep trying for up to that time before failing. An explicit wait, WebDriverWait with ExpectedConditions, waits for a specific condition on a specific element, such as elementToBeClickable or visibilityOfElementLocated. A fluent wait is an explicit wait where you also set the polling interval and the exceptions to ignore.

Thread.sleep always waits the full time, so tests become slow, and it still fails if the page takes longer than you guessed. Prefer explicit waits for dynamic elements, and don't mix implicit and explicit waits, because the timeouts can combine and make waiting unpredictable.

For an iframe, switch into it first, with driver.switchTo().frame() using its index, name or id, or the frame's WebElement, which is the most reliable. Work inside it, then return with switchTo().defaultContent(), or parentFrame() for nested frames. For a JavaScript alert, use driver.switchTo().alert() and then accept(), dismiss(), getText() or sendKeys() for a prompt; waiting with ExpectedConditions.alertIsPresent() avoids timing failures.

For a new tab, store the current window handle, click the link, wait until there are two handles, then switch to the one that isn't the original. Close it and switch back when done. Forgetting to switch back is a common cause of failures in the next steps.

In the Page Object Model, each page or major component has a class that holds its locators and the actions a user performs there, such as LoginPage.loginAs(user, password). Tests call these methods and never touch locators, so when the UI changes, you fix one class instead of fifty tests.

To keep it maintainable: keep assertions in the tests, not the page classes; split big pages into components, like a header or a search panel used on many pages; put shared waits and clicks in a base page; and return the next page object from navigation methods so flows read clearly. PageFactory with @FindBy is optional; many teams now prefer plain By locators.

The order is @BeforeSuite, @BeforeTest, @BeforeClass, @BeforeMethod, then the @Test method, then @AfterMethod, @AfterClass, @AfterTest and @AfterSuite. @BeforeMethod and @AfterMethod run around every test method, which is where you usually open and close the browser. @BeforeTest runs once per test tag in testng.xml, not before each test method, which confuses many candidates.

Useful attributes on @Test include priority, dependsOnMethods, groups (for example smoke or regression), enabled and expectedExceptions. If you use Python, the equivalent is pytest fixtures with a scope of function, class, module or session, with setup before yield and teardown after it, often shared through conftest.py.

Data-driven testing runs the same test steps with many sets of data, kept separate from the code. Instead of writing ten login tests, you write one and feed it ten rows of usernames, passwords and expected results.

In TestNG, a @DataProvider method returns the data as an Object[][] or an Iterator, and the test takes it through dataProvider = "loginData". In pytest, @pytest.mark.parametrize does the same. The data usually comes from Excel (read with Apache POI), CSV or JSON files. Choose the rows with test design in mind: valid values, boundaries and invalid inputs, each with its expected result, so adding a case means adding a row, not code.

Describe the layers, then what you personally built. For example: "It was a hybrid framework in Java with Selenium, TestNG and Maven. Page classes held locators and actions; test classes held only steps and assertions; a BaseTest set up and closed the browser; utilities handled waits, screenshots, Excel data and reading config.properties for the URL and browser. Test data was in Excel and JSON. testng.xml defined the smoke and regression suites, Extent Reports produced HTML reports with screenshots of failures, and Jenkins ran the suite every night from Git."

Then add one problem you solved, like cutting flaky failures or run time. Be ready to draw the folder structure.

In TestNG, set parallel to methods, classes or tests in testng.xml with a thread-count; in pytest, use the pytest-xdist plugin with -n. To run across many browsers or machines, use Selenium Grid or a cloud grid.

The main problem is shared state. A static WebDriver shared by all threads makes tests drive each other's browsers, so keep one driver per thread, usually in a ThreadLocal<WebDriver>. Tests must also be independent: no test may rely on another's data or order, and each needs its own test user or data so two threads don't edit the same record. Reports and logs must be thread-safe too. Start with a few threads and increase while the results stay stable.

Use a reporting library such as Extent Reports or Allure, which show each test's steps, status, time and logs in an HTML report, and attach the report to the CI build. TestNG and the Maven Surefire plugin also produce basic reports and JUnit-style XML that Jenkins can read.

For screenshots, implement TestNG's ITestListener and, in onTestFailure, cast the driver to TakesScreenshot and call getScreenshotAs(OutputType.FILE), save it with the test name and time, and attach it to the report. In pytest, a hook in conftest.py does the same. Adding the page URL and browser console log alongside the screenshot makes failures much quicker to diagnose.

A List keeps items in order and allows duplicates: findElements returns a List<WebElement>, for example all the product names on a search page, which you can loop through or check are sorted. A Set holds only unique items: getWindowHandles returns a Set<String>, and adding values to a HashSet is an easy way to check that a dropdown has no duplicate options. A Map stores key-value pairs: a HashMap is handy for test data such as field name to value, or for counting how many times each status appears in a table.

Knowing which Selenium methods return which collection is a common follow-up.

Checked exceptions are checked by the Java compiler: you must catch them or declare them with throws, like IOException when reading a test data file. Unchecked exceptions extend RuntimeException and aren't forced on you, like NullPointerException.

Selenium's exceptions are unchecked, since WebDriverException extends RuntimeException. Common ones are NoSuchElementException (wrong locator, or the element isn't there yet), TimeoutException (an explicit wait's condition never came true), StaleElementReferenceException (the page re-rendered after you found the element, so find it again), ElementClickInterceptedException (something like a loader covers it) and NoSuchFrameException. Explain the cause and fix of each, not just the name.

Give concrete places. Inheritance: every test class extends a BaseTest that starts and closes the browser, and page classes extend a BasePage with shared waits. Encapsulation: locators are private inside page classes, and tests use only public methods like loginAs(). Abstraction: tests call those methods without knowing the steps inside, and WebDriver itself is an interface. Polymorphism: WebDriver driver = new ChromeDriver() lets the same code drive any browser, chosen from config at runtime; method overloading, such as two versions of a click helper, is the compile-time form.

Interviewers expect this question almost every time, so tie each concept to your own framework, not textbook definitions.

Git marks the conflicting lines in the file between <<<<<<<, ======= and >>>>>>> markers, showing your version and theirs. I open the file, usually in the IDE's merge tool, and decide line by line: keep mine, keep theirs, or combine both, for example when we each added a different locator. Then I remove the markers, run the affected tests locally, git add the file and commit or continue the rebase.

If I'm unsure what my teammate intended, I ask before choosing. To avoid conflicts, pull from the main branch often, keep branches short-lived and commit small changes, and split very large page classes so fewer people edit the same file.

Continuous integration means developers merge their changes into a shared branch often, and every merge automatically builds the code and runs tests, so problems are caught within minutes. A pipeline usually runs in stages: build, unit tests, deploy to a test environment, then API and UI automation, and later deployment to staging and production.

Fast tests run first and on every commit, such as unit tests and a small UI smoke suite. Longer regression suites often run nightly or before a release. If tests fail, the pipeline stops and the team is alerted, so a broken change doesn't move further. As an automation tester, your suite is one of the gates in that pipeline.

Create a Jenkins job, either a pipeline defined in a Jenkinsfile in the repository, or a freestyle job. Point it at the Git repository and branch, and set a trigger: on every push using a webhook, on a schedule such as every night, or after the deployment job finishes. The build step runs a Maven command such as mvn clean test, with the suite chosen in pom.xml or passed as a parameter, and the browser and environment passed as parameters too.

Run the browser in headless mode on the build agent, or point the tests at a Selenium Grid. Afterwards, publish the TestNG or JUnit XML results and the HTML report, and send an email or chat message on failure.

Treat flakiness as a bug, because a suite people don't trust gets ignored. First find the flaky tests: look at failure history across runs and rerun the failures to confirm they pass sometimes. Then find the cause. The usual ones are timing (fixed sleeps or missing explicit waits), test data shared between tests or left over from earlier runs, tests depending on each other's order, unstable test environments and dynamic locators.

Fix the cause; don't just add automatic retries, which hide real problems. While fixing, move a known flaky test to a quarantine group so it doesn't block the pipeline, and track how many tests are flaky as a team measure.

Look for what differs between the two machines. In headless mode the default window size is small, so elements may be hidden or laid out differently; set the window size explicitly. The CI agent may be slower, exposing missing waits. Browser and driver versions may differ. Configuration may differ: environment URL, credentials, files read from a local path, or a time zone or locale that changes date formats. The test data the CI run uses may already be used by another run.

Use the evidence: screenshots, browser logs and the report from the CI run. Running the suite locally in headless mode, or in the same Docker image the CI uses, usually reproduces it.

Automate tests that run often and give the same steps and checks each time: the regression suite, smoke tests on every build, data-heavy tests run with many inputs, and checks across several browsers. The feature should also be fairly stable, or the scripts will need constant fixing.

Keep manual the tests that need human judgement or change constantly: exploratory testing, usability and look-and-feel, a brand-new feature still being redesigned, and one-off checks where writing the script costs more than running it by hand. Things like CAPTCHA are deliberately hard to automate. A good answer also mentions the cost of maintaining scripts, not just writing them.

Start from the rules, for example: a code has 6 to 10 letters and digits, works only on orders of ₹1,000 or more, and expires on a set date. Partitions give one value per group: a valid code, an expired code, a code with special characters, and an order below the minimum. Boundaries add 5, 6, 10 and 11 characters, and orders of ₹999 and ₹1,000.

Each case becomes one row in a data provider with the input and the expected message, so a single test method covers them all. This keeps the suite small but strong: one well-chosen value per partition instead of dozens of similar runs that add time without finding new bugs.

Passing tests that miss bugs usually check too little. Common problems: tests click through a flow but assert only that a page loaded, not the values on it; most tests cover the happy path, with few negative or boundary cases; many tests repeat the same flow with trivial differences while risky areas have none; and the test data never resembles real data.

I'd map the production bugs to the suite to see where the gaps are, review assertions, and compare coverage with the requirements and risks. Moving some checks down to API or unit level, adding meaningful assertions and removing duplicates often gives a smaller suite that finds more. Count of tests is not a measure of quality.

Keep it to about a minute and centre it on what you automated and the results. "I'm an automation tester with [three] years' experience, currently at [company], testing a [domain] application. I work mainly with [Java, Selenium, TestNG and Jenkins] and [REST Assured or Postman] for APIs. In my current project I [your contribution, for example built the regression suite of 400 tests and cut the regression cycle from four days to one night]. I'm now looking for a role where I can [work on a larger framework, API or mobile automation, or a product company], which is why this role interests me."

End on why this job, not on a list of tools.

Show interest in both testing and coding, not just a trend. "I like testing because I enjoy finding problems, and I like coding because I enjoy building things. Automation combines both: I design tests and then write code that runs them on every build. In my training and projects I automated [the login and checkout flows of a demo site] with [Selenium and Java or Python], and seeing a suite run on its own and catch a broken change was very satisfying."

Avoid saying you chose it because manual testing is boring, and be ready to write some code if you claim a language.

Give a habit and an example, not a promise. "I focus on the fundamentals that carry across tools: a programming language, locators, waits, test design and CI. Then I learn new tools by building something small with them. For example, I [recreated part of my Selenium suite in Playwright] to compare them, and I follow the official documentation and release notes."

Mention a recent thing you learnt and why. Interviewers like candidates who can compare tools sensibly, such as Playwright's built-in auto-waiting, rather than ones who chase whichever is newest.

Use STAR, with numbers if you have them. "Regression took our team four days of manual work each release (situation). I was asked to automate the core flows (task). I prioritised the 150 most-used scenarios, built them with page objects and data providers, and set them to run nightly in Jenkins (action). Regression came down to one overnight run and caught [a pricing bug] two days before a release (result)."

A failure story works too if you show the lesson: "Our suite became so flaky that people stopped trusting it, so I…". Owning a mistake and fixing it is often more convincing than a success.

Do your research before the interview: look at recent offers for your experience and skills in your city through salary sites and people you know, and work out the range you'd accept. Then give a range, not one number, and tie it to your value: "Based on my [three] years in automation, the framework work I've done and the market for this role, I'm looking for something in the range of [your researched range]. I'm open to discussing it based on the overall package."

It's fine to ask for the role's budget first. Never lie about your current salary; companies often check payslips.