Real-Time & Career
Automation Real-Time Interview Questions & Answers
Real-time automation testing interview questions answered from project experience: explaining your framework, flaky tests, CI failures, test data, parallel runs and tricky UI elements.
Interview Questions
Showing 15 of 50 questions
In my last project we used a hybrid framework with Selenium and Java, TestNG as the runner, Maven for builds, and the Page Object Model for UI layers. Test data came from JSON and Excel, reports from Extent, and everything ran in Jenkins on Selenium Grid.
I automate stable, repetitive, high-value cases first: smoke and regression of critical flows, data-driven scenarios, and cross-browser checks. I avoid automating one-time tests, frequently changing UI, and things needing human judgement like usability.
I start by analysing the nightly run failures and raising bugs or fixing scripts. Then I attend stand-up, work on automating sprint stories, review teammates' pull requests, and help with manual testing of new features when needed.
I avoid generated IDs and use stable attributes like data-testid, name, or visible text, with relative XPath or CSS using contains or starts-with. Where possible I ask developers to add test IDs.
For iframes I switch into the frame with switchTo().frame and switch back with defaultContent. For new windows or tabs I store the parent handle, loop through getWindowHandles, switch to the new one, and return when done.
If the page has an input of type file, I just sendKeys the absolute file path, which works on Grid too with a LocalFileDetector. I avoid Robot class or AutoIt because they break in headless and remote runs.
We use explicit waits with WebDriverWait wrapped in reusable helper methods, and we keep implicit wait at zero to avoid mixing them. Thread.sleep is not allowed in code review.
I first find the root cause rather than just adding retries: usually missing waits, test data collisions, shared state, or environment instability. Flaky tests are quarantined from the release gate until fixed, and we use limited retry only as a short-term safety net.
I compare the environments: headless mode, screen resolution, browser and driver versions, timing on slower agents, test data, and environment URLs. Screenshots, logs, and videos from the CI run usually show the cause quickly.
We run tests in parallel with TestNG at the methods or classes level, and each thread gets its own WebDriver stored in a ThreadLocal. Tests run on Selenium Grid in Docker, which cut our regression from about 4 hours to 40 minutes.
We keep static data in JSON or properties per environment and create dynamic data through APIs or database setup before tests, so each test owns its data. Data is cleaned up after the run where possible.
We used Extent Reports, later Allure, attached to TestNG listeners. Each test shows steps, environment, browser, and on failure a screenshot and logs, and the report link is posted to the team channel after each Jenkins run.
Smoke tests run on every deployment to QA via a Jenkins pipeline trigger, and the full regression runs nightly. Parameters like environment, browser, and suite are passed to Maven, and failures notify the team on Slack or email.
CAPTCHA should not be automated; we ask developers to disable it or use a test key in QA environments. For OTP we fetch it from a test API, the database, or a test email/SMS service like Mailosaur, or use a fixed OTP in lower environments.
Locators live only in page objects, so a UI change means updating one place. We use stable data-testid attributes, reusable components for common widgets, and move business validations to the API layer.