Scenario-Based Automation Testing Interview Questions

Headless mode or screen resolution, timing issues, environment data, missing dependencies, browser–driver version mismatch or parallel conflicts. Check logs and failure screenshots and make waits robust.

Keep credentials in external data, parameterise the test with a data provider, reuse a login method in a page class, and clear sessions between roles.

Set window size explicitly, use proper waits, check animations and viewport differences, and capture screenshots and logs to find timing issues.

Use mocks or stubs such as WireMock to simulate the dependency and test your service in isolation.

Re-locate the element after the DOM refreshes, use explicit waits for the refreshed element, don't keep element references for long, or wrap the action in retry logic.

Schedule the job, spin up environments or containers, run suites in parallel, store reports and screenshots, notify failures on Slack or email and track trends.

Do not automate it; ask for a test environment where CAPTCHA is disabled or use test keys, or a bypass token agreed with developers.

Maven project → POM with a BasePage → driver factory with ThreadLocal → config files → data-driven utilities (Excel/JSON) → TestNG or Cucumber runner → logging → Extent reports with screenshots on failure → Jenkins pipeline.

Automate stable, repetitive, high-risk and data-heavy flows (smoke, regression). Skip one-time tests, frequently changing UI and checks needing human judgement. Compare run frequency × manual time with build and maintenance cost.

Stabilise waits and data, isolate tests, use retries cautiously, quarantine unstable tests, run in consistent containers and track flaky rates.

Compare effort saved by running automated tests repeatedly against the cost of building and maintaining scripts, counting execution time, defects found earlier and release speed.

Use CSS or XPath with contains(), starts-with() or stable attributes, relative axes, or data-test attributes agreed with developers.

Check the glue path in the runner points to the package containing the step classes. Check the step text matches exactly, including quotes and parameter types, since {string} expects quoted text. Confirm the step class is under src/test/java and compiled, the annotation import is io.cucumber.java.en, and the Cucumber versions of core, java and the runner module match. Running with dryRun shows all unmatched steps quickly.

First run a report of step usage to find duplicate and unused steps. Agree a step vocabulary per domain, merge near-identical steps using parameters, and delete unused ones. Move logic out of steps into page objects and service helpers. Add a review checklist and a dryRun gate in CI. Do this incrementally by feature area so the suite keeps running while you clean up.

Partly. Readable scenarios still help testers and developers, but if nobody discusses examples before coding, Cucumber is only an extra layer over normal tests. I would first try to restart three-amigos sessions for complex stories. If the business truly will not engage, I would keep Gherkin only for key business flows and write lower-level tests in plain TestNG to reduce maintenance.

Create data in Given steps through APIs, record the created IDs in the scenario context, and delete them in an @After hook, which runs even when the scenario fails. Use unique names with a timestamp or UUID to avoid clashes in parallel runs. For shared environments, add a nightly cleanup job for leftover data tagged with a test prefix.

Likely shared state. Common causes are static RestAssured settings changed by one test, shared test data like the same user being updated by two tests, token reuse after another test logged out, or rate limits. Fix by using per-test RequestSpecification instead of global statics, creating unique data per test, isolating tokens, and checking server rate-limit responses such as 429.

Call the first page, check page size, total count and the next link or cursor. Loop through pages until there is no next page, collecting IDs, then assert no duplicates and the total matches the reported count. Also test edge cases: page 0, a page beyond the last, invalid page size and sorting stability. Cap the loop to avoid endless runs if the API misbehaves.

First confirm the server uses a self-signed or internal certificate. The proper fix is to import the company CA certificate into a truststore and configure REST Assured with trustStore(path, password). As a temporary measure in a test environment only, relaxedHTTPSValidation() skips checks. Never use relaxed validation against production, and raise the certificate issue with the infra team.

Because locators live only in page classes, I check which page object methods fail, update the changed locators in those few classes, and rerun. Usually 40 failures map to two or three locators. I would also ask developers to add stable data-testid attributes and review UI changes with QA early, so future changes do not break tests unexpectedly.

Create a ModalComponent class scoped to the modal root element, with methods like title(), confirm() and cancel(). Pages that open modals return the component, such as cartPage.removeItem() returning ConfirmModal. The component waits for itself to appear and disappear. This keeps modal logic in one place and avoids copying locators into every page.

