Microsoft SDET (Software Development Engineer in Test) - Junior Level Interview Preparation Guide

Direct answer

For interdependent integration tests that need deterministic, reproducible ordering while still allowing safe parallelism, the core technique is making each test step explicitly idempotent and defining clear transactional (or compensating) boundaries around any shared state, so tests that don't actually depend on each other can run in parallel while tests that share ordering requirements are executed within an explicit, declared dependency graph rather than relying on incidental execution order.

Structured elaboration

• Idempotency: design test steps so that re-running a step (due to a retry after a transient failure) produces the same end state rather than double-applying an effect; this is what makes safe automatic retries possible without corrupting shared state.
• Transactional boundaries: where tests share a resource (a database, a queue), define an explicit boundary around what state each test run owns, so parallel tests don't observe each other's in-flight changes; this often means test-scoped transactions that roll back at the end of a test, or resource partitioning (each test gets its own logical slice) rather than a single shared mutable state everyone reads and writes.
• Dependency graphs for ordering: rather than relying on incidental file or execution order to imply "test B must run after test A," declare that dependency explicitly (a directed graph of test dependencies) so the test runner can safely parallelize everything that has no declared dependency while still enforcing correct ordering for what does.
• Handling non-deterministic third-party dependencies: for a dependency you don't control that itself introduces non-determinism (varying response timing, occasional transient errors), wrap it behind a retry-with-backoff and idempotency check at the boundary where your system calls it, so a real transient hiccup from that dependency doesn't manifest as nondeterministic test behavior; you can't make the dependency deterministic, but you can make your system's handling of its non-determinism deterministic.

Worked example

An order-fulfillment integration test suite declares an explicit graph: "provision-inventory" must complete before "place-order," which must complete before "process-payment," but "send-confirmation-email" and "update-analytics" have no ordering dependency on each other and can run in parallel once "process-payment" succeeds. Each step is written to be safely re-runnable (checking "has this already happened" before applying an effect), so a transient failure in "send-confirmation-email" can be retried without needing to redo "process-payment."

Trade-offs & pitfalls

The most common mistake is relying on incidental ordering (tests happen to pass because of the order a test runner historically executed them in) rather than an explicit, declared dependency graph; this works until someone reorders tests, parallelizes the suite, or the runner's default ordering changes, at which point tests that were never actually correctly isolated start failing unpredictably, often written off as "flaky" when the real cause is an undeclared ordering dependency.

Direct answer

I separate what's actually being transferred, the underlying principle, from what's incidental to the old context, the specific implementation and its defaults, and I re-verify the parts that depend on the new context's specifics rather than assuming a straight port. I check soundness by comparing the new result against an independent ground truth or the new domain's own baseline, not just against "it ran without error."

Structured elaboration

• Identify the transferable core versus the context-bound specifics. The underlying idea, an algorithm, a statistical method, a design pattern, usually carries over. The exact parameters, library defaults, and assumptions baked into the old context often don't, even when everything looks superficially the same.
• Watch for the mechanical trap. Reimplementing what looks like "the same" logic in a different toolchain can silently produce a different answer because of quiet differences in defaults: numeric precision, random seeds, how a library breaks ties, or off-by-one conventions that never mattered before because you never had to think about them.
• Watch for the conceptual trap. A method borrowed from a neighboring field brings assumptions baked into it, tuned for a particular scale, data distribution, or failure mode, that may not hold in the new one, and needs deliberate adapting rather than a straight relabel.
• Validate against something independent. A known-answer test case, an existing simpler baseline already trusted in the new domain, or a manual spot-check by someone who knows the new context well, so you're checking that the result is right, not just that it executed.
• Only trust the transfer once it holds up against the new domain's own baseline, measured on its own terms, not against the numbers you got in the old context.

Worked example

I ported a feature-engineering pipeline that had been prototyped in a small, single-machine data-analysis library over to a distributed processing toolchain meant to scale it up. I assumed the aggregation logic, grouping records and summing a value within each group, would produce identical output, since it was "the same" calculation. Before trusting it, I ran both versions on a fixed, unchanged sample and diffed the outputs directly rather than assuming a match. They disagreed slightly, and it turned out the distributed version summed floating-point numbers in a different order across its workers, which changed the result by a tiny but real amount for a few groups, and it also handled missing values differently by default than the original library had. Because I'd deliberately checked instead of trusting the port, I caught both before the new pipeline went anywhere near a real report, fixed the null handling to match intentionally, and documented the small floating-point discrepancy as expected and acceptable rather than a bug, since I understood its actual cause instead of just noticing a mismatch.

