The full QA spectrum kept deliberately separate: manual craft, automation engineering, and performance testing are different interviews with different rubrics.
36 published across 13 topics.
The test pyramid, black versus white box, severity versus priority, and the STLC vocabulary asked verbatim.
Work out what the test was actually asserting. If it pins behaviour a user depends on, the refactor changed behaviour and the test did its job; if it pins an implementation detail, it never had value and the failure is the cost of having written it that way.
Split the input domain into classes the code should treat identically, then test each class once and probe every boundary at the smallest step the field allows. Exhaustive testing is ruled out by combinatorics, which is why a coverage number is a claim about your model rather than about correctness.
Line coverage tells you which lines executed while the tests ran, which is not the same as which behaviours were verified: a test with no assertions still counts, and the interesting information is in the uncovered lines and in whether the tests would fail if the code were wrong.
Test case design, equivalence partitioning and boundary values, exploratory charters, and defect reporting.
Work in timeboxed charters rather than ad-hoc clicking: build a model of the feature from the code, the UI and whoever asked for it, name your oracles, attack the highest-risk areas first, and record findings and open questions as you go.
A report gets fixed when a developer can reproduce it without asking you anything: exact build, preconditions, numbered steps with real data, expected versus actual with the source of the expectation, and evidence attached.
Risk-based scoping, entry and exit criteria, estimation, traceability, and release sign-off judgement.
Automate what runs often, has a deterministic oracle, sits on a stable interface, and guards an expensive escaped bug. Push each check to the cheapest layer that can still fail meaningfully, treat flakiness as a defect rather than noise, and keep human time for exploratory testing, not scripted regression.
A clean track record is evidence about the old system's operating envelope, not about yours, so the strategy must surface the assumptions the component inherits, test it against the new envelope rather than trusting its history, and state which inherited assumptions are going untested.
Buy most of your confidence from fast isolated tests and little from slow end-to-end ones, because cost and flakiness rise as you climb. It is a claim about where risk lives, so a system whose risk sits in integration - a thin service over a database - correctly has a different shape.
What to automate and what not to, page objects, locator strategy, waits, and flakiness root causes.
A failure has to be diagnosable from its artefacts alone, because nobody can attach a debugger to a CI run: that means assertions that report the compared values, a message naming the business expectation, and captured evidence of the state at the moment of failure. Use this automation answer to show the decision, trade-off, and evidence rather than a memorised definition.
Quarantine and measure before fixing: keep per-test pass history so you can rank offenders and restore a trustworthy signal, then work the root-cause families one at a time. Retries belong in a narrow, logged, budgeted policy, because a blanket rerun turns a real product race condition into a green build.
A page object owns locators and the mechanics of interacting with a screen, and nothing else. Assertions, test data and workflow belong in the test, because the moment a page object asserts, the test's intent stops being readable from the test.
Driver architecture, synchronisation, framework design, grid and parallel execution, and reporting.
An implicit wait retries element location globally and nothing else; an explicit wait polls for a named condition and is the only tool that can wait for state. Stale references happen because a WebElement points at one DOM node that no longer exists, so the cure is re-locating rather than re-waiting.
Give each thread its own WebDriver session held in thread-local storage, remove every other piece of shared mutable state including test data and static fields, size the run to the grid's slots so requests queue rather than time out, and quit every session even on abnormal exit.
Auto-waiting, fixtures and isolation, network interception, tracing, and migration considerations.
Playwright actionability checks pass on server-rendered markup because the element is attached, visible, stable and enabled - none of which imply React has attached its listener. The click lands on inert HTML, so this is a race with hydration, not a timing problem. Wait on a readiness signal the app exposes deliberately.
Auto-waiting runs actionability checks before an action and retries assertions that are bound to a locator, so it removes timing races but never wrongness. Playwright drives the browser from a separate Node process.
Create the data through the API, restore an authenticated session from saved cookies and storage rather than logging in each time, and stub only the third parties you do not own, so each test drives the UI solely for the behaviour it is actually asserting.
Contract and schema validation, auth handling, data setup and teardown, and REST Assured or Postman workflows.
The contract captured the shape the consumer sends, not the rules the provider enforces. Optionality lived in the schema while the real requirement lived in provider validation, and no recorded example ever omitted the field. Contract tests only verify interactions they contain, so add the negative example and verify against real code.
Make every test create its own preconditions under a generated identity, scope each assertion to records that test owns, and treat cleanup as housekeeping rather than as the isolation mechanism, because teardown does not run when a test is killed.
Contract testing has each side verify itself against a shared description of the interaction, so consumer expectations are checked against the provider's real behaviour without the two ever running together. Mismatches surface in each team's own pipeline, not in a shared environment days later. It also connects api testing to the point an interviewer is testing.
Separate contract tests, which check shape and backwards compatibility cheaply, from integration tests that exercise real behaviour across real dependencies. Make every test create and own its data so the suite is re-runnable, spend most of your negative cases on authorisation and malformed input.
Load versus stress versus soak, workload modelling, JMeter and k6 and Gatling, and reading percentiles honestly.
Derive the mix, arrival pattern, and data distribution from production telemetry rather than assumptions, size concurrency from throughput and think time instead of guessing a user count, and report percentiles with error rates so the result means something.
Ramp load steadily past the target until throughput stops rising, record the knee and the collapse point separately, and watch bounded resources such as threads, file descriptors and connection pools, because the first hard limit is often not request rate at all.
Correlating client metrics with server, DB, and JVM evidence to locate a bottleneck rather than guess.
A launch is a transient, not a steady state: users arrive in the same minutes, against cold caches, mostly doing sign-up writes and retrying as it slows. A typical load test ramps gently, uses a closed workload, stubs third parties, runs a smaller fleet and measures in ways that hide stalls.
Stop the bleeding first by rolling back or disabling the suspect path, then find the cause by profiling the saturated process rather than by reading the diff, because a profile names the hot function directly while forty commits offer forty plausible stories. Use this performance analysis answer to show the decision, trade-off, and evidence rather than a memorised definition.
Read the throughput curve first: if throughput has flattened while latency rises, you are queueing behind a saturated resource, and the job is to find which one by walking utilisation and saturation from the load generator through the app tier to the database.
Device and OS fragmentation, Appium, real device versus emulator trade-offs, and mobile-specific defects.
Treat each launch state as its own test case, because each delivers the link through a different code path. Cold start runs splash, auth and initialisation that can drop the link, and on iOS delivers it in the scene's connection options, not the continue callback. Test cold, warm, restored and logged-out.
Pick devices from your own analytics rather than from a market-share article, spread the choice across OS version, screen size, memory class and manufacturer skin, and keep real hardware for anything involving the camera, sensors, radios, battery or vendor-modified behaviour.
Mobile adds four things a browser mostly hides: a device and OS matrix you cannot enumerate, a network that degrades and disappears mid-request, an operating system that interrupts and revokes permissions at will, and hardware behaviour that emulators cannot reproduce.
The DSA and code-design questions asked of automation engineers, plus framework build-out exercises.
A correct wait helper tracks a wall-clock deadline rather than an attempt count, treats an exception from the condition as a not-yet rather than a failure, returns the condition's value, and reports the last observed value or error when it gives up.
Group lines by a normalised path so that /orders/1 and /orders/2 collapse to one endpoint, compute the percentile by nearest rank on the sorted latencies, and count the lines you could not parse instead of silently dropping them.
Gating pipelines, test data management, parallelisation, environment strategy, and quality metrics.
Configuration, feature flags, content and reference data, schema migrations, infrastructure definitions and dependency updates all change production behaviour, and most organisations ship them through channels that were designed to be faster than the release pipeline.
Give the blocking stage a fixed time budget and put only fast, deterministic, developer-diagnosable tests inside it; everything slow, environment-dependent or exploratory moves to a scheduled run with a named owner. Use this ci cd answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects test automation to the point an interviewer is testing.
Profile before cutting: suite time concentrates in a few tests, and the cause is usually repeated setup or real waiting rather than work. Parallelise what is independent, move the slow and rarely-failing out of the merge path, and treat deleting redundant tests as legitimate.
Judgement situations: no requirements, no time, a flaky suite, a production escape, a resistant dev team.
In a debugging exercise with planted breaks, get a feedback loop before you read closely. Ask what correct behaviour is, whether you can run it and its tests, and what counts as done, then let failing behaviour point you to the code. Small planted changes hide from reading and show up when the code runs.
Reconstruct the defect's exact path, then ask at which layer a test could have seen it and why none did, distinguishing a missing case from a whole condition your environments cannot reproduce, and fix the class rather than adding one test for this instance.
Re-plan the remaining time against risk rather than against the test-case order, then report coverage as an explicit list of what was tested, what failed and what was never opened. The recommendation is yours; the decision to ship belongs to whoever carries the business consequence.