I would not rewrite everything at once. First create the base structure: DriverManager, BasePage and config. Then pick the most-used flows, such as login and navigation, create page objects for them and migrate tests touching those pages. Agree that new tests must use POM, and migrate old tests when they are next changed. Track progress so the team sees improvement in maintenance time.

Possibly testFailureIgnore is set to true in Surefire, the shell step uses || true, or the script swallows Maven's exit code. Sometimes tests catch exceptions and never fail. Check the console log for Maven's BUILD result and Surefire summary. Fix the configuration so failures produce a non-zero exit, or use junit publishing to mark the build unstable when tests fail.

Run mvn dependency:tree to see which versions are pulled in transitively. Maven picks the nearest version, which may not be the one you need. Fix by declaring the required version in dependencyManagement, excluding the unwanted transitive dependency with exclusions, or upgrading the library that brings the old version. Conflicts often appear as NoSuchMethodError or ClassNotFoundException at runtime.

Measure first: find the slowest tests and setup steps. Then run tests in parallel across Grid nodes or containers, replace UI setup with API calls, remove duplicate coverage, move checks down to API level, split the suite into shards across agents, and cache Maven dependencies. Aim for a smoke stage under 15 minutes on every commit and a parallel regression under an hour.

Compare what differs: configuration URLs, test data, feature flags, user permissions, network or proxy, browser versions and timing due to slower servers. Check logs and screenshots from staging and rerun one failing test with verbose logging. Often the issue is missing data or a flag. Fix by making environment settings explicit and creating required data in test setup.

Read the documented limit, then send requests quickly until you exceed it and assert a 429 Too Many Requests response with headers like Retry-After or remaining quota. Wait for the window to reset and confirm requests succeed again. Also check limits are per user or key as designed. Run these tests in isolation so they do not throttle the rest of the suite.

Separate concerns: for most functional tests, stub the payment API with WireMock returning success, failure and timeout responses, so tests are fast and deterministic. Keep a small set of integration tests against the sandbox, with longer timeouts and retries for network errors, run on a schedule. Report sandbox slowness separately so it does not block every pull request.

Usually a configuration method failed, such as @BeforeClass or @BeforeSuite throwing an exception, which makes TestNG skip dependent tests. Other causes are dependsOnMethods on a failed test, a group filter excluding setup methods without alwaysRun, or a DataProvider that threw an exception. Check the configuration failures section of the report and the log for the first exception.

Log the full response with then().log().all() to see the actual body. Common causes are a wrong JSON path, such as missing a wrapper like data, the field being in an array needing an index, a different content type like XML or HTML error page, or the field name having different case. Fix the path, and add a schema check so structure changes are caught clearly.

Centralise token handling in an auth helper that caches the token with its expiry time and refreshes it shortly before it expires, or in a filter that catches a 401, refreshes once and retries. Do not log in before every test, as that slows the suite and may hit rate limits. Make the helper thread-safe for parallel runs.

Add JSON schema validation for key responses so type changes fail immediately, and deserialize into typed POJOs, which fail when types do not match. For services with multiple consumers, introduce contract tests so providers learn about breaks before deploying. Also ask for API changes to be shared in pull requests or a changelog that QA reviews.

Look for shared state between methods: instance or static fields changed by earlier tests, data created or deleted by another test, cookies or logged-in session kept in the same browser, and priority or order assumptions. Run the class in a different order to confirm. Fix by resetting state in @BeforeMethod, creating unique data per test and avoiding static fields.

Retries are hiding real intermittent defects, such as race conditions, by treating them as flaky tests. Limit retries to one, report retried tests separately as flaky in the dashboard, and require a ticket for each one. Review retried tests weekly to find whether the cause is the test or the product. Retries should buy time to fix, not replace fixing.

The WebDriver is shared, probably through a static field. Replace it with a ThreadLocal<WebDriver> in a DriverManager, create the driver in @BeforeMethod and call quit() and remove() in @AfterMethod(alwaysRun = true). Make page objects take the driver from the current thread. Also check test data, reports and loggers are thread-safe.