Trade-offs and pitfalls

The clearest trap is assuming "same logic, different tool" automatically means "same answer," when defaults and edge-case handling frequently differ between implementations in ways that only show up once you actually check. A close second is skipping validation because the transfer feels obvious or low-risk, which is exactly when a quiet discrepancy is most likely to go unnoticed. And carrying an assumption over from the source domain without re-examining whether it still holds, rather than deliberately adapting it, is how a borrowed method ends up quietly wrong in its new setting.

Direct answer: The three policies trade release safety for developer velocity along a spectrum, immediate quarantine favors velocity and visibility, fail-on-flake favors correctness at the cost of blocking unrelated work, and skip-with-annotation is the cheapest but weakest on both signal and accountability, so the right choice depends on how much a company can tolerate either blocked releases or silently degraded coverage.

Structured elaboration

Recommendations by company context:

• Startup: skip-with-annotation or lightweight quarantine, moving fast matters more than perfect suite hygiene at this stage, and the team is small enough that "someone remembers" can substitute for formal SLA enforcement, at least temporarily. The risk is this doesn't scale past a certain team size without becoming quarantine's downside (an ever-growing, unmanaged skip list).
• Mid-size company: quarantine with a strict, enforced SLA is usually the best balance, enough scale that fail-on-flake's blocking cost becomes prohibitive, but enough process maturity to sustain an ownership/SLA system without it collapsing into skip-with-annotation's laissez-faire failure mode.
• Regulated enterprise: fail-on-flake, or quarantine with MUCH stricter oversight (a compliance-reviewed, audited quarantine list rather than a lightweight engineering process), since the cost of a real regression shipping (potential compliance or safety consequences) generally outweighs the velocity cost of blocking merges, and audit requirements often demand exactly the kind of accountability trail fail-on-flake naturally produces.

Worked example: a regulated financial-services company evaluated skip-with-annotation early on and found, in an internal audit eight months later, over 200 silently-skipped tests with no owner and no record of why they were skipped, several covering critical calculation paths, exactly the failure mode the policy comparison above predicts. They moved to fail-on-flake for anything touching a regulated calculation path, and quarantine-with-audit-trail for everything else, accepting the higher operational cost of faster triage capacity as the price of the compliance posture they needed.

Trade-offs & pitfalls: it's tempting to pick one policy for the whole organization, but the worked example shows the more common real-world pattern is a HYBRID, different policies for different risk tiers of test (a payments-critical test gets fail-on-flake; a low-risk internal-tool test gets quarantine or skip). A pure one-size-fits-all policy either over-constrains low-risk work (unnecessary fail-on-flake friction everywhere) or under-constrains high-risk work (skip-with-annotation on something that actually matters).

Direct answer

The global session cache is a dict that stores every session ever seen and never evicts, so the process's memory footprint grows monotonically with the total number of unique sessions handled over its entire lifetime, not with the number of CURRENTLY active sessions, which is why it only becomes visible as "unbounded growth over days," not immediately. The fix is a bounded cache with an explicit eviction policy (most simply, LRU) so memory usage stays proportional to a chosen ceiling, not to total historical traffic.

Structured elaboration

The buggy pattern is deceptively simple to write and easy to miss in review: a module-level (or otherwise long-lived) dict that's written to on every request and never has anything removed. Each individual dict[key] = value assignment looks completely ordinary; the bug is entirely in the ABSENCE of any corresponding removal, which doesn't show up as a red flag in a normal code read the way an obviously wrong line would.

Worked example

# BUGGY: module-level dict that never evicts
_session_cache_buggy = {}
def handle_request_buggy(session_id, payload):
    _session_cache_buggy[session_id] = payload  # never removed
    return len(_session_cache_buggy)

# FIXED: bounded LRU-style cache
from collections import OrderedDict
class BoundedSessionCache:
    def __init__(self, max_size=1000):
        self.max_size = max_size
        self._data = OrderedDict()
    def set(self, key, value):
        if key in self._data:
            self._data.move_to_end(key)
        self._data[key] = value
        if len(self._data) > self.max_size:
            self._data.popitem(last=False)  # evict oldest
    def __len__(self):
        return len(self._data)

