Frequent UI Changes — Will You Automate?

The Situation

In one project, the UI design was changing frequently, so you had to decide whether automation would even be effective.

The Approach

Result

Automation maintenance was reduced and overall testing efficiency improved.

Spoken Interview Answer

"If the UI keeps changing, I don't rush into UI automation. I first focus on testing stable functionality and wait for the UI to settle. Once it becomes stable, I automate critical flows so automation remains useful and low maintenance."

Follow-Up Questions

Does This Mean You Won't Automate at All?

No.

Delay UI automation and automate:

  • Stable functionality.
  • APIs.
  • Backend logic.

How Do You Decide Which Parts Are Stable Enough?

Automate areas:

  • That are not undergoing frequent UI changes.
  • Where business behavior has stabilized.

What Type of Automation Do You Prefer?

Prefer:

These are less affected by UI changes and provide faster feedback.

What If Management Insists on UI Automation?

Explain the maintenance risk and recommend a Hybrid Approach.

Key Principle

Don't automate an unstable UI. Stabilize first, then automate critical business flows.

Advertisement

Automation vs Manual: What to Automate

The Situation

There are hundreds of test cases but limited time available for automation.

You must choose where automation provides the maximum return.

The Approach

Automate:

  • Repetitive test cases.
  • Stable functionality.
  • Regression scenarios.

Keep Manual:

Result

Automation coverage increased with minimal maintenance while Manual Testing continued to validate rapidly changing functionality.

Real Example

Automated:

  • Login
  • Payment
  • API Validations

using Selenium + TestNG.

Kept Manual:

  • Exploratory UI Testing

Spoken Interview Answer

"When deciding to automate a test case, I first check if it's repetitive, stable, or part of regression—those I automate. Anything exploratory, dynamic, or likely to change frequently I keep manual, so automation stays valuable and low-maintenance."

Decision Criteria

Automate

  • Repetitive
  • Stable
  • Regression

↓

Manual

  • Exploratory
  • Dynamic
  • Frequently changing

Flaky Tests: Diagnosing and Fixing Intermittent Failures

The Situation

Automation tests were failing randomly in the CI pipeline.

The objective was to stabilize the automation suite.

The Approach

  • Analyze reports.
  • Identify flaky tests.
  • Fix synchronization issues.
  • Remove test data dependency.
  • Validate environment stability.

Result

False failures were reduced significantly, making the CI pipeline more reliable.

Real Example

Flaky Selenium tests caused by improper waits were fixed using:

  • Explicit Waits
  • Stable Locators

This significantly reduced intermittent failures.

Spoken Interview Answer

"If my tests fail sometimes and pass sometimes, I treat them as flaky. I check waits, synchronization, test data dependency, and environment issues, and fix the root cause so the suite becomes stable and reliable."

Follow-Up Questions

What Are Flaky Tests?

Automation tests that fail randomly without any code change.

Common causes include:

  • Synchronization issues.
  • Test data dependency.
  • Environment instability.

What Is the Most Common Cause?

Synchronization issues.

Examples:

  • Improper waits.
  • Dynamic web elements.

How Do You Identify Flaky Tests Quickly?

  • Re-run failed tests multiple times.
  • Analyze CI reports.
  • Review logs.
  • Review screenshots.

Do You Ignore Flaky Tests in CI?

No.

Fix the root cause.

Use:

  • Explicit Waits
  • Proper wait conditions

Avoid using:

  • Thread.sleep()

How Does Test Data Cause Intermittent Failures?

Shared or hard-coded test data can be modified by parallel executions, causing random failures.

How Do You Handle Flakiness in Parallel Execution?

  • Ensure test data independence.
  • Avoid shared state.
  • Make each test self-contained.

What Role Does the Environment Play?

Intermittent failures can result from:

  • Unstable environments.
  • Slow network.
  • Frequent deployments.

How Do You Communicate Flaky Test Issues?

Classify every flaky test as:

  • Test-related
  • Data-related
  • Environment-related

Share the findings with the team.

Flaky Test Causes and Fixes — With Code

SymptomLikely causeFix
NoSuchElementException or ElementNotInteractableException sometimesThe element loads after the actionExplicit wait for the right condition
StaleElementReferenceExceptionThe page re-rendered after you found the elementFind it again after the change; store By locators, not WebElements
ElementClickInterceptedExceptionA spinner, overlay or banner covers the elementWait for the overlay to disappear
Passes alone, fails in parallelShared test data or a shared driverUnique data per test; ThreadLocal driver
Passes locally, fails in CIHeadless window size, slower machines, missing dataFixed window size, waits based on conditions, data created by the test
Fails at the same time every nightDeployments, backups or batch jobs in the environmentCoordinate schedules; report as environment-related

Look up any Selenium exception's usual causes and fixes in the Selenium Exception Lookup.

Replace fixed sleeps with conditions

// ❌ Flaky: sometimes too short, always slow
Thread.sleep(3000);
driver.findElement(By.id("place-order")).click();

// ✅ Waits only as long as needed, for the thing that actually matters
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.invisibilityOfElementLocated(By.cssSelector(".spinner")));
wait.until(ExpectedConditions.elementToBeClickable(By.id("place-order"))).click();

Reproduce before you fix

  • Run the suspect test 20–50 times in a loop (TestNG invocationCount, or a CI job) and in parallel — a fix you can't reproduce is a guess.
  • Compare screenshots, logs and timings of passing and failing runs.
  • Check the CI history: does it fail on one browser, one agent, or at one time of day?

Retries: a safety net, not a fix

A TestNG IRetryAnalyzer or Maven Surefire's rerun option can stop a known infrastructure glitch from failing the whole pipeline — but every retried test should be logged and reported as flaky, and fixed. A test that "passes on retry" can also be hiding an intermittent bug that real users will hit. If a test can't be fixed quickly, quarantine it (move it to a separate group that doesn't block the build) with a ticket, rather than deleting it or letting it make every build red.

More: Selenium Waits and Passes Locally, Fails in Jenkins.

From Real Projects

Before any automation, my work on each project started with the requirement: understanding the business flow, identifying scenarios, writing test cases and getting them reviewed. On Canolog, where sales, inventory, finance, service and parts all connect, that analysis is what found the gaps between modules. Execution was tracked in TestRail and defects in Jira. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. A flaky test should be fixed or removed quickly — a suite nobody trusts isn't doing its job.

📖 Related tutorials

📚 Official documentation: ISTQB Glossary of testing terms

FAQs

Should You Automate a Frequently Changing UI?

No.

Delay UI automation until the interface stabilizes.

Automate APIs or stable functionality first.

What Automation Is Best When the UI Is Unstable?

They are less affected by UI changes and provide faster feedback.

How Do You Decide Between Automation and Manual Testing?

Automate:

Keep Manual:

What Are Flaky Tests?

Automation tests that fail randomly without any application code change.

Typical causes include:

  • Synchronization
  • Test Data
  • Environment

What's the Most Common Cause of Flaky Tests?

Synchronization issues.

Fix them using:

  • Explicit Waits
  • Stable Locators

Avoid Thread.sleep() whenever possible.

How Do You Keep Tests Stable During Parallel Execution?

  • Use independent test data.
  • Avoid shared state.
  • Design self-contained tests.