Add a health check stage that pings dependencies before tests and marks the run as environment failure rather than test failure. For tests that do not need the real service, use stubs. Escalate with data on downtime frequency to the team owning the service. Keep a separate scheduled job for the real integration tests so pull requests are not blocked.

The driver was never initialised or was passed as null, for example a page created before setup ran or a static driver not yet assigned. With PageFactory, initElements may not have been called, so @FindBy fields are null. A config value read from a properties file may also be missing. Check the stack trace line, then fix the setup order and add null checks with clear messages.

The file path is probably hard-coded or relative to the IDE working directory, or uses Windows backslashes while Jenkins runs on Linux. Load the file from the classpath with getClass().getClassLoader().getResourceAsStream("config.properties") and keep it in src/test/resources, or build paths with Paths.get. Also check the file is committed to Git and not ignored.

It occurs when a collection is modified while being iterated with a for-each loop, for example removing items from an ArrayList inside the loop. Fix by using Iterator.remove(), removeIf(), collecting items to remove separately, or using CopyOnWriteArrayList or ConcurrentHashMap when threads share the collection. In parallel tests, shared lists are a common source.

Check whether drivers are always quit, ThreadLocal values are removed, and static lists or maps keep growing, such as collecting screenshots or response objects. Enable heap dumps with -XX:+HeapDumpOnOutOfMemoryError and analyse with a tool like VisualVM or Eclipse MAT to see which objects hold memory. Fix the leak and tune Surefire's forked JVM memory with argLine if needed.

== compares object references, not content. String literals are interned, so two literals with the same text may share a reference and == returns true, but strings read from the UI or built at runtime are new objects, so == returns false even with the same text. Use equals() or equalsIgnoreCase() for content, and Objects.equals() to be null-safe.

It probably uses a shared static SimpleDateFormat, which is not thread-safe, so parallel threads corrupt each other's parsing. Replace it with java.time DateTimeFormatter, which is immutable and thread-safe, and LocalDate or LocalDateTime for values. Generally, avoid shared mutable static objects in test utilities that run in parallel.

double uses binary floating point, which cannot represent many decimal values exactly, so small rounding errors appear. For money, use BigDecimal created from strings and compare with compareTo(), or compare doubles with a tolerance such as Assert.assertEquals(actual, expected, 0.001). Also strip currency symbols and commas before parsing UI text.

Use a factory: a BrowserType enum and a DriverFactory.create(BrowserType) that returns the right WebDriver with its options, using a switch. Read the browser from a system property with a default. For remote runs, return RemoteWebDriver with the same options. Tests depend only on the WebDriver interface, so adding a new browser changes one class, following the open-closed principle.

Swallowing exceptions hides failures, so TestNG never sees an error and marks the test passed. Catch only specific exceptions you can handle, add context and rethrow, or let them propagate. If you need logging, log and then throw. Code reviews should flag empty catch blocks and broad catch (Exception e) in test code.

Do not load everything as one giant DataProvider; that creates thousands of UI tests. First question whether all rows need UI runs; most can be validated at API level. Read the file with BufferedReader or Files.lines() as a stream, filter to the rows you need, and use a lazy Iterator<Object[]> DataProvider so rows load as tests run, keeping memory low.

Create a ConfigReader that loads properties once, using a singleton or a static holder initialised lazily in a thread-safe way, and exposes typed getters like getInt("timeout"). Let system properties and environment variables override file values so CI can change them. Keep it read-only after loading so parallel threads cannot change settings mid-run.

Extract repeated steps into private helper methods or a page object, move common setup into @BeforeMethod, and use a DataProvider when only data differs. If the repeated code differs only in a small action, pass that action as a lambda, such as a Consumer<WebDriver>. Rerun the tests after each small refactor to confirm behaviour is unchanged.

Another element, such as a cookie banner, loader overlay or sticky header, covers the target. In CI the window is often smaller, so the layout differs. Set a fixed window size, wait for the overlay to disappear with invisibilityOfElementLocated, close banners in setup and scroll the element into view. Use a JavaScript click only as a last resort, since it bypasses real user behaviour.

Check whether the element is inside an iframe or shadow DOM, the locator matches a different hidden element first, the page opened in a new tab not yet switched to, or the wait condition is wrong, such as presence versus visibility versus clickable. Use findElements to see how many matches the locator has and verify it in browser DevTools.

