Test Automation Design and Quality Questions

Covers principles and practices for writing maintainable, readable, and scalable automated tests and their supporting code. Key areas include separation of concerns and test architecture; applying design patterns such as the Page Object Model to isolate application knowledge from test logic; following the do not repeat yourself principle through reusable helpers and utilities; organizing tests into logical suites and layers for clarity and execution control; managing test data and test isolation to ensure independence and repeatability; meaningful test and method naming conventions; comprehensive assertions and structured logging for diagnosability; strategies to reduce flakiness such as reliable synchronization and idempotent tests; designing tests and frameworks for parallel execution and continuous integration pipelines; code quality practices including refactoring, code reviews, consistent style and structure, and documentation to support long term maintainability and scalability.

MediumTechnical

32 practiced

Design and implement (pseudocode or Java) a Page Object Model where a reusable ProductCard component appears on many pages. Show how ProductCard is implemented as a component class with its own locators and actions, and how pages compose ProductCard to avoid duplication. Include sample methods (e.g., getPrice(), clickAddToCart()) and explain lifecycle and object ownership.

Sample Answer

**Approach — why component POM:** Reuse a ProductCard component class with its own locators and actions; pages compose it (has-a) rather than inherit to avoid duplication and keep tests resilient.

**ProductCard component (Java + Selenium)**

java

// ProductCard.java
public class ProductCard {
  private final WebDriver driver;
  private final WebElement root; // root element for this card

  // locators relative to root
  private final By title = By.cssSelector(".product-title");
  private final By price = By.cssSelector(".product-price");
  private final By addToCart = By.cssSelector(".btn-add");

  public ProductCard(WebDriver driver, WebElement root) {
    this.driver = driver;
    this.root = root;
  }

  public String getTitle() {
    return root.findElement(title).getText();
  }

  public BigDecimal getPrice() {
    String p = root.findElement(price).getText().replaceAll("[^0-9.]", "");
    return new BigDecimal(p);
  }

  public void clickAddToCart() {
    root.findElement(addToCart).click();
  }

  public void waitUntilVisible(Duration timeout) {
    new WebDriverWait(driver, timeout).until(d -> root.isDisplayed());
  }
}

**Page composition example**

java

// CategoryPage.java
public class CategoryPage {
  private final WebDriver driver;
  private final By productCardRoots = By.cssSelector(".product-card");

  public CategoryPage(WebDriver driver){ this.driver = driver; }

  public List<ProductCard> getProductCards(){
    return driver.findElements(productCardRoots)
                 .stream()
                 .map(el -> new ProductCard(driver, el))
                 .collect(Collectors.toList());
  }

  public Optional<ProductCard> findByTitle(String name){
    return getProductCards().stream()
      .filter(pc -> pc.getTitle().equalsIgnoreCase(name)).findFirst();
  }
}

**Lifecycle & ownership**- Test instantiates Page (owner of WebDriver); Page locates card root elements and constructs ProductCard instances (cards do not fetch elements globally). - ProductCard holds a reference to its root WebElement and driver but does not manage navigation. Pages manage page-level flows (navigation, waits). - This keeps responsibility clear: Page = page-level operations and composition, Component = encapsulated actions/locators.

**Benefits / best practices**- Single source for locators reduces duplication; easier maintenance- Use relative locators to avoid stale references; recreate ProductCard from fresh root when page updates- Keep component methods small, deterministic, and return primitives or other components for chaining when needed.

EasyTechnical

31 practiced

Describe a robust locator strategy for UI tests to minimize breakage during UI changes. Include recommendations on which attributes to rely on (ids, data-* attributes), how to avoid brittle xpaths, and techniques for handling dynamic content and third-party widgets.

MediumTechnical

53 practiced

Write a Python decorator named "retry_on_exception" that retries a flaky function up to N times with exponential backoff and optional jitter. The decorator signature should accept parameters: retries, initial_delay_seconds, max_delay_seconds, backoff_factor, jitter (bool), and exception_types. Provide correct behavior, logging on each retry, and re-raise the last exception if retries are exhausted. Mention idempotency considerations.

Sample Answer

**Approach**Use a parameterized decorator that wraps the function, catches specified exceptions, sleeps with exponential backoff plus optional jitter, logs each retry, and re-raises the last exception when exhausted. Note idempotency: retries can cause repeated side effects; ensure the wrapped operation is idempotent or use compensating actions.

**Implementation**

python

import time, random, functools, logging
logger = logging.getLogger(__name__)

def retry_on_exception(retries=3, initial_delay_seconds=0.5, max_delay_seconds=30.0,
                       backoff_factor=2.0, jitter=False, exception_types=(Exception,)):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            attempt = 0
            delay = initial_delay_seconds
            last_exc = None
            while attempt <= retries:
                try:
                    return func(*args, **kwargs)
                except exception_types as e:
                    last_exc = e
                    if attempt == retries:
                        logger.error("Exhausted retries (%d) for %s; re-raising.", retries, func.__name__)
                        raise
                    sleep = delay
                    if jitter:
                        sleep = random.uniform(0, delay)
                    logger.warning("Attempt %d failed for %s: %s. Retrying in %.2fs",
                                   attempt+1, func.__name__, e, sleep)
                    time.sleep(min(sleep, max_delay_seconds))
                    delay = min(delay * backoff_factor, max_delay_seconds)
                    attempt += 1
            raise last_exc
        return wrapper
    return decorator

**Notes / Best practices**- For SDET: prefer idempotent test operations (e.g., read-only checks or repeated setup/teardown) or record attempts to avoid duplicate side effects.- Use deterministic jitter (seeded) in tests to avoid flakiness.- Add metrics and increased logging in CI to track flaky patterns.

HardTechnical

