Question 1

Design test cases for a discount field that accepts 1-100 percent with role-based caps.

Accepted Answer

Start with the field's own boundaries independent of role: valid values are 1 and 100 (edges), just-inside values like 2 and 99, and just-outside invalid values like 0, 101, and negative numbers. Add equivalence classes for bad input types too — empty string, non-numeric text, decimals if the field is meant to be a whole percent, and injection-style strings like "100; DROP TABLE" to check input sanitization.

Then layer role-based caps on top as a second dimension, because the 1-100 range is really "1 to the role's cap," not a flat range for everyone. If a sales rep is capped at 20%, a manager at 50%, and an admin at 100%, each role needs its own boundary tests: for the rep, 19/20/21; for the manager, 49/50/51; for the admin, 99/100/101. Testing only the global 1-100 range would miss a rep who submits 21% and should be rejected even though 21 is 'valid' for the field type.

Finally, cross-check for privilege escalation: what happens if a rep's request is replayed with a tampered payload claiming manager-level access, or if the cap is enforced only in the UI and not re-validated server-side? A realistic test here is sending a raw API call with discount=45 as a rep account and asserting the server rejects it with 403/422, not just checking the UI blocks the slider — client-side caps are trivially bypassed with curl or DevTools.

Question 2

Model an order lifecycle (cart to delivered to returned) as states and derive the minimal test set covering all transitions.

Accepted Answer

Model the order as a finite state machine first: Cart -> Placed -> Confirmed -> Shipped -> Delivered -> Returned, with Cancelled reachable from Cart, Placed, or Confirmed. Draw this as a simple transition table (from-state, event, to-state) before writing any test — it exposes ambiguous cases immediately, like whether Cancelled is even legal after Shipped.

The minimal test set for full transition coverage is one test per edge in that graph, not one test per state and not the combinatorial product of all state pairs — that's the difference between 'transition coverage' and 'switch coverage.' For the graph above, that's roughly 7 valid-transition tests (Cart→Placed, Placed→Confirmed, Confirmed→Shipped, Shipped→Delivered, Delivered→Returned, plus the three Cancelled paths), each just asserting the order lands in the expected state and only the expected side effects fire (inventory released on cancel, refund triggered on return).

Just as important is a smaller set of invalid-transition tests: attempting Shipped→Cart, or Delivered→Cancelled, should be rejected by the state machine, not silently accepted. A concrete regression this catches: a bug where hitting the 'cancel' API on an already-Shipped order still fired a refund and released inventory, because the endpoint checked 'is this order != Delivered' instead of an explicit allow-list of valid from-states — a transition table with negative cases baked in would have caught that in one line.

Question 3

A login test passes locally but fails in CI intermittently — walk through likely causes and a stable waiting strategy.

Accepted Answer

The classic causes of 'passes locally, flaky in CI' for a login test are timing-related almost every time. Locally your machine is fast and lightly loaded, so a fixed delay or an assumption like 'the redirect finishes by the time I read the URL' happens to hold; in CI, containers are slower and share CPU with other jobs, so the same assumption breaks intermittently. Other common culprits: a Thread.sleep/fixed wait that's too short for CI, test order dependence (a previous test left a session cookie or a modal open), and the backend session/auth cookie not being fully propagated before the next request fires.

The fix is to replace every fixed sleep with a condition-based wait tied to an actual signal of readiness — a specific element appearing, a URL change, or a network response completing — instead of guessing a duration:

```javascript
// bad: guesses a duration
await page.click('#login-btn');
await page.waitForTimeout(2000);
expect(await page.url()).toContain('/dashboard');

// good: waits for the actual signal
await page.click('#login-btn');
await page.waitForURL('**/dashboard');
await expect(page.locator('[data-testid="user-menu"]')).toBeVisible();
```

For Selenium, that's `WebDriverWait(driver, 10).until(EC.url_contains('/dashboard'))` instead of `time.sleep(2)`. On top of the wait fix, isolate tests from each other (fresh browser context/incognito per test, don't share login state across tests unless intentional), and add a failure artifact (screenshot + network log) so the next flake tells you exactly what state the page was in instead of just 'assertion failed.'

Question 4

Structure a test framework for 40 screens so a UI change touches one place.

Accepted Answer

With 40 screens, the failure mode to design against is one CSS class or button rename breaking 15 different test files. The Page Object Model fixes this by putting every locator and every screen-level action behind one class per screen (or per reusable component), so tests call loginPage.login(user, pass) instead of finding #username themselves — when the id changes, you edit one method in one file.

```javascript
class LoginPage {
  usernameInput = () => this.page.locator('#username');
  passwordInput = () => this.page.locator('#password');
  submitBtn = () => this.page.locator('[data-testid="login-submit"]');

async login(user, pass) {
    await this.usernameInput().fill(user);
    await this.passwordInput().fill(pass);
    await this.submitBtn().click();
  }
}
```

At 40 screens, a flat one-class-per-screen structure alone isn't enough — extract shared chrome (header nav, a filter sidebar, a modal that appears on a dozen screens) into separate component objects that page objects compose, rather than copy-pasting the same locator into every page class. Use a BasePage for cross-cutting concerns (waiting for the app shell to load, common toast/error assertions) so every page object inherits it instead of reimplementing it. And keep assertions out of the page object entirely — page objects describe how to interact with the screen, tests decide what should be true; mixing the two means a shared method breaks unrelated tests when someone tweaks an assertion inside it.

Question 5

For a POST /orders endpoint, design positive, negative, and contract tests including auth and idempotency.

Accepted Answer

Positive tests confirm the happy path: a valid payload returns 201 Created, the response body matches the expected order shape (schema-validated, not just spot-checked fields), and a Location header or order id is present. Negative tests cover the ways a client can misuse the endpoint — missing required fields (400), an unauthenticated request (401), a valid token without order-create permission (403), a non-existent product id (404), and a legitimate-looking request that fails a business rule like insufficient stock (409 or 422, and check the API is consistent about which).

Contract tests check the response shape stays stable for consumers even as the implementation changes — validate the JSON response against the OpenAPI schema (or a Pact contract if a separate frontend/consumer team depends on this endpoint), so a backend refactor that silently renames orderId to id fails CI before it reaches a real client.