The file is saved on the remote node, not the machine running the test, so the test cannot find it locally. Options are enabling Selenium Grid's managed downloads with se:downloadsEnabled and fetching the file through the Grid API, sharing a mounted volume with the container, or verifying the download by requesting the file URL with an HTTP client and checking status, size and type.

Rerun on Firefox with screenshots and logs. Common causes are timing differences, different default window sizes, unsupported CSS or JavaScript behaviour, alerts handled differently, or a driver version mismatch. Compare the DOM in both browsers at that step. Fix by using explicit waits, setting window size, and reporting genuine browser bugs to developers.

Measure flakiness per test over many runs and fix the worst first. Typical fixes are replacing sleeps with explicit waits, creating independent test data via API, avoiding shared logins, using stable locators, isolating parallel drivers and stubbing unstable third parties. Quarantine known flaky tests into a separate job so they do not block releases, and set a target like under 2 percent.

Log in once through the API, capture the session cookie or token, and inject it into the browser with driver.manage().addCookie() after opening the domain, or set local storage with JavaScript. Then navigate directly to the page under test. Keep one real UI login test to cover the login page itself. This often saves several seconds per test.

Type the text with sendKeys, wait for the suggestion list with visibilityOfAllElementsLocatedBy, then find the option whose text matches the required value and click it. Avoid selecting by index because suggestion order may change. If the list is virtualised, type more characters to narrow results. Verify the selected value in the input afterwards.

The screenshot may be taken before the page renders, the window size in headless mode may be tiny, or the browser is crashing due to low shared memory in Docker. Set --window-size=1920,1080, use the new headless mode, wait for page content before capturing, and add --disable-dev-shm-usage or a larger shm size for containers.

Use Selenium Manager, built into Selenium 4.6 and later, which resolves the right driver automatically, so you do not commit driver binaries. In CI, pin browser versions using Docker images or browser options so all agents match. Avoid auto-updating browsers on test agents. Log the browser and driver versions at the start of each run to diagnose quickly.

Do not try to read SMS from a real phone. Ask developers for a test-only approach: a fixed OTP for test users, a bypass flag in non-production, or an API to fetch the latest OTP. For authenticator apps, store the test account's TOTP secret and generate codes in Java with a TOTP library. Keep production 2FA untouched and secrets in the CI credential store.

Use both, for different purposes. Emulators and simulators are cheap, fast to reset and easy to run in CI, so they suit smoke and regression runs on every commit. Real devices reveal issues emulators hide: performance on low-end hardware, camera, biometrics, push notifications, network changes and vendor-specific Android skins. A common plan is emulators in the pull request pipeline and a nightly run on a small matrix of real devices covering the most-used models.

First check timing: the screen may still be loading, so add an explicit wait for presence. Then check context: in a hybrid app the element may be in a webview while you are in NATIVE_APP. Confirm the locator matches exactly, including package prefix in resource-id. The element may be off screen in a list, so scroll first. Also check that the Inspector session used the same app build, language and device size as the test.

Low-end devices are slower, so fixed waits and short timeouts expire before screens render. Replace sleeps with explicit waits and increase timeouts sensibly. Check for vendor-specific pop-ups, battery optimisation dialogs or different keyboards on that brand. Compare screen size and resolution, since coordinate-based taps break. Collect device logs with adb logcat and screen recordings to see what the app was doing. Also check whether the app crashed due to low memory.

The cleanest fix is the capability appium:autoGrantPermissions set to true, which grants all permissions the app declares at install time. If you need to test the permission flow itself, handle the dialog explicitly by waiting for the Allow button using its resource-id and clicking it. Another option is granting a specific permission with adb shell pm grant before the test. Avoid blind try-catch around taps, because it hides real failures.

Call driver.hideKeyboard() after typing, or check driver.isKeyboardShown() first so the call does not fail when no keyboard is open. On Android you can also set appium:hideKeyboard or use a capability for the unicode keyboard so the soft keyboard does not appear. Alternatively press the keyboard's Done or Enter key, or scroll the button into view. Pick one approach and put it in a helper so all tests behave the same.

