The full QA spectrum kept deliberately separate: manual craft, automation engineering, and performance testing are different interviews with different rubrics.
18 published across 13 topics.
QA and testing fundamentals59 short answers on one page, for revising rather than studying.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.
Test case design, equivalence partitioning and boundary values, exploratory charters, and defect reporting.
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.
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.
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.
Auto-waiting, fixtures and isolation, network interception, tracing, and migration considerations.
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.
Contract and schema validation, auth handling, data setup and teardown, and REST Assured or Postman workflows.
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.
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.
Correlating client metrics with server, DB, and JVM evidence to locate a bottleneck rather than guess.
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.
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.
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.
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.
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.
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.