44 practiced

Implement a robust 'waitForStableState' helper in TypeScript that works with Puppeteer or Playwright. It should resolve when: (1) no DOM mutations observed for X milliseconds, (2) no outstanding network requests for Y milliseconds, or (3) a global timeout is reached. Provide working code (or clear pseudocode) and explain how you handle edge cases like long-polling, background service-workers, or intermittent frames.

Sample Answer

**Approach (brief)**

Wait for page "stability" by observing DOM mutations (MutationObserver) and network activity (intercepting/fetching requests). Resolve when both have been quiet for configured quiescence windows or when a global timeout fires. Ignore background service-worker and long-polling by whitelist/heuristics (e.g., stable connections allowed, or require inactivity > longer window).

typescript

// TypeScript (works with Playwright or Puppeteer Page-like API)
type Options = {
  domQuietMs?: number;      // e.g. 500
  networkQuietMs?: number;  // e.g. 500
  timeoutMs?: number;       // e.g. 10000
  ignoreUrlPatterns?: RegExp[]; // long-poll/service-worker URLs
};

export async function waitForStableState(page: any, opts: Options = {}) {
  const { domQuietMs = 500, networkQuietMs = 500, timeoutMs = 10000, ignoreUrlPatterns = [] } = opts;
  return new Promise<void>(async (resolve, reject) => {
    const start = Date.now();
    let domTimer: NodeJS.Timeout | null = null;
    let netTimer: NodeJS.Timeout | null = null;
    let outstanding = new Set<string>();
    let finished = false;

    function cleanup() {
      finished = true;
      if (domTimer) clearTimeout(domTimer);
      if (netTimer) clearTimeout(netTimer);
      try { page.off && page.off('request', onRequest); page.off && page.off('requestfinished', onRequestFinished); page.off && page.off('requestfailed', onRequestFinished); } catch {}
      // remove injected observer
      page.evaluate(() => { (window as any).__stopMutationObserver && (window as any).__stopMutationObserver(); }).catch(()=>{});
    }

    function checkDone() {
      if (finished) return;
      if (outstanding.size === 0 && !domTimer && !netTimer) {
        cleanup();
        resolve();
      }
    }

    // network tracking
    function isIgnored(url: string) {
      return ignoreUrlPatterns.some(r => r.test(url));
    }
    function onRequest(req: any) {
      if (isIgnored(req.url())) return;
      outstanding.add(req._requestId || req.url() + Math.random());
      if (netTimer) { clearTimeout(netTimer); netTimer = null; }
    }
    function onRequestFinished(req: any) {
      if (isIgnored(req.url())) return;
      // remove one matching id if present
      for (const id of outstanding) { if (id.includes(req.url().slice(0,50))) { outstanding.delete(id); break; } }
      if (outstanding.size === 0) {
        netTimer = setTimeout(() => { netTimer = null; checkDone(); }, networkQuietMs);
      }
    }
    page.on && page.on('request', onRequest);
    page.on && page.on('requestfinished', onRequestFinished);
    page.on && page.on('requestfailed', onRequestFinished);

    // DOM MutationObserver injected into page
    await page.evaluate(({ domQuietMs }) => {
      const win = window as any;
      if (win.__stopMutationObserver) win.__stopMutationObserver();
      let timer: any = null;
      const notify = () => {
        (window as any).__notifyMutation && (window as any).__notifyMutation();
      };
      const obs = new MutationObserver(() => {
        if (timer) clearTimeout(timer);
        timer = setTimeout(notify, domQuietMs);
      });
      obs.observe(document, { childList: true, subtree: true, attributes: true, characterData: true });
      win.__stopMutationObserver = () => { obs.disconnect(); if (timer) clearTimeout(timer); delete win.__stopMutationObserver; };
    }, { domQuietMs });

    // bridge: page.exposeFunction called once to receive notifications
    await page.exposeFunction && page.exposeFunction('__notifyMutation', () => {
      if (domTimer) clearTimeout(domTimer);
      domTimer = setTimeout(() => { domTimer = null; checkDone(); }, domQuietMs);
    });

    // initialize timers: if no outstanding and no initial DOM changes, set timers
    netTimer = setTimeout(() => { netTimer = null; checkDone(); }, networkQuietMs);
    domTimer = setTimeout(() => { domTimer = null; checkDone(); }, domQuietMs);

    // global timeout
    const global = setTimeout(() => {
      if (finished) return;
      cleanup();
      reject(new Error(`waitForStableState timeout after ${timeoutMs}ms (elapsed ${Date.now()-start}ms)`));
    }, timeoutMs);
  });
}

**Edge cases & handling**- Long-polling / SSE: use ignoreUrlPatterns to exclude known endpoints; otherwise require longer networkQuietMs.- Service workers/background fetches: ignore requests to service-worker scope or patterns; do not count navigator.serviceWorker messages.- Iframes: MutationObserver on top document won't see cross-origin iframe internals; for same-origin iframes, inject separate observers.- Flaky tests: use conservative defaults (500ms–1s) and allow callers to tune per test.

**Complexity & notes**- Lightweight; cost equals event listeners + small injected script.- Ensure page.exposeFunction available (Playwright/Puppeteer); adapt to evaluateOnNewDocument for persistent behavior in SPA navigations.

MediumTechnical

31 practiced

Provide a practical checklist and process for reviewing and refactoring test automation code. Include guardrails (determinstic, fast, minimal external dependencies), test-specific code smells (sleep, duplicated locators, long tests), and steps to measure improvement post-refactor (runtime, flakiness rate, code complexity).

Unlock Full Question Bank

Get access to hundreds of Test Automation Design and Quality interview questions and detailed answers.

Join thousands of developers preparing for their dream job.