Run devices in parallel with one thread per device, each with its own udid, systemPort or wdaLocalPort. Use deep links or API calls to reach the screen under test instead of navigating through the UI every time. Prefer noReset with explicit data cleanup over reinstalling the app. Replace XPath with accessibility ids. Split the suite so pull requests run a small smoke set on emulators while the full device matrix runs nightly.

Wait for a stable end state instead of sleeping, for example wait until the target element is visible and enabled or until a spinner disappears. On test devices and emulators you can disable animations with adb shell settings put global window_animation_scale 0, along with the transition and animator scales. Ask developers for an idle indicator if needed. Disabling animations makes tests faster and more stable, but keep one manual check of the real animations.

The webview is probably not debuggable. Android only exposes a webview to automation when the app calls WebView.setWebContentsDebuggingEnabled(true), which developers usually enable only in debug builds, so ask for a debug or test build. Also wait until the webview screen is actually loaded before reading contexts. If the app uses Chrome custom tabs, that is a separate Chrome process, not a webview. Finally check that a compatible Chromedriver is available to Appium.

A cloud farm gives hundreds of device and OS combinations, parallel capacity and no hardware maintenance, but costs per minute, adds network latency and may raise data privacy concerns. An in-house lab is cheaper over time for a small fixed set of devices and gives full control, but needs USB hubs, OS updates, battery care and someone to maintain it. Many teams keep a few local devices for debugging and use the cloud for wide coverage.

The text may contain extra whitespace, a line break or a non-breaking space that looks normal visually. getText() also returns only visible text and applies CSS text-transform, so uppercase styling changes the value. Print the string with its length or character codes to spot hidden characters. Fix it by trimming and normalising whitespace before comparing, or compare with the expected case-insensitively when the UI uses text-transform.

It means no matching free slot appeared in time. Check the Grid UI to see whether nodes are registered and whether their capabilities match the request, such as browser name, version or platform. Compare the test thread count with total slots, since extra threads just wait in the queue. Look for stuck sessions holding slots after aborted builds. Then increase capacity, reduce threads, or raise the session request timeout.

This is almost always shared memory exhaustion, because Docker's default /dev/shm of 64 MB is too small for Chrome. Set shm_size: 2gb in Compose or --shm-size=2g in docker run. Also check the container's memory limit and the number of sessions per node, since several browsers in one container multiply memory use. Heavy pages or memory leaks in long sessions can also crash tabs, so restart sessions between test classes.

sendKeys with a file path sends a path that exists on your test machine, but the browser runs on the remote node where that path does not exist. Set a LocalFileDetector on the RemoteWebDriver, using ((RemoteWebDriver) driver).setFileDetector(new LocalFileDetector()), so Selenium zips and transfers the file to the node first. Alternatively mount the test data folder into the node container. Always use absolute paths.

When a build is killed, driver.quit() never runs, so sessions stay open until the node notices. Set a sensible session timeout on nodes, such as SE_NODE_SESSION_TIMEOUT of 300 seconds, so idle sessions are cleaned up. Always call quit in an @AfterMethod with alwaysRun or a finally block. In CI, bring the Compose Grid up per build and tear it down in a post always step, so each build gets a fresh Grid.

Inside a container, localhost means the container itself, not the host machine. On Docker Desktop use host.docker.internal as the host name. On Linux add extra_hosts with host.docker.internal:host-gateway, or use the host's IP. A cleaner option is running the application in the same Compose network and calling it by its service name, such as http://web:8080. Make sure the app listens on 0.0.0.0, not only 127.0.0.1.

The Grid only has 8 free slots, so the other requests wait in the New Session Queue. Total parallelism equals nodes multiplied by max sessions per node, not the TestNG thread count. Check the Grid UI for slot count. To run more, scale the node containers, raise max sessions if hardware allows, or use a larger grid. Otherwise reduce threads to match slots so waiting requests do not time out.

Every command now travels over the network, so chatty code with many findElement calls or getText in loops suffers most. Check latency between test runner and Grid, ideally keeping them in the same network or region. Check node resources: overloaded CPU or many sessions per container slow browsers. Video recording and VNC add overhead. Reduce round trips by batching checks, using JavaScript for bulk reads and avoiding implicit waits combined with explicit ones.