bounded = BoundedSessionCache(max_size=1000)
def handle_request_fixed(session_id, payload):
    bounded.set(session_id, payload)
    return len(bounded)

Simulating 5,000 distinct sessions against both:

buggy cache size after 5000 requests: 5000 (unbounded growth)
fixed cache size after 5000 requests: 1000 (capped at max_size)

The buggy version's size tracks the total number of distinct sessions ever seen, growing without bound as more unique sessions arrive over the service's uptime; the fixed version stays exactly at its configured ceiling regardless of how many distinct sessions have passed through, evicting the least-recently-used entry once the cap is reached.

Detecting and mitigating in production without an immediate code deployment:

• Detection: a process's resident memory (RSS) growing roughly linearly over days with no corresponding growth in request rate or working-set size is the classic signature; correlating RSS growth against the count of unique keys in the suspect structure (if instrumented, or inferable from a heap snapshot) confirms it directly rather than just suspecting it.
• Operational mitigation without a code change: a scheduled restart of the affected process on a cadence shorter than the time it takes to reach a problematic memory footprint buys time for a proper fix to be developed and reviewed, at the cost of losing all cached sessions on each restart (acceptable for a CACHE, specifically because losing cached data is a performance regression, not a correctness bug, unlike losing genuinely authoritative state).
• Detecting in production going forward: export the cache's current size as a metric, and alert on it growing past a sane threshold, so this class of bug is caught by monitoring within hours rather than discovered days later via a host running low on memory.

Trade-offs and pitfalls

An LRU eviction policy is the right default for a session cache specifically because "most recently used" is generally the best available proxy for "most likely to be used again soon" without deeper application-specific knowledge, but it's worth confirming that assumption holds for the actual access pattern (a workload where recency ISN'T predictive of reuse would want a different eviction strategy, like a TTL-based (time-to-live, meaning a fixed expiry duration set when the entry is cached) expiry keyed to the session's own actual validity window, which may be the more semantically correct choice for session data specifically, since a session that's still logged in but idle for exactly the LRU-eviction-worthy duration might still be a session the fix should keep alive based on its expiry, not its recency).

What it is (SDET perspective)
A test data and environment strategy defines how we create, provision, isolate and clean up test data and test environments so automated tests run reliably, quickly and reflect real-world scenarios without exposing sensitive data.

Primary goals

• Ensure test reliability and repeatability
• Protect production data (privacy/compliance)
• Provide production-like coverage for realistic validation
• Minimize environment provisioning time and cost
• Enable parallel test execution with isolation

Critical components

• Data generation: synthetic and anonymized production-like datasets; data factories, schema-aware generators, and recorded fixtures for edge cases.
• Data provisioning: automated seeding via scripts/fixtures, DB snapshots, or feature-flagged dataset versions; integrate with CI/CD using Infrastructure-as-Code (Terraform, Helm).
• Isolation: ephemeral environments (containers/namespaces), per-branch databases, test tenancy, and transaction-scoped rollbacks to avoid cross-test pollution.
• Cleanup: automated teardown hooks, database truncation or snapshot restore, and scheduled reclamation of stale environments/resources.

3 measurable success metrics

1. Environment Provisioning Time — median time from pipeline start to ready test environment (target: < X minutes).
2. Test Flakiness Rate — % of CI runs failing non-deterministically due to data/env issues (target: < Y%).
3. Data-coverage & freshness — % of critical user flows covered by production-like datasets and age of seeded data (target: ≥ Z% coverage, data < N days old).

These ensure strategy is secure, fast and improves test signal as an SDET.

Situation & goal (one line)
As an SDET I’d keep staging functionally and behaviorally close to production for high-risk systems while reducing overall infra spend.

Prioritization — which systems to mirror

• Rank by risk: customer impact, frequency, recent incidents, deployment velocity.
• Use data: incident/bug heatmaps, business KPIs (payments, auth, checkout), and code churn to pick top 10–20% of services that cause ~80% of risk.

Which parity aspects to replicate

• Critical: production-like data schemas, API contracts, auth flows, third‑party integration behavior, latency profiles, and deployment topology for services in-scope.
• Noncritical: exact hardware counts, full data volume.

Cost-saving techniques that preserve fidelity