Idempotency deserves its own dedicated test: send the identical request twice with the same Idempotency-Key header (a common pattern for payment/order APIs, since a client retry after a timeout shouldn't create two orders) and assert both calls return the same order id rather than creating a duplicate:

```python
key = str(uuid.uuid4())
r1 = requests.post(url, json=payload, headers={"Idempotency-Key": key})
r2 = requests.post(url, json=payload, headers={"Idempotency-Key": key})
assert r1.json()["orderId"] == r2.json()["orderId"]
assert r1.status_code == 201 and r2.status_code in (200, 201)
```

Without this test, a common real bug slips through: the endpoint honors the idempotency key on success but not when the first call times out mid-processing, so a client retry after a slow response still double-charges.

Question 6

Decide what to mock versus hit for tests of a service that depends on a payment gateway and an email provider.

Accepted Answer

The decision hinges on what each dependency's role is in the test and how expensive/unreliable it is to call for real. A payment gateway is the classic mock candidate: real calls cost money, can create real charges, and their sandbox modes are often slower and less deterministic than a mock — so unit and most integration tests stub it to return canned success/failure/timeout responses, letting you deliberately test how your service behaves when the gateway declines a card or times out, which is hard to reliably trigger against a real sandbox on demand.

An email provider is usually mocked for the same reasons plus one more: you don't want CI runs actually emailing real inboxes. Assert that your code *called* the email service with the right template and recipient (a mock, verifying the interaction) rather than that an email physically arrived.

```python
def test_order_confirmation_email(mock_email_service, mock_payment_gateway):
    mock_payment_gateway.charge.return_value = {"status": "success"}
    create_order(cart, payment_info)
    mock_email_service.send.assert_called_once_with(
        template="order_confirmation", to=cart.customer_email
    )
```

What should NOT be mocked forever: a small number of true end-to-end tests, run against each provider's real sandbox/test-mode environment (Stripe test mode, a real SMTP sandbox like Mailtrap), on a schedule rather than every commit, to catch the case where the provider's actual API contract drifted from what your mocks assume — a mock that's never validated against reality eventually just tests your own assumptions, not the integration.

Question 7

A 45-minute E2E suite blocks every merge — redesign the suite using a test-pyramid budget.

Accepted Answer

A 45-minute E2E suite gating every merge is almost always a symptom of pushing coverage to the wrong layer — most of what a slow E2E suite checks (validation rules, pricing math, permission checks) doesn't need a real browser and a real backend to verify; it needs a unit test that runs in milliseconds. The fix is to redraw the suite against a test-pyramid budget: something like 70% unit tests (seconds total), 20% integration/API tests hitting a real backend but no browser (a minute or two), and 10% true browser E2E tests reserved for a handful of critical user journeys — login, checkout, the flows that actually require verifying the whole stack wired together.

Concretely: audit the 45-minute suite and reclassify each test by what it's actually verifying. A test asserting a discount calculates correctly doesn't need Selenium — pull that logic down to a unit test against the pricing function directly. A test asserting a page renders order history doesn't need to click through checkout first — hit the API to seed the order, then load the page directly (API-driven setup instead of UI-driven setup is usually the single biggest time saver in bloated E2E suites).

What's left after that triage — maybe 5-10 true end-to-end journeys — gets a time budget of its own, say under 8 minutes, and runs on every merge; blocking. Everything reclassified as broader regression coverage (cross-browser variants, less-critical flows) moves to a nightly or pre-release scheduled run instead of blocking every PR. This keeps the merge-blocking gate fast without losing coverage, it just moves most of it earlier (unit) or later (nightly) instead of stacking all of it in front of every merge.

Question 8

What is the difference between unit, integration, and end-to-end tests?

Accepted Answer

Unit tests check one function or class in isolation — no database, no network, all dependencies mocked or stubbed — and answer 'does this piece of logic do what it claims.' Integration tests check that two or more real pieces work together — a service talking to a real (or realistic test) database, or two internal services communicating — and catch problems unit tests structurally can't see, like a wrong SQL column type or a serialization mismatch between two teams' code. End-to-end tests drive the system the way a real user or client would, through the actual UI or public API, with everything wired together, and catch integration failures across the whole stack including things like auth, routing, and deployment config.

A concrete example: a unit test for a calculateDiscount(price, pct) function checks the math with mocked inputs; an integration test checks that saving an order with a discount actually persists the discounted total correctly in the real database; an E2E test opens the checkout page, applies a coupon, and confirms the total shown on screen and the emailed receipt both reflect the discount. Each layer catches a different class of bug, and each layer above is progressively slower and more expensive to write and run — which is exactly why the test pyramid recommends having many of the first and few of the last.

Question 9

What is the test pyramid and why does it matter?

Accepted Answer

The test pyramid is a shape recommendation for how a test suite's investment should be distributed: a wide base of fast, cheap unit tests, a narrower middle layer of integration/API tests, and a thin top of slow, expensive end-to-end tests. The reasoning is purely cost and speed — a unit test runs in milliseconds and pinpoints exactly which function broke, while an E2E test might take 30 seconds, depend on a dozen moving parts, and only tell you 'something on the checkout page is broken' without saying what.

In practice this means: if a bug can be caught by testing a function's logic directly, don't route that check through a full browser test just because it 'feels more real' — you pay 100x the runtime for the same signal. A team that inverts the pyramid (few unit tests, hundreds of E2E tests) typically ends up with a CI suite that takes an hour, is chronically flaky, and where a single failure requires 20 minutes of investigation to find the actual root cause instead of a stack trace pointing straight at the broken function.

Question 10

Explain smoke testing vs sanity testing.

Accepted Answer

Smoke testing is a quick, broad check run right after a new build to answer 'is this build stable enough to test at all' — does the app launch, can you log in, does the homepage load, nothing catastrophically broken. It's shallow but wide: a handful of checks across many areas, run before investing more testing time.

Sanity testing is narrow but deep: after a specific bug fix or small change, you verify that the specific area affected now works correctly, without doing a full regression pass. If a bug fix touched the password-reset flow, a sanity test checks password reset works end to end; it doesn't re-verify the entire authentication module.

A useful way to remember the difference: smoke asks 'is the whole build not on fire,' sanity asks 'did this specific fix actually work.' Teams commonly automate smoke tests as a CI gate that blocks deployment if it fails, while sanity checks are often quick manual verification right after a hotfix, before a fuller regression suite runs later.

Question 11

What is regression testing and how do you decide what to include in a regression suite?

Accepted Answer

Regression testing re-runs existing tests after a change to make sure nothing that used to work got broken by it. The hard part isn't running the tests, it's deciding what belongs in the regression suite, because running every test ever written on every change doesn't scale — that's exactly the 45-minute-suite problem.

A practical approach: every regression suite entry should map to either a past production bug (so it never regresses silently again) or a core business flow (checkout, login, payment) that would be a P0 if it broke. Newly added feature tests graduate into the regression suite once the feature stabilizes, but exploratory or one-off tests for a feature still in flux usually don't belong there yet — they'd just add noise and maintenance cost for a UI still expected to change.

Concretely, when a bug ships to production — say, discount codes stacking incorrectly with loyalty points — the fix should come with a new regression test asserting the correct combined total, not just a manual verification that it's fixed. Without that test, the same bug class reappears in six months when someone touches the pricing code again and nothing catches it.

Question 12

Explain equivalence partitioning with an example.

Accepted Answer

Equivalence partitioning splits a field's possible inputs into groups where every value in a group should be handled the same way, then tests one representative value per group instead of every possible value — the assumption being if 25 works for a valid-age field expecting 18-65, 26 through 64 don't need separate tests because they hit the same code path.

For an age field validated as 18-65: the valid partition is anything 18-65 (test with, say, 30), one invalid partition is below 18 (test with 10), another invalid partition is above 65 (test with 90), and a third invalid partition is non-numeric input (test with "abc"). That's 4 tests instead of testing every integer from 0 to 200.

Equivalence partitioning is usually paired with boundary value analysis rather than used alone — partitioning tells you which groups exist, boundaries tell you where inside each group bugs actually cluster (off-by-one errors happen at 17/18 and 65/66, not at 30 or 90), so a real test plan tests the boundaries of each partition, not just an arbitrary middle value.

Question 13

Explain decision table testing with an example.

Accepted Answer

A decision table lists every combination of relevant input conditions as columns and the expected outcome as a row, which is the right tool when a system's behavior depends on multiple independent conditions combining, not just one field's own valid range. It also forces you to notice combinations the spec forgot to define.

Example for a loan approval rule with two conditions — credit score >= 700, and income >= $50k:

| Credit >=700 | Income >=50k | Outcome |
|---|---|---|
| Y | Y | Approve |
| Y | N | Manual review |
| N | Y | Manual review |
| N | N | Reject |

Each row becomes one test case. The value shows up most clearly once you add a third condition — say, existing default on file — because the table then has 8 rows instead of 4, and it's common to discover during table construction that the business rule never actually said what should happen for one of those combinations (does an existing default override an otherwise-approvable score+income combo?), which is a much cheaper time to catch that gap than after the feature ships.

Question 14

What is the difference between Selenium and Playwright?

Accepted Answer

Selenium WebDriver talks to browsers through the W3C WebDriver protocol — a separate driver binary (chromedriver, geckodriver) sits between your test code and the browser, translating commands. It supports the widest range of browsers and languages and has the largest ecosystem, but it has no built-in auto-waiting: you're expected to add explicit waits yourself, which is the single biggest source of flaky Selenium suites.

Playwright, from Microsoft, talks to browsers over their native automation protocols without a separate driver process, and it auto-waits for elements to be actionable (visible, enabled, not animating) before every interaction by default — which eliminates a large share of the flakiness that plagues naive Selenium scripts. It also ships built-in network interception, multiple isolated browser contexts per test (faster than spinning up a new browser), and a built-in test runner with parallelization and trace viewer for debugging failures.

In practice: choose Selenium when you need Safari/IE-class legacy browser coverage, an existing large Selenium codebase, or a language Playwright doesn't support well; choose Playwright for new projects on modern browsers, since less boilerplate is needed to get a stable, fast suite. Cypress is a third common option, similar to Playwright's developer experience but historically limited to Chromium-family browsers and running inside the browser itself rather than driving it externally.

Question 15

How does Selenium WebDriver locate elements, and what's the recommended locator priority?

Accepted Answer

WebDriver locates elements via a strategy plus a value: by id, CSS selector, XPath, link text, tag name, class name, or name attribute. The reliability and maintenance cost differ a lot between these, which is why teams pick a priority order rather than using whichever locator DevTools happens to suggest.

The commonly recommended priority, most to least preferred: a dedicated test attribute like data-testid (stable because it's not tied to styling or structure, and won't change when a designer reworks the CSS), then id (fast and unique, but often auto-generated and unstable in some frameworks), then CSS selector (readable, fast, but can break if class names are reused for styling), and XPath last (powerful — can select by text content or traverse up the DOM — but slower and the most brittle against markup changes).

```java
// preferred: stable, intent-revealing
driver.findElement(By.cssSelector("[data-testid='submit-btn']"));

// avoid: brittle, breaks if a designer changes layout
driver.findElement(By.xpath("//div[3]/div[2]/button"));
```

Introducing data-testid attributes specifically for tests (rather than repurposing CSS classes or ids meant for styling) is worth the small dev effort because it decouples test stability from visual design changes — one of the most common causes of an automation suite needing constant locator maintenance.

Question 16

Explain explicit wait vs implicit wait in Selenium.

Accepted Answer

Implicit wait is a single global setting on the WebDriver instance telling it to poll for up to N seconds whenever any findElement call doesn't immediately find a match, before throwing NoSuchElementException. It's set once and applies everywhere, which is exactly its problem — it's a blunt, one-size-fits-all timeout that can't express 'wait for this element to be clickable' versus 'wait for this element to disappear.'

Explicit wait targets a specific condition on a specific element: WebDriverWait(driver, 10).until(EC.element_to_be_clickable((By.ID, 'submit'))) waits up to 10 seconds specifically for that element to become clickable, polling repeatedly rather than sleeping the full duration. This is what most real test flakiness fixes come down to — replacing a vague 'wait a bit' with a wait tied to the actual condition the next step depends on.

The two shouldn't be mixed carelessly: Selenium's docs warn that combining implicit and explicit waits on the same driver can produce unpredictable total wait times (they can compound in edge cases), so most teams pick one strategy — almost always explicit waits — and set the implicit wait to 0.

Question 17

What is data-driven testing and when would you use it?

Accepted Answer

Data-driven testing separates the test logic (the steps and assertions) from the test data (the specific inputs and expected outputs), so one test function runs many times against a table of inputs instead of copy-pasting the same test with one value changed each time.

```python
import pytest

@pytest.mark.parametrize("email,expected_valid", [
    ("user@example.com", True),
    ("no-at-sign.com", False),
    ("", False),
    ("a@b.co", True),
])
def test_email_validation(email, expected_valid):
    assert is_valid_email(email) == expected_valid
```

This is the right tool when a function's behavior needs to be verified against many input variations that all exercise the same code path (validation rules, pricing tiers, permission matrices) — adding a new case is a one-line data addition instead of a whole new test method, and a bug found in production (a specific malformed email that slipped through) gets added as a new row rather than a new test file.

Question 18

What's the difference between mocking, stubbing, and faking in tests?

Accepted Answer

A stub is a hardcoded, canned response — it returns a fixed value regardless of input, used to isolate the code under test from a slow or unavailable dependency (e.g., a stub payment gateway that always returns 'success' so an order-processing test doesn't need real network access). A mock goes further: it's a stub that also records how it was called and lets the test assert on that — 'was sendEmail called exactly once, with this recipient' — which is useful when the interaction itself, not just the return value, is what needs verifying.

A fake is a working, simplified implementation instead of a canned response — an in-memory database that behaves like a real one (supports insert/query) but isn't the real Postgres instance, so tests can run fast without a real DB while still exercising real query logic rather than a hardcoded answer.

Concretely: testing that a checkout flow calls the email service exactly once uses a mock; testing that checkout works when the payment gateway is 'down' uses a stub configured to throw; testing repository query logic without spinning up a real database uses a fake in-memory store. Overusing mocks specifically is a common test-quality issue — a suite full of mocks that only verifies 'function A called function B' can pass even when the actual business behavior is wrong, because it never checks real outputs, only call patterns.

Question 19

How do you test a REST API's error responses (4xx/5xx)?

Accepted Answer

Testing error paths means asserting both the right status code and a response body a client can actually act on — not just that a 4xx or 5xx came back, but the specific code the spec promises and a consistent error shape (an error code, a human-readable message, sometimes a field-level detail for validation errors).

Concretely for an endpoint like POST /orders: send a request missing a required field and assert 400 with a body identifying which field failed, not a generic 'bad request'; send a request with an expired auth token and assert 401 (not 403, which should be reserved for 'authenticated but not allowed'); send a request for a product id that doesn't exist and assert 404; and trigger the endpoint's own internal error path (e.g., mock the downstream payment service to throw) and assert 500 doesn't leak a stack trace or internal exception message in the response body — that's both a testing gap and a security issue.

```python
resp = requests.post(url, json={})  # missing required fields
assert resp.status_code == 400
assert resp.json()["error"]["field"] == "productId"
```

A subtle bug this kind of test catches: an endpoint that returns 200 with an {"success": false} body instead of a real HTTP error code — which looks fine in a manual check but silently breaks any client or monitoring tool that keys off status codes rather than parsing the body.

Question 20

What is contract testing and how does Pact work?

Accepted Answer

Contract testing verifies that a consumer (say, a frontend or another microservice) and a provider (the API it calls) agree on the shape of their interaction, without either side needing the other running — which matters most in a microservices setup where dozens of services are versioned and deployed independently, and a full integration test against every real dependency doesn't scale.

Pact works consumer-first: the consumer's test defines the interactions it expects ("when I POST to /orders with this payload, I expect a 201 and a body with orderId") and running that test generates a contract file. That contract is published to a Pact Broker, and the provider's CI pipeline replays every recorded interaction from every consumer's contract against the real provider code, failing the build if the provider's actual response no longer matches what any consumer expects.

```javascript
// consumer test defines the expected interaction
provider.addInteraction({
  state: 'an order exists',
  uponReceiving: 'a request for order details',
  withRequest: { method: 'GET', path: '/orders/123' },
  willRespondWith: { status: 200, body: { orderId: '123', status: like('shipped') } }
});
```

The payoff: a backend team can refactor freely and know immediately, in their own CI, if they've broken a frontend team's contract — without either team needing to spin up the other's full application, and without the slow, flaky full-stack integration tests that traditionally caught this kind of breakage only after deployment.

Question 21

How do you handle authentication tokens in automated API tests?

Accepted Answer

The usual pattern is a setup/fixture step that authenticates once (or reuses a cached token across a test run) and injects the resulting token into every subsequent request's headers, rather than re-authenticating inside every single test — that's both slower and couples every test's success to the login endpoint working.

```python
@pytest.fixture(scope="session")
def auth_token():
    resp = requests.post(f"{BASE_URL}/auth/login", json={"email": TEST_USER, "password": TEST_PASS})
    return resp.json()["accessToken"]

def test_create_order(auth_token):
    headers = {"Authorization": f"Bearer {auth_token}"}
    resp = requests.post(f"{BASE_URL}/orders", json=payload, headers=headers)
    assert resp.status_code == 201
```

For tests that specifically need to verify auth behavior — expired token, malformed token, token for a different role — those get their own explicit test cases with a deliberately broken/scoped-down token, rather than reusing the session-wide valid token. And test credentials should live in environment variables or a secrets manager the CI pipeline injects, never hardcoded in the test file, both for security and so the same suite can point at different environments (local, staging) by swapping config, not code.

Question 22

What is BDD and how does Gherkin syntax work?

Accepted Answer

BDD (Behavior-Driven Development) writes test scenarios in a structured, plain-language format — Given/When/Then — so the same document serves as a specification a product owner can read, a test a QA engineer can automate, and living documentation of what the system actually does, instead of three separate artifacts that drift out of sync.

```gherkin
Feature: Discount codes
  Scenario: Applying a valid discount code at checkout
    Given a cart with items totaling $100
    When the customer applies the discount code "SAVE20"
    Then the order total should be $80
```

A framework like Cucumber or Behave maps each Given/When/Then line to a step-definition function that does the actual work (setting up the cart, applying the code, checking the total), so the scenario stays readable while the automation underneath can be as complex as needed. The real value of Gherkin isn't the syntax — it's forcing three-way agreement (product, dev, QA) on exactly what 'valid discount code' means and what 'applying' it should do, ideally worked out before the feature is built (three amigos sessions), which catches ambiguous requirements a lot earlier and cheaper than a bug report after launch.

Question 23

What is the difference between TDD and BDD?

Accepted Answer

TDD (Test-Driven Development) is a coding discipline: write a failing unit test for a small piece of behavior, write just enough code to make it pass, then refactor — repeat. It's developer-facing and operates at the level of individual functions/classes, and its main goal is driving clean, testable design as a side effect of the red-green-refactor loop.

BDD operates one level up: it describes system behavior from a user or business perspective (Given/When/Then scenarios), is meant to be readable by non-engineers, and its main goal is closing the gap between what the business asked for and what got built — not driving low-level code design.

They're complementary, not competing: a team might write a BDD scenario ('applying SAVE20 reduces the total by 20%') to agree on requirements with the product owner, then use TDD internally while implementing the discount-calculation function that scenario depends on. Treating BDD as 'TDD with fancier syntax' is a common misunderstanding — BDD scenarios usually map to acceptance/integration-level tests, not the fine-grained unit tests TDD produces.

Question 24

How do you set up parallel test execution and what problems does it introduce?

Accepted Answer

Parallel execution splits a test suite across multiple workers/machines so it finishes in a fraction of the wall-clock time — a 45-minute suite run four-way in parallel finishes in roughly 12 minutes, assuming even distribution. Most modern runners (Playwright, Jest, pytest-xdist) support this natively via a --workers/-n flag.

The problems it introduces are almost always shared-state bugs that were invisible when tests ran one at a time: two tests both creating a user with the same hardcoded email will race and one will fail with a duplicate-key error; two tests both asserting 'the products table has exactly 5 rows' will conflict if they run against a shared database at the same time; a test that leaves global state dirty (a feature flag flipped on, a file written to a fixed path) can leak into a concurrently running unrelated test.

The fix is designing tests to be independent by construction: generate unique test data per test (a UUID-suffixed email, not a fixed one), use isolated database schemas/transactions per worker where possible, and avoid tests that assert on shared global counts rather than on data they created themselves. A suite that only works serially and breaks under parallelization usually has one of these hidden coupling bugs, and it's worth fixing rather than just disabling parallel runs, since the same coupling can also cause order-dependent failures in CI reruns.

Question 25

What is flaky test quarantine and how would you implement one in CI?

Accepted Answer

A flaky test is one that passes and fails on the same code, with no code change in between — and the wrong response to a flaky test is to just delete it or ignore its failures, because it's usually pointing at a real timing bug even when the test itself is also poorly written. Quarantine is a middle path: move the test out of the merge-blocking suite into a separate, tracked 'known flaky' bucket so it stops blocking unrelated PRs, without losing its coverage or its signal entirely.

A practical setup: tag flaky tests (@flaky or a similar marker), run them in a separate CI job that reports results but doesn't fail the build, and track a re-run/failure rate per test — if a test fails more than, say, 5% of runs, it gets auto-flagged into quarantine and someone is assigned to fix or delete it, with a deadline.

```yaml
# CI config sketch
- name: Stable tests (blocking)
  run: pytest -m "not flaky"
- name: Quarantined tests (non-blocking, tracked)
  run: pytest -m "flaky" || true
```

Without an active quarantine process, flaky tests tend to accumulate silently until a team just stops trusting red CI at all and starts merging on red — which defeats the entire point of having a test suite.

Question 26

How do you measure code coverage and what are its limits?

Accepted Answer

Code coverage measures which lines (or branches, or conditions) actually executed during a test run, usually reported as a percentage via a tool like Istanbul/nyc for JS, coverage.py for Python, or JaCoCo for Java, and it's genuinely useful for finding code nobody tests at all — an untested error-handling branch, a dead code path.

Its core limit is that coverage measures execution, not verification — a line can execute during a test and still be completely unchecked by any assertion, which means 100% coverage is achievable with tests that assert nothing meaningful.

```javascript
function divide(a, b) { return a / b; }

test('divide runs', () => {
  divide(10, 2); // line executes -> counts as covered
  // no assertion at all — a bug here (e.g. divide-by-zero) is invisible
});
```

That test gives 100% line coverage on divide while catching zero bugs, including the obvious missing divide-by-zero check. This is why coverage percentage should be treated as a floor-finder (what's completely untested) rather than a quality score — a codebase can have 95% coverage and still ship a critical bug, and chasing the last 5% often has worse ROI than reviewing whether the existing 95% actually asserts anything meaningful.

Question 27

What is mutation testing and how does it differ from code coverage?

Accepted Answer

Mutation testing answers the question code coverage can't: not 'did my tests run this line,' but 'would my tests actually notice if this line were wrong.' A mutation testing tool automatically introduces small deliberate bugs into the code — flipping a > to >=, changing + to -, negating a boolean — one at a time, called mutants, then reruns the test suite against each mutant. If the tests still pass, that mutant 'survived,' meaning the tests didn't actually verify that piece of logic; if a test fails, the mutant was 'killed.'

```javascript
// original
function isEligible(age) { return age >= 18; }

// mutant: >= changed to >
function isEligible(age) { return age > 18; }
```

If the only test for isEligible calls it with age = 25, that mutant survives — the test never checks the boundary at exactly 18, so a real off-by-one bug there would also slip through undetected. Tools like Stryker (JS), PIT (Java), or mutmut (Python) automate this and report a mutation score, which is a much stronger signal of test quality than line coverage — but it's also computationally expensive (running the full suite once per mutant), so most teams run it periodically or on critical modules rather than on every commit.

Question 28

How would you performance-test an API endpoint (tools, key metrics)?

Accepted Answer

Performance testing an endpoint means driving simulated load against it and measuring how response time and error rate behave as load increases, using a tool like k6, JMeter, Gatling, or Locust to generate concurrent virtual users rather than testing with a single manual request.

```javascript
// k6 script sketch
import http from 'k6/http';
export const options = { vus: 50, duration: '2m' };
export default function () {
  http.post('https://api.example.com/orders', JSON.stringify(payload));
}
```

The metrics that matter go beyond average response time, which hides the real problem: p95 and p99 latency (the slowest 5% and 1% of requests — usually what actual users complain about), error rate under load, and throughput (requests/sec the endpoint can sustain before it degrades). A common finding this surfaces: average latency looks fine at 200ms, but p99 is 8 seconds because of a database connection pool exhausting under concurrent load — a bug invisible to a single-user manual test but catastrophic for real traffic.

Before running load, agree on a target based on real usage (e.g., 'must sustain 200 req/s at p95 < 300ms' from expected peak traffic plus headroom) rather than testing an arbitrary number and declaring success — a performance test with no target is just a number with no verdict attached.

Question 29

What's the difference between load testing, stress testing, and soak testing?

Accepted Answer

Load testing checks how the system behaves at an expected, realistic level of concurrent usage — does it meet its performance target (say, p95 < 300ms) at the traffic volume it's actually built for. Stress testing pushes well past that expected load, deliberately, to find the breaking point and see how the system fails — does it degrade gracefully (slower responses, clear errors) or catastrophically (crashes, corrupts data, cascades to unrelated services).

Soak testing (also called endurance testing) runs a sustained, moderate load for an extended period — hours, sometimes days — to catch problems that only appear over time: a memory leak that's invisible in a 5-minute load test but crashes the service after 6 hours, a connection pool that slowly exhausts because connections aren't being released, a log file that fills the disk.

A concrete distinction: load testing tells you 'the checkout service handles our Black Friday traffic estimate fine'; stress testing tells you 'at 5x that traffic, it returns 503s cleanly instead of crashing the database for every other service sharing it'; soak testing tells you 'it still handles normal traffic fine after running continuously for 48 hours,' which is exactly the kind of bug that a short load test, however thorough, structurally cannot catch.

Question 30

How do you approach mobile testing across many devices?

Accepted Answer

Testing across many real devices at once isn't feasible to do fully manually, so most teams combine a small set of automated tests run across a device matrix (via a cloud device farm like BrowserStack, Sauce Labs, or Firebase Test Lab) with a much smaller set of manual exploratory sessions on a few representative real devices.

The device matrix should be chosen by actual usage data, not guesswork — pull the app's own analytics for the top OS versions, screen sizes, and manufacturers real users are on, and prioritize coverage there rather than testing every device that exists. A common gap this catches: an app that works fine on a flagship phone with a tall screen but clips a critical button below the fold on a smaller or older device with on-screen navigation buttons eating extra vertical space.

Automation frameworks like Appium (cross-platform, WebDriver-based, works for native and hybrid apps) let the same test logic run against both iOS and Android by swapping the driver capabilities, though locator strategies and platform-specific quirks (permission dialogs, deep links, OS-level interruptions like an incoming call) usually need some platform-specific handling rather than one identical script for both. Given the cost of full device-matrix runs, teams commonly run a fast smoke suite against a handful of top devices on every PR and reserve the full matrix for nightly or pre-release runs.

Question 31

What is visual regression testing and what tools support it?

Accepted Answer

Visual regression testing catches UI bugs that functional tests structurally can't — a button that's technically clickable and correctly wired but has become invisible because its color matches the background, or a layout that's shifted and now overlaps text, none of which a functional assertion like 'button exists and is clickable' would ever catch.

The mechanism: capture a screenshot of a page/component as a baseline, then on every subsequent run capture a new screenshot and diff it pixel-by-pixel (or via perceptual diffing) against the baseline, flagging anything above a configured difference threshold for human review. Tools like Percy, Applitools Eyes, and Playwright's built-in toHaveScreenshot() all follow this pattern.

```javascript
await expect(page).toHaveScreenshot('checkout-page.png', { maxDiffPixels: 100 });
```

The tooling matters because naive pixel-diffing is noisy — font anti-aliasing rendering slightly differently between CI and a local machine, or a dynamic timestamp on the page, can trigger false-positive diffs on every run. Mature tools handle this with perceptual diffing (ignoring imperceptible sub-pixel differences) and masking regions that are expected to change (timestamps, ads, user avatars) rather than diffing the whole page as one flat image.

Question 32

How do you approach accessibility testing for a web app?

Accepted Answer

Accessibility testing checks that people using assistive technology — screen readers, keyboard-only navigation, voice control — can actually use the product, and it splits into automated and manual layers because automated tools can only catch a subset of real accessibility issues.

Automated tools like axe-core (usable standalone or wired into Playwright/Cypress via @axe-core/playwright) catch objective, rule-based violations: missing alt text on images, insufficient color contrast, form inputs without associated labels, missing ARIA roles — these can run in CI on every PR just like a functional test.

```javascript
const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toEqual([]);
```

What automated tools structurally can't catch is whether the experience actually makes sense to someone using it — does tab order follow a logical reading flow, does a screen reader announce a form error in a way that's actually understandable, is a custom dropdown genuinely operable with only a keyboard. That needs manual testing with an actual screen reader (VoiceOver, NVDA) and keyboard-only navigation, ideally against the WCAG 2.1 AA success criteria as a checklist rather than relying on the automated scan's green checkmark as proof the page is accessible.

Question 33

What is exploratory testing and how do you structure it with session-based test management?

Accepted Answer

Exploratory testing is simultaneous learning, test design, and test execution — instead of following a pre-written script, the tester actively investigates the application, forms hypotheses about where bugs might hide, and adapts the next action based on what the last one revealed. It's especially valuable for finding the kind of bug a scripted test never thinks to check, because scripted tests can only find what someone already anticipated writing a script for.

Session-based test management gives exploratory testing enough structure to be trackable rather than purely ad hoc: define a time-boxed session (say, 60-90 minutes) with a charter — a specific mission like 'explore the checkout flow's edge cases around payment failures and interrupted sessions' — and the tester takes notes during the session on what was covered, bugs found, and questions raised, producing a session report afterward.

This matters for coverage tracking specifically because pure unstructured exploratory testing is hard to account for in a report ('we tested it' isn't verifiable), while a stack of session charters and reports gives a concrete, reviewable record of what areas got real human attention and what didn't — useful input for deciding where the next round of exploratory time should go, and for justifying to a release manager that a feature actually got looked at by a human beyond the automated suite.

Question 34

How do you prioritize test cases when release time is limited (risk-based testing)?

Accepted Answer

When there isn't enough time to test everything before a release, risk-based testing prioritizes by two factors multiplied together: the probability something is broken, and the impact if it is. A feature that's brand new, touched by a large recent refactor, or historically buggy scores high probability; a feature on the critical revenue path (checkout, payment) or affecting many users scores high impact — the combination is what should get tested first, not whichever area is easiest or most familiar to test.

A concrete triage: given a release touching (a) a rarely-used admin settings page, (b) the payment flow with a new gateway integration, and (c) a cosmetic footer link update, risk-based prioritization puts nearly all remaining test time on (b) — high probability (new integration, never run in production) and high impact (revenue-critical) — spends a light pass on (a), and largely skips deep testing on (c) beyond a glance, because even a worst-case bug there is low-impact and easy to hotfix.

This isn't a one-time exercise — a risk matrix built at project start should get revisited right before release using what actually changed in that release cycle, since a normally low-risk area that had unusual recent churn (a junior engineer's first PR touching the pricing engine, say) can jump in priority even if it's 'always been stable' historically.

Question 35

What is shift-left testing?

Accepted Answer

Shift-left means moving testing activities earlier in the development timeline — toward the 'left' side of a left-to-right project timeline — instead of treating QA as a phase that starts only after development finishes. In practice, that means writing tests alongside (or before, in TDD) the code rather than after a feature is 'done,' involving QA in requirements/design discussions (three amigos sessions) so ambiguities are caught before code is written, and running fast automated checks (linting, unit tests, security scans) on every commit rather than in a separate manual QA pass at the end.

The economic argument is the well-known cost curve: a bug caught while writing the requirements costs a conversation to fix; the same bug caught in a design review costs a diagram edit; caught in code review it costs a re-write before merge; caught in QA after the feature is built it costs a bug report, a triage, a re-fix, and a re-test cycle; caught in production it costs an incident, a hotfix, and reputational/revenue damage on top of all of the above.

A concrete shift-left practice: a QA engineer reviewing a feature's Jira ticket before any code is written and flagging 'this doesn't say what happens if the discount code is applied twice' catches an ambiguity for the price of a comment, versus catching it as a bug report three weeks later after a customer double-applies a code in production.

Question 36

How do you manage test data for automated tests?

Accepted Answer

Test data management covers how automated tests get realistic, isolated data to run against without tests stepping on each other or depending on brittle, hand-seeded fixtures that drift out of sync with the real schema. The core principle is that each test should create the data it needs and clean up after itself, rather than relying on a shared pool of pre-existing records that other tests might also be mutating.

Common patterns: a factory library (Factory Boy in Python, Faker.js/factory functions in JS) that generates realistic-looking random data with sensible defaults, letting a test override only the fields it actually cares about:

```javascript
const order = buildOrder({ status: 'pending', total: 99.99 }); // other fields get sane defaults
```

For tests needing a real database, Testcontainers spins up a real, disposable database instance (Postgres, MySQL) in Docker for the test run and tears it down after, giving tests a real database engine to run against without a shared, stateful test DB that accumulates cruft across runs. For production-like data volume or shape testing, anonymized/masked copies of real data are sometimes used, but require strict PII scrubbing before they ever leave production — using real customer data unmasked in a test environment is both a compliance risk and, in many jurisdictions, a legal one.

Question 37

How do you approach cross-browser testing strategy?

Accepted Answer

Cross-browser testing checks that a web app behaves consistently across different browser engines — Chromium (Chrome, Edge), Gecko (Firefox), and WebKit (Safari) — because each implements CSS, JavaScript APIs, and rendering slightly differently, and a bug that only reproduces in one engine is easy to miss if the team only ever tests in Chrome during development.

Rather than running the entire suite against every browser on every commit (expensive and slow), a practical approach tiers it: a fast smoke suite runs against all target browsers on every PR to catch obvious breakage, while the full regression suite runs against the primary development browser on every commit and against the full browser matrix on a schedule (nightly, or pre-release) since most bugs aren't browser-specific and re-running the full suite three times per commit for marginal extra coverage isn't worth the CI cost.

```javascript
// Playwright config running the same tests against 3 engines
projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  { name: 'webkit', use: { ...devices['Desktop Safari'] } },
]
```

A concrete bug this catches: a CSS Grid layout that renders correctly in Chrome but collapses in Safari due to a vendor-prefix gap, or a Date parsing quirk that behaves differently in Safari's JS engine than in Chrome's V8 — both invisible if the whole team develops and tests exclusively in one browser.

Question 38

How would you design tests for a rate limiter (e.g., 100 requests/minute per user)?

Accepted Answer

Testing a rate limiter means testing at three points relative to the limit: just under it, exactly at it, and just over it — plus what happens across the window boundary, which is where the subtlest bugs live. Send 99 requests in a minute and confirm all succeed; send 101 and confirm the 101st gets 429 Too Many Requests with a Retry-After header, not a silent failure or, worse, a request that gets processed anyway.

```python
responses = [requests.get(url, headers=auth) for _ in range(101)]
assert all(r.status_code == 200 for r in responses[:100])
assert responses[100].status_code == 429
assert 'Retry-After' in responses[100].headers
```

The window-boundary case is the one most teams skip: if the limiter uses a fixed window (resets every minute on the clock), sending 100 requests at 0:59 and another 100 at 1:01 both succeed even though it's 200 requests in 2 seconds — a real bypass of the intended limit that only a sliding-window algorithm avoids. A thorough test suite checks which algorithm is actually implemented (fixed window, sliding window, token bucket) and writes a boundary-crossing test specific to that algorithm's known weak point, plus a multi-tenant check confirming one user hitting their limit doesn't throttle a different user sharing the same server.

Question 39

How do you test idempotency for a payment API that might be retried by the client?

Accepted Answer

A payment API needs idempotency specifically because network failures are ambiguous from the client's side — if a payment request times out, the client genuinely can't tell whether the charge succeeded before the connection dropped, so a naive retry risks double-charging a real customer. Testing this means simulating exactly that ambiguity, not just checking the happy path twice.

The standard pattern is an idempotency key the client generates once and sends with every retry of the same logical request; the server persists a mapping of key to result and returns the original result for any repeat, without re-executing the charge:

```python
key = str(uuid.uuid4())
r1 = charge_payment(amount=500, idempotency_key=key)
r2 = charge_payment(amount=500, idempotency_key=key)  # simulated retry
assert r1.json()["chargeId"] == r2.json()["chargeId"]
assert get_charge_count_for_customer(customer_id) == 1  # not charged twice
```

The test that actually catches real bugs here is a concurrent retry — fire both requests with the same key at nearly the same instant (simulating a client that retries before the first response even comes back) and confirm only one charge is created, not two; a naive implementation that checks 'does this key exist' and then inserts, without a unique constraint or lock, has a race window where both concurrent requests pass the check before either has written its result. That race is invisible in a sequential test and only shows up under real concurrent load, which is why it needs to be tested deliberately rather than assumed away.

Question 40

How would you statistically detect and quantify flaky tests rather than guessing from a single failure?

Accepted Answer

Detecting flakiness reliably needs more than 'this test failed once, ignore it' or 'this test failed twice, it's definitely flaky' — both are unreliable with too little data. A better approach tracks each test's pass/fail history across recent runs (CI systems or a test-analytics tool like BuildPulse, Datadog CI Visibility, or a custom job querying CI history) and computes a flakiness rate: failures divided by total runs over, say, the last 50 runs, for that specific test.

A test with a 2% failure rate over 50 runs (one flake) is much less certain to genuinely be flaky than one with a 20% failure rate — the fix is usually to require a minimum sample size and a rerun-on-failure signal specifically: if a failed test passes on an immediate retry with no code change, that's strong evidence of flakiness (a genuine bug reproduces consistently; a flaky test often doesn't), whereas a test that fails consistently on retry is probably a real regression, not flakiness.

```
flakiness_rate = retried_and_passed_runs / total_failed_runs
```

Teams that build this out often auto-quarantine a test once its trailing flakiness rate crosses a threshold (say 5% over 20+ runs) rather than relying on someone noticing a pattern manually, since a slow-building flakiness trend is easy to miss run-by-run but obvious once aggregated.

Question 41

What does a low mutation score alongside high line coverage tell you about a test suite?

Accepted Answer

This combination means the test suite executes almost every line but doesn't actually verify the behavior of most of them — coverage measures whether code ran, mutation score measures whether the tests would notice if that code were subtly wrong, and a big gap between the two is the clearest possible signal of assertion-free or weakly-asserted tests.

A concrete pattern that produces exactly this: tests that call a function and check only that it didn't throw, or that check a return value's type/existence but not its actual value (expect(result).toBeDefined() instead of expect(result).toBe(42)). Every line executes, coverage looks great, but a mutant that flips + to - or > to < inside that function survives because nothing checks the actual computed value.

```javascript
test('calculates total', () => {
  const result = calculateTotal(cart);
  expect(result).toBeDefined(); // passes even if the math is wrong
});
```

The fix isn't writing more tests, it's strengthening the assertions in the tests that already exist — replacing loose existence checks with exact expected-value checks, and adding boundary-value assertions specifically where mutants are known to survive (a mutation report names exactly which line and which mutant survived, so it's a targeted fix list, not a guessing game).

Question 42

How would you test for eventual consistency issues in a distributed system (e.g., read-after-write)?

Accepted Answer

In a distributed system with eventual consistency (a write goes to a primary, reads might hit a replica that hasn't caught up yet), a naive test that writes data and immediately reads it back can pass locally against a single test database and then fail intermittently in an environment with real replication lag — which makes it a specific, non-obvious source of flakiness distinct from ordinary timing bugs in application code.

Testing this deliberately means either (a) explicitly testing the inconsistency window itself — write, immediately read, and assert the system's documented behavior for a stale read (does it show the old value, or does the API guarantee read-your-own-writes via a sticky session/primary read), rather than assuming it always reflects the latest write — or (b) if the system promises strong consistency for a specific operation, testing that promise under load by writing and reading in a tight loop from different simulated clients to try to surface a real staleness violation.

```python
write_response = client.put(f"/orders/{order_id}", data)
read_response = client.get(f"/orders/{order_id}")
# depends on the system's actual consistency guarantee — don't assume strong consistency
assert read_response.json()["status"] in (data["status"], previous_status)
```

The key mistake to avoid is writing a test that asserts strong consistency when the system was never designed to provide it — that test will be flaky forever, and 'flaky' is the wrong diagnosis; the real issue is the test encodes a guarantee the architecture doesn't make, and the fix is either changing the assertion to match the real guarantee or changing the architecture, not adding a retry loop to paper over it.

Question 43

How do you test a feature that's behind a percentage-based rollout feature flag?

Accepted Answer

A percentage-based rollout flag (say, a new checkout flow enabled for 10% of users) needs tests for both variants of the flag and for the decision of which variant a given user gets, not just for the new code path in isolation.

Functional coverage: run the full relevant test suite twice, once with the flag forced on and once forced off, so both the old and new code paths are verified — most flag systems provide a way to override the rollout percentage for a given test user/context precisely for this reason, rather than relying on random assignment during a test run.

```javascript
test('checkout works with new-flow flag ON', async () => {
  await setFeatureFlagOverride('new-checkout-flow', true);
  await runCheckoutFlow();
});
test('checkout works with new-flow flag OFF', async () => {
  await setFeatureFlagOverride('new-checkout-flow', false);
  await runCheckoutFlow();
});
```

Beyond the two variants, worth testing separately: the assignment itself is stable for a given user (the same user doesn't flip between old and new flow on every page load, which would break in-progress sessions), and that the flag's rollout percentage change doesn't require a deploy — if it's meant to be an instant kill-switch, test that flipping it to 0% actually stops new traffic from getting the new flow within the expected propagation delay, since a flag system with slow cache invalidation defeats the point of having an instant rollback lever.

Question 44

How do you test webhook delivery, including retries and signature verification?

Accepted Answer

Testing webhooks is unusual because the system under test is the caller, not a request-response API — your service needs to reliably deliver an HTTP POST to a URL the receiver controls, so tests need to verify delivery, retry behavior, and signature verification, from both the sending and receiving side.

On the sending side: spin up a local mock HTTP server the test controls, configure it as the webhook target, trigger the event, and assert the correct payload arrives; then make the mock server return a 500 or time out and assert the sender retries with backoff (and eventually gives up and logs/alerts after N attempts, rather than retrying forever) — a common real bug is a webhook sender with no retry limit that hammers a dead endpoint indefinitely, or no retry at all so a receiver's brief downtime silently drops events.

```javascript
mockServer.get('/webhook').respondWith(500).once(); // first attempt fails
mockServer.get('/webhook').respondWith(200);        // retry succeeds
await triggerEvent('order.created');
await waitFor(() => expect(mockServer.receivedCount).toBe(2));
```

On the signature side, most webhook systems sign the payload (an HMAC in a header, computed from the payload and a shared secret) so the receiver can verify a request genuinely came from the sender and wasn't forged — a test should verify a tampered payload with an unchanged signature is rejected by the receiver, and separately that a legitimate payload's signature actually validates, since both directions of that check have shipped broken in real systems.

Question 45

How do you test time-dependent logic (e.g., subscriptions expiring after 30 days) without waiting real time?

Accepted Answer

Logic that depends on the current time — a subscription expiring after 30 days, a discount code valid only during a date range, 'this offer expires in 2 hours' — is hard to test with real wall-clock waiting, so the standard approach is freezing or mocking the clock the code under test reads from, rather than actually waiting 30 real days in CI.

```javascript
// using jest's fake timers
jest.useFakeTimers().setSystemTime(new Date('2026-01-01T00:00:00Z'));
const sub = createSubscription({ durationDays: 30 });
jest.setSystemTime(new Date('2026-01-31T00:00:01Z'));
expect(sub.isExpired()).toBe(true);
```

This requires the code itself to read time through an injectable source (Date.now() wrapped in a clock service, or a library like Python's freezegun) rather than calling new Date() scattered directly throughout the codebase — a common refactor needed before this kind of test is even possible is centralizing time access behind one function so tests can substitute it.

Worth testing deliberately: the exact boundary (expires at exactly midnight — is the expiring moment itself expired or still valid), timezone handling (a 'valid until end of day' promotion needs a defined timezone, and a naive implementation using server-local time can make a discount expire at a different real-world moment for users in different timezones than intended), and daylight saving time transitions for any duration-based logic spanning a DST change, which has caused real off-by-one-hour bugs in scheduling systems.

Question 46

How would you test a Kafka consumer for correctness (ordering, at-least-once delivery)?

Accepted Answer

A message queue consumer's correctness properties are different from a typical function's — you're testing ordering guarantees, at-least-once vs exactly-once delivery semantics, and idempotent handling of redelivered messages, not just 'does the handler process one message correctly.'

A basic test publishes a known set of messages to a test topic (via Testcontainers running real Kafka, or an embedded/in-memory broker) and asserts the consumer processes each exactly as expected:

```python
producer.send('orders', {'orderId': '1', 'action': 'create'})
producer.send('orders', {'orderId': '1', 'action': 'cancel'})
consumer_group.wait_until_idle()
assert get_order_status('1') == 'cancelled'  # ordering preserved within a partition
```

Beyond that happy path, the properties worth testing deliberately: message redelivery — Kafka's at-least-once default means the same message can be delivered twice (after a consumer crash and rebalance before committing an offset), so the handler needs to be idempotent, and a test should feed the same message twice and confirm no duplicate side effect (e.g., an order isn't cancelled-and-then-cancelled-again in a way that double-refunds); and out-of-order handling across partitions — Kafka only guarantees ordering within a partition, so if related events for the same entity could land on different partitions, a test should confirm the consumer's logic tolerates that instead of assuming global ordering the underlying system never actually promised.

Question 47

How do you test for cache invalidation bugs?

Accepted Answer

Cache invalidation bugs show up as stale data — a user updates their profile, the change succeeds, but a cached copy elsewhere in the system keeps serving the old value past when it should. Testing for this means deliberately exercising the write-then-read-through-cache path, not just testing the cache and the write path separately in isolation.

```python
update_user_email(user_id, "new@example.com")
# read through whatever path is cached, not directly from the DB
profile = get_user_profile_cached(user_id)
assert profile["email"] == "new@example.com"
```

If that test passes trivially every time, it's worth also testing the cache's TTL-expiry path specifically (does stale data get served correctly during the window before a write, then correctly invalidated by the write, then correctly repopulated on the next read) and the multi-instance case if the app runs multiple servers each with a local in-memory cache — a write on instance A invalidating only instance A's local cache while instance B keeps serving stale data is a very common real bug, and it's invisible in any single-instance test setup, which is exactly why it slips past a lot of test suites until it shows up as a confusing 'works on my machine but users report stale data in prod' report.

Question 48

How do you avoid false positives in visual regression tests caused by font rendering or anti-aliasing differences?

Accepted Answer

Naive pixel-by-pixel screenshot diffing flags any difference, including ones a human wouldn't perceive as a bug at all — font hinting/anti-aliasing rendering a few pixels differently between a local machine and a CI container, a slightly different font version installed, or sub-pixel rounding differences between browser versions. Left unaddressed, this makes a visual regression suite fail on nearly every run for reasons unrelated to any real UI change, which quickly trains the team to ignore its failures — the exact outcome the suite was built to prevent.

The fix has a few layers: run visual tests in a consistent, pinned environment (a specific Docker image with fixed fonts and browser version, not 'whatever's installed on this CI runner today') so the baseline and the comparison run under identical rendering conditions; use perceptual diffing rather than exact pixel match (tools like Applitools and Percy compute a structural/perceptual similarity rather than flagging any byte difference, tolerating imperceptible anti-aliasing noise); and explicitly mask or exclude regions expected to change between runs — timestamps, ad content, user-specific avatars, animated elements — rather than screenshotting the whole page and hoping nothing dynamic is in frame.

A concrete setup: toHaveScreenshot(name, { maxDiffPixelRatio: 0.01, mask: [page.locator('.timestamp')] }) tolerates 1% pixel difference and explicitly excludes a known-dynamic element, which turns a flaky always-red visual suite into one whose failures are actually worth looking at.

Question 49

What is consumer-driven contract testing and why does it matter for independently-deployed microservices?

Accepted Answer

Consumer-driven contract testing flips the usual direction of contract definition: instead of the provider (the API team) publishing a spec and consumers hoping their assumptions match it, each consumer defines exactly the interactions it actually needs from the provider, and those consumer-authored contracts become the source of truth the provider's CI verifies against. This matters specifically in a microservices architecture with many independently-deployed services, because it directly answers the question 'can we deploy this provider change safely' without needing every consumer's full application running in an integration environment.

The mechanism (as with Pact, the most common implementation): a consumer team's test suite generates a contract file describing every interaction it depends on; that file is published to a shared broker; the provider's CI pipeline, on every build, pulls every registered consumer's contract and replays each interaction against the real provider code, failing the build if any consumer's expectation is no longer met.

The alternative — a shared, provider-authored OpenAPI spec everyone tests against — doesn't catch the same class of bug: a provider can honor its own spec exactly and still break a real consumer that depended on an undocumented but real behavior (a field always being present in practice, even if the spec marked it optional). Consumer-driven contracts catch that because they encode what consumers actually rely on, not just what the provider promises on paper — at the cost of needing broker infrastructure and consumer teams disciplined enough to keep their contracts current as their actual usage evolves.

Question 50

How would you design chaos/fault-injection tests for a microservices system?

Accepted Answer

Chaos testing deliberately injects real failures into a running system — killing a service instance, adding artificial network latency, dropping a percentage of requests, taking a dependency offline — to verify the system degrades the way its design claims it will, rather than trusting that claim untested. The premise is that a distributed system's failure modes (timeouts, retries, cascading overload, partial outages) are the hardest bugs to find any other way, because they only appear under conditions a normal functional test never creates.

A concrete chaos experiment for a microservices order flow: use a tool like Chaos Mesh, Gremlin, or a simple network-latency injection (tc on Linux, or a service mesh's fault-injection config) to add 5 seconds of latency to calls from the order service to the inventory service, then verify the order service's timeout and circuit breaker actually trip as configured instead of the request hanging indefinitely and exhausting the order service's own thread pool — which, without a working circuit breaker, can cascade into the order service itself becoming unresponsive to unrelated requests, taking down more of the system than the original injected failure.

The discipline that makes this safe rather than reckless is running it first in a controlled staging environment with a clear hypothesis ('the circuit breaker trips within 3 seconds and the order service stays responsive for unrelated requests') and a rollback plan, before ever running anything similar against production (which some mature organizations do deliberately, called chaos engineering in production, but only after the staging version has been validated repeatedly and blast radius is tightly scoped).

Question 51

How do you test multi-tenant SaaS applications for data isolation between tenants?

Accepted Answer

In a multi-tenant SaaS app, the single highest-severity class of bug is one tenant seeing another tenant's data — a query missing a WHERE tenant_id = ? clause, a cache key that doesn't include the tenant id, or an authorization check that verifies the user is logged in but not that the specific resource they're requesting belongs to their own tenant. Testing for this needs to be deliberate and adversarial, because a functional test written from a single tenant's perspective will never accidentally surface a cross-tenant leak.

The core test pattern: create two tenants with known, distinct data, authenticate as a user in tenant A, and attempt to access a specific resource by ID that actually belongs to tenant B — the correct behavior is a 404 (not found, so the resource's existence isn't leaked to unauthorized tenants) rather than a 403 (which confirms the ID is valid, a smaller but real information leak) or, worst case, a 200 returning tenant B's actual data.

```python
tenant_a_user = create_user(tenant='A')
tenant_b_order = create_order(tenant='B')
resp = api_client.get(f"/orders/{tenant_b_order.id}", auth=tenant_a_user)
assert resp.status_code == 404  # not 200, not even 403
```

This needs to be tested at every layer that touches tenant-scoped data, not just the top-level API — a background job, a search index, an export/reporting feature, and any caching layer are common places this check gets forgotten because they were built later than the original API and didn't go through the same tenant-isolation review; a thorough audit greps every database query in the codebase for tenant-scoped tables and confirms each one filters by tenant id rather than assuming a single review of the main CRUD endpoints covers the whole surface.

QA Automation Interview Questions & Answers

Ready to practice these live?