First shrink the UI suite by moving checks to API and unit level. Then run the rest on an autoscaling Grid, for example Kubernetes with KEDA, sized so tests divided by slots times average duration fits the budget. Make tests independent with API-based setup and ThreadLocal drivers. Shard tests across CI agents, fail fast on smoke tests first, and track flaky tests separately. Pin image versions and monitor queue time.

Use path filters so commits that touch only docs or markdown skip the test stages. For code changes, map modules to their test suites and run only the affected ones on pull requests, with the full regression on merge to main or nightly. Cache Maven dependencies and Docker layers. Keep a fast smoke stage first so failures appear early. Track pipeline time as a metric so the optimisation does not quietly regress.

Tag them, for example with @wip, and exclude the tag in the CI runner using a tag expression like not @wip, set through the cucumber.filter.tags property or the runner options. Developers can still run them locally by including the tag. Review @wip scenarios regularly so they do not stay parked forever, and never use the tag to hide failing tests that should be fixed or reported as bugs.

Check CPU and memory usage of application servers, garbage collection pauses and heap usage for Java services, thread pool and connection pool saturation, database slow queries, locks and connection counts, disk I/O and network bandwidth. Also look at load balancer and cache hit rates and error logs. Correlate the timestamp of the slowdown with these graphs in an APM or monitoring tool to find which resource saturated first.

Look at which requests fail and their error codes: 503 or 504 suggest overloaded servers or gateways, connection refused points to exhausted connection pools or ports. Find the user count where errors start by running a stepped ramp-up. Correlate with server metrics such as CPU, thread pools, database connections and GC. Confirm the load generator itself was not overloaded. Report the saturation point and the bottleneck with evidence, not just the error percentage.

First remove or disable GUI listeners like View Results Tree and run in non-GUI mode. Save results in CSV format with only needed fields instead of XML with response data. Increase heap through the HEAP environment variable, such as -Xms2g -Xmx4g, within the machine's RAM. Use Groovy instead of BeanShell, avoid huge regex extractions, and if one machine still cannot generate the load, distribute it across several workers.

The test may not have matched reality. Common gaps are unrealistic think time or user journeys, repeated test data giving high cache hits, a smaller database than production, missing third-party calls that were stubbed, a test environment with different hardware or configuration, and load generated from one region. Review production logs and analytics to rebuild the workload model, use production-like data volumes and repeat the test.

The script is probably replaying hard-coded dynamic values, such as a CSRF token, session cookie or auth header captured during recording. The server rejects them because they belong to the old session. Add an HTTP Cookie Manager so cookies are handled per thread, extract the CSRF or bearer token from the login response with an extractor, and replace the recorded value with the variable. Verify with View Results Tree on one thread.

First clarify what 10,000 users means: concurrent sessions, users per hour or requests per second, and which journeys they perform. Use production analytics to build the workload mix and think times, then agree on SLAs like 95th percentile under two seconds and errors under one percent. Prepare a production-like environment and data, plan baseline, load, stress and soak runs, set up monitoring, and share a report with clear limits and bottlenecks.

A steady rise under constant load usually indicates a resource leak, such as memory not being freed, growing caches, unclosed database connections or threads, or log and temp files filling disk. Check heap usage and garbage collection trends, connection pool counts and open file handles over time. A heap dump comparison can show which objects grow. Share the evidence with developers, since such issues rarely appear in short tests.

Do not assert on positions when the API does not guarantee order. Use order-independent Hamcrest matchers such as hasItem, hasItems or containsInAnyOrder on the extracted field, for example body("name", hasItems("Pen", "Book")). Or use GPath filtering like find { it.id == 42 } to pick the right item before checking its fields. If order matters for the feature, raise it as a requirement and request a sort parameter.

Make the outcome explicit with separate methods instead of one method guessing. For example loginAs(user) returns DashboardPage for valid credentials, while loginExpectingError(user) returns the same LoginPage so the test can check the error. Each method waits for its expected page and fails clearly if it does not appear. This keeps tests readable and avoids returning a generic Object or checking types in tests.

The most stable fix is preventing it: set the consent cookie before the test with driver.manage().addCookie after opening the domain, or ask developers for a test flag that disables the banner. If it must be handled in the UI, write one helper that checks for the banner with a short wait using findElements and closes it if present. Call it from the BasePage after navigation, not scattered in tests.