1. Representative sampling: use production-derived sampled datasets (anonymized) that preserve key distributions and edge-case records rather than full DB copies.
2. Service virtualization & contract testing: mock third-party endpoints with configurable latency/error injections; combine with consumer-driven contract tests to ensure compatibility.
3. Scaled-down topologies with traffic replay: run scaled replicas (fewer nodes) but replay real production traffic patterns and peak loads using load generators to validate behavior.
4. Spot/preemptible instances + autoscale groups for ephemeral test runs; tear down after CI.
5. Canary + staging-in-prod for last-mile verification: deploy to isolated namespaces in production with synthetic traffic for highest-risk flows.

Measurement & governance

• Track test coverage for prioritized systems, measure defect escape rate, and review cost vs. risk quarterly.

Situation: In staging an intermittent automated E2E test failed 3x in last 10 runs; failure is non-deterministic.

Task: Report a clear, actionable bug so the developer can triage and fix root cause.

Action — Issue contents (what I fill):

• Title: concise and specific, e.g. “Intermittent: Checkout E2E fails at payment authorization — 3/10 runs (staging)”
• Environment: staging cluster name, build/tag, service versions, DB snapshot id, browser/driver versions, OS, region, network conditions
• CI details: CI job name, run id, timestamp, commit SHA, pipeline URL
• Steps to reproduce: exact automated test name, test file, deterministic reproduction attempts I ran (commands), timing or race conditions observed
• Actual vs expected: error message, stack trace, HTTP responses, assertion details
• Frequency / pattern: counts, % of failures, time windows
• Attachments:
  • CI artifacts (full failing log), zipped screenshots, network HAR, webdriver logs, server-side logs correlated by timestamp, core dumps if any
  • Small repro script or minimal test harness and exact CLI to run locally
  • Video/gif of failure when available
• Labels/fields: severity (initial: P2 intermittent flakiness), component, regression? (yes/no), flaky-test flag

Assignee & Priority:

• Assign to owning service team or on-call developer; if unknown, assign to platform triage or QA lead and tag primary owners
• Initial priority: P2 (test is flaky in staging but not blocking production); escalate to P1 if it fails CI gating for releases or reproducible locally

Result / Follow-up:

• Offer next steps: I will add a temporary test skip with link to ticket if it blocks release, provide a reproducible artifact, and schedule a pairing session to debug timing/race conditions
• Add watchers: QA, dev lead, SRE
• Update the ticket with progress and close only after root cause and test fix verified across 20+ consecutive runs

I communicate clearly, attach evidence, propose mitigation, and own follow-up until verified.

Direct answer

Choosing an automation tool should be driven specifically by how it affects the automate-versus-manual calculus for your team, not by feature checklists alone: a tool that is flaky-resistant, easy to debug, and quick for the team to ramp up on effectively lowers the cost side of the automation decision, making more tests worth automating than a tool that is powerful on paper but slow and frustrating to use day to day.

Structured elaboration

Attributes that most affect the automate-versus-manual decision, and why:

• Flaky resilience: how well the tool handles timing, waits, and dynamic content out of the box. A tool prone to flakiness raises the effective cost of every test built on it, since flaky tests erode trust and require ongoing maintenance, directly shrinking the set of tests worth automating.
• Debugging ergonomics: how easy it is to understand why a test failed (clear error messages, screenshots or traces on failure, a good local debugging experience). Poor debugging ergonomics increases the time cost of maintaining the suite, again raising the bar for what is worth automating.
• Cross-browser or cross-platform support: relevant specifically when the product needs to be verified across multiple browsers or platforms; a tool with weak support here either limits coverage or forces expensive workarounds.
• Team ramp-up time: how quickly the team's current skill level can become productive with the tool. A powerful but steep-learning-curve tool can slow automation adoption enough that, in practice, less gets automated than with a simpler tool the team can use effectively from week one.

Scoring approach: rate each candidate tool on these attributes on a simple scale, weighted by what matters most for your specific context (a small team with limited prior automation experience should weight ramp-up time heavily; a team supporting many browser and device combinations should weight cross-platform support heavily), and choose the tool with the best fit for your actual constraints rather than the most feature-complete option in the abstract. Framework choice for a narrower context, such as picking a testing framework for a React front-end specifically, follows the same underlying attributes, just narrowed to what matters for that stack: developer experience (does it fit how the team already writes React and JSX), CI integration (does it run cleanly and quickly in the existing pipeline), debugging ergonomics, and execution speed, weighted the same way based on team context.

Worked example

Comparing four options for a team automating a web application's UI, scored 1-5 (flaky resilience, debugging ergonomics, cross-browser support, ramp-up time for a team with moderate prior experience): Selenium (the classic WebDriver-based standard), Playwright (a modern framework with built-in auto-waiting), Cypress (a modern, JavaScript-native framework with built-in retry-ability), and a generic record-playback commercial tool.

Playwright scores highest overall specifically because its built-in auto-waiting directly reduces flakiness (a common source of maintenance cost with Selenium's more manual, explicit-wait-driven approach) and its trace-viewer debugging tooling is strong. Cypress scores close behind, with similarly strong flaky-resilience and debugging (its time-travel debugger is a real strength) but historically narrower cross-browser coverage (strong on Chromium-family browsers and Firefox, with WebKit support less mature) than either Playwright or Selenium. Selenium, despite lagging on flaky-resilience and ramp-up, scores highest on cross-browser support given its status as the long-established, broadly-implemented WebDriver standard across nearly every browser and language binding. For a team without dedicated cross-browser needs beyond the two or three most-used browsers, this trade-off favors Playwright; a team with a hard requirement for broad legacy browser or device coverage might weight cross-browser support more heavily and choose Selenium instead.

Trade-offs and pitfalls

The most common mistake is choosing a tool based on a feature checklist or industry popularity without weighting the attributes against the team's actual constraints, ending up with a technically capable tool the team struggles to use effectively, which in practice reduces how much gets automated rather than increasing it. The second mistake is ignoring ramp-up time as a "soft" factor; for a team early in its automation journey, ramp-up time can matter more than any other single attribute, since a tool nobody can use productively automates nothing regardless of its ceiling.

Direct answer
Floating-point numbers cannot exactly represent most decimal fractions (0.1 in binary floating point is a repeating fraction, just as 1/3 is in decimal), so comparing floats with strict equality (==) is unreliable; the fix is to compare within a tolerance, using a RELATIVE tolerance for large-magnitude values and an ABSOLUTE tolerance as a floor for values near zero, since either one alone fails in a different regime.

Structured elaboration and worked example (executed)

import math

def approx_equal(a, b, rel_tol=1e-9, abs_tol=1e-12):
    return math.isclose(a, b, rel_tol=rel_tol, abs_tol=abs_tol)

print("0.1 + 0.2 == 0.3 ->", 0.1 + 0.2 == 0.3)
print("0.1 + 0.2 =", repr(0.1 + 0.2))
print("approx_equal(0.1+0.2, 0.3) ->", approx_equal(0.1+0.2, 0.3))

Running this:

0.1 + 0.2 == 0.3 -> False
0.1 + 0.2 = 0.30000000000000004
approx_equal(0.1+0.2, 0.3) -> True

The strict-equality check is False even though the values are 'the same' for any practical purpose, because 0.1 and 0.2 cannot be represented exactly in binary floating point and their sum accumulates a tiny representation error.

Why relative tolerance alone fails near zero (executed)

a, b = 1e-300, 2e-300
print("math.isclose(a,b) default (rel only) ->", math.isclose(a, b))
print("math.isclose(a,b, abs_tol=1e-12) ->", math.isclose(a, b, abs_tol=1e-12))

Actual output:

math.isclose(a,b) default (rel only) -> False
math.isclose(a,b, abs_tol=1e-12) -> True

Two numbers that are both astronomically small but differ by a factor of 2 (1e-300 vs 2e-300) fail a relative-tolerance-only check, correctly by relative-difference logic, but this is almost always NOT what a test author actually wants: near zero, tiny absolute differences are usually noise, not a meaningful failure, which is why an absolute tolerance floor is needed as a companion check.

Why absolute tolerance alone fails for large numbers (executed)

c, d = 1e15, 1e15 + 100
print("abs diff:", abs(c - d))
print("relative diff:", abs(c - d) / max(abs(c), abs(d)))
print("math.isclose(c, d, rel_tol=1e-9) ->", math.isclose(c, d, rel_tol=1e-9))
print("abs(c-d) < 0.01 ->", abs(c - d) < 0.01)

Actual output:

abs diff: 100.0
relative diff: 9.999999999999e-14
math.isclose(c, d, rel_tol=1e-9) -> True
abs(c-d) < 0.01 -> False

An absolute-tolerance-only check (e.g. abs(a - b) < 0.01) would FAIL this case, flagging two numbers that differ by only about one part in ten trillion as unequal, purely because their magnitude is large; relative tolerance correctly recognizes this as an insignificant difference.

Code-level best practices

1. Use a library function (math.isclose in Python, assertAlmostEqual/an epsilon-based custom matcher elsewhere) rather than hand-rolling abs(a-b) < 0.0001, since a hardcoded absolute epsilon silently breaks at both extremes shown above.
2. Always pass BOTH rel_tol and abs_tol explicitly rather than relying on library defaults, and choose abs_tol based on the smallest meaningful magnitude your domain actually produces (a physics simulation and a financial percentage calculation have very different notions of 'negligible').
3. Never use exact equality on any float that has passed through at least one arithmetic operation (addition, division, an accumulated sum); exact equality is only safe for a float that was directly assigned a literal and never recomputed.

Trade-offs & pitfalls
A tolerance that is too loose can mask a genuine regression (a calculation that is now systematically off by a small but real amount gets silently accepted), while a tolerance that is too tight reintroduces flaky test failures from ordinary floating-point noise across platforms or numeric library versions; the tolerance value itself is a design decision that belongs in code review, not a default nobody revisits.

These names describe two different axes, not one: smoke, regression, integration, system, and user-acceptance tests describe SCOPE and PURPOSE within a release process, while functional versus non-functional describes WHAT KIND of requirement is being verified. A single test can sit at one point on each axis at once (for example, a load test is a non-functional system test).

The five scope/purpose types

Regression testing's specific effect on release velocity

A solid regression suite is what lets a team ship frequently without re-manually-verifying everything that already worked: automated regression tests reliably catch a bug like the double-discount example above, where a change to one part of the pricing logic silently breaks a previously-correct interaction, the moment it's introduced, rather than after a customer reports it. What automated regression tests do NOT reliably catch is a bug that requires actual human judgment to notice, such as a new promotional banner rendering with confusing or misleading wording, which passes every automated check while still being wrong; that class of issue needs manual exploratory testing precisely because "correctness" here is a judgment call, not a fixed assertion.

Keeping a growing regression suite fast and reliable

As a regression suite grows, two problems compound: it gets slower, and it accumulates flaky tests (ones that fail intermittently for reasons unrelated to real regressions). Keep it fast by running only the subset of regression tests relevant to changed code on every PR, reserving the full suite for a nightly run. Keep it reliable by treating a flaky regression test as a bug in the test itself, not background noise to tolerate: track a rerun rate per test, and either fix or quarantine (temporarily exclude with an owner assigned to repair it) any test whose failures don't correlate with real code changes, since an ignored flaky test trains the team to distrust the whole suite.

Functional versus non-functional testing, as a separate axis

Functional testing asks "does the checkout flow correctly compute the total and complete the order," a direct check against a stated feature requirement. Non-functional testing asks a different kind of question entirely: for the same checkout flow, does it perform well under load (performance), does it protect payment data appropriately (security), is it usable by someone unfamiliar with the site (usability), and can someone using a screen reader complete a purchase (accessibility). These four non-functional concerns should be prioritized before release based on business risk, not treated as equally weighted: for a payment flow specifically, security and performance under peak load typically deserve the most pre-release attention, since a failure there has the most severe and hardest-to-reverse consequences, while usability and accessibility issues, though real and important, are more often caught and improved iteratively after release without the same acute risk.

In a typical CI/CD pipeline, functional tests run continuously as part of the regular suite on every commit or pull request, since a functional regression, like the checkout total being computed incorrectly, is valuable to catch immediately. Non-functional tests usually run on a slower, scheduled cadence: a load test simulating peak Black Friday traffic against the checkout API is a concrete non-functional example, and it typically runs nightly or pre-release rather than blocking every commit, since it needs a longer, resource-heavy run that would slow down PR feedback if it gated every merge.

Trade-offs and pitfalls

The most common confusion is treating "system test" and "end-to-end test" as interchangeable; they overlap heavily in practice but system testing traditionally emphasizes validating the WHOLE application against its requirements as one unit (often owned by QA, closer to release), while end-to-end testing more narrowly emphasizes a specific user JOURNEY through the real stack (often automated and run continuously). Naming this distinction explicitly, rather than treating the terms as synonyms, is itself a signal of depth in this space.