Scenario Based Testing Interview Questions and Answers (2026)

Clarify: Which Safari version + macOS/iOS combo? Desktop or mobile Safari? All users or one? First occurrence tied to a deploy?

Investigate: Reproduce on the exact Safari version. Open Web Inspector → Console for CSP violations, missing polyfills, or unsupported syntax (Safari lags Chrome on new JS/CSS APIs). Check the Network tab for blocked requests, cookie SameSite quirks, and third-party script failures. Diff the user-agent-specific code paths in the front-end bundle.

Act: File a bug with the browser matrix table, a screen recording, the failing console line, and the source-map location. Set severity based on Safari's traffic share for the product (often 15–25% for consumer apps in India, 40%+ in the US). Add a Playwright cross-browser test in CI pinned to WebKit so the regression doesn't recur.

Not necessarily a product bug — most likely a process defect. Verify three things before filing: (1) the deployed build number on QA vs prod (compare /version or CI build metadata), (2) the CDN cache TTL on the logo asset (long TTLs mean old logos stay for hours after deploy), (3) any feature flag or environment-specific asset override.

If QA is behind because the pipeline promoted prod first (common with hotfix branches), log it as a process defect against the release pipeline, not a product bug against the app. Always compare build numbers before filing a UI regression — this single habit prevents 20–30% of false-positive UI bugs on most teams.

Assess: severity (does it break flow?), priority (who's affected?), reachability (what percent of users hit it?), and workaround (is there one?). Never sit on a defect silently because the sprint is closing.

Decide by data, not urgency: if it's P1/P2 or affects paid users, escalate to the PO in writing for a same-day hotfix decision. If it's cosmetic, low-traffic, and has a workaround, log it with full evidence (screenshot, browser matrix, repro steps) and let the PO groom it into the next sprint. Sprint deadlines don't change severity — the PO owns the ship/no-ship call, your job is to surface the risk with enough data that the decision is informed.

Reproduce with Chrome DevTools → Performance panel — record while opening the dropdown, capture Long Tasks, layout thrashing, and memory heap growth. Also measure Time-to-Interactive (TTI) and Total Blocking Time (TBT).

File as a performance defect (high severity because it freezes the tab, medium priority because opening the dropdown is a user-initiated action). Attach metrics: initial render time (probably 3–10 seconds), TTI, peak heap. Recommend fixes: virtualised list (react-window, TanStack Virtual), server-side search with type-ahead, or paginated fetching. Add a regression test that fails if render exceeds 500 ms with 10 K items — otherwise the fix rots the next time someone refactors the component.

Yes — file as a UI/visual defect against the story's acceptance criteria. Attach side-by-side screenshots with pixel measurements (use PixelSnap or the browser's ruler). Severity depends on user impact: spacing off by 2 px is low, wrong CTA colour on a paid button is high, missing accessibility contrast is a compliance-blocking severity-1.

Before filing, confirm the Figma version matches the story — designers frequently update Figma after handoff without updating the story link. If Figma drifted, the bug belongs against the design-vs-story mismatch, not the implementation. Add a visual regression test (Percy, Chromatic, Playwright screenshot) so future drift is caught in CI.

Never close as 'not reproducible' without server-side traces. Ask the user for device, OS, browser, network (Wi-Fi vs 4G), time-of-day, geo-region, and a screen recording. Their session ID or user ID is gold.

Pull their session from the APM (Datadog, New Relic, Sentry Performance) for the reported time window. Look at server-side p95/p99 latency for their region, DB slow queries, third-party API calls, and any cache misses. Reproduce with throttled network + CPU in DevTools (Fast 3G + 4× CPU slowdown replicates most mid-range Android experiences). If you still can't reproduce but the APM shows a real regression, file it against the slow endpoint — the user's report is the signal, not the whole diagnosis.

File a defect — a successful 2xx response must either carry the expected schema or explicitly return 204 No Content. Attach the request (headers + body), the actual response, and the expected schema from the API contract (OpenAPI / Swagger).

Add a contract test that asserts the response matches the schema, and add a Postman/RestAssured/Pact test that fails if a 200 comes back with an empty body. Root cause is usually a serialization bug (null object silently serialised as {}) or a race condition where the DB fetch resolves after the response is sent. The bug is worth escalating because empty 200s corrupt downstream systems that trust the status code without inspecting the body.

Use provider sandboxes and their documented test cards — Stripe 4242 4242 4242 4242, Razorpay sandbox tokens, PayPal sandbox accounts, Adyen test cards. Never test with production credentials, even 'just once'.

Cover the full matrix: valid card success, expired card, insufficient funds, CVC fail, 3-D Secure challenge (Stripe 4000 0025 0000 3155), network timeout mid-authorization, idempotency-key replay (send the same key twice, assert only one charge), full refund, partial refund, chargeback webhook, currency conversion, and webhook retries. Also test the failure paths on your side: what happens if the payment succeeds but the webhook is lost? Idempotent order creation and a reconciliation job are what prevent double-charging in production.

Stub the downstream at the network layer with WireMock, MSW, Playwright page.route, or a service-virtualisation tool. Simulate three failure modes: 5xx responses, connection timeouts, and slow responses (10–30 s). Assert your app shows a graceful error (not a blank white screen or infinite spinner), retries with exponential backoff, does not corrupt local state, and surfaces a user-friendly message.

Add a chaos test in staging that kills the dependency for 30 seconds and asserts your circuit breaker opens, degraded mode kicks in, and metrics/alerts fire. In production, run monthly game-days where you deliberately fail a dependency for 5 minutes with the on-call team watching — most teams learn their runbooks are wrong the hard way.

Clarify: Same user or many users? Same time-of-day? First occurrence after a deploy? Same client (web/mobile/API)?

Investigate: Capture the failing request's Authorization header and decode the JWT — check the exp claim against server clock. Common root causes: token expiring mid-request, clock skew between client and server, race between token-refresh and in-flight request, session invalidated by a parallel logout, or a load-balanced auth server with an out-of-sync secret. Log every 401 with request-id + user-id so you can grep production.

Act: Fix at the client (proactive refresh 60 s before expiry, queue in-flight requests during refresh) or at the server (widen clock-skew tolerance to ±60 s, propagate the secret via config-reload). Add a test that runs 100 concurrent requests across a token boundary and asserts zero 401s.

Read the documented limit (e.g., 100 requests/minute per user). Send N+1 requests in a burst — assert the (N+1)th response returns 429 Too Many Requests with a Retry-After header naming the seconds to wait. Test window reset: wait Retry-After, retry, assert 200.

Cover per-user vs per-IP vs per-API-key limits separately. Test the interaction: does a burst from user A also throttle user B on the same IP? Does the rate limiter reset cleanly on a rolling window vs a fixed window? For distributed rate limiters (Redis-backed), test failover: kill the Redis primary mid-burst and assert the limiter fails closed (better to reject than to let through). Finally, add a negative test: your monitoring should alert on sustained 429s because a healthy API shouldn't be throttling real users at scale.

No — webhooks are contractually at-least-once delivery for every mature provider (Stripe, GitHub, Twilio, Razorpay). The bug is if your consumer processes the same event twice.

Test idempotency directly: send the same webhook payload twice with the same event ID and assert the DB state changes only once — no duplicate row, no double charge, no double email. Root cause fixes: dedupe by event ID in a processed_events table with a unique index, or use the provider's idempotency key. File a defect against the consumer, not the provider. Also test out-of-order delivery: webhooks for event 2 can arrive before event 1, so your consumer must be tolerant of ordering.

Depends on the product's compliance profile — GDPR (EU), CCPA (California), DPDP (India). Verify five things: (1) PII fields are soft-deleted immediately and a purge job hard-deletes on the documented retention window (typically 30–90 days), (2) audit logs are retained per regulatory requirement (7 years for finance), (3) related rows — orders, comments, uploaded files — are anonymised or cascaded correctly, (4) the user cannot log in with old credentials or password-reset links, (5) the email is released for re-registration only per policy (some products block re-registration for 90 days to prevent takeover attacks).

Test the purge job actually runs on the schedule — many bugs hide in cron jobs that silently fail. File a defect with high severity for any PII that survives the retention window.

Send classic payloads (' OR 1=1--, '; DROP TABLE users;--, UNION SELECT ...) in every input field, URL parameter, header, cookie, and JSON body value. Cover both string and numeric contexts.

Verify three defences: (1) DB error messages don't leak to the UI (a generic 500 is fine; a Postgres syntax error is a critical info-leak), (2) queries are parameterised — read the code, not just black-box test, (3) an ORM or query builder is used consistently. Automate with OWASP ZAP or sqlmap as part of the security pipeline. Also test second-order injection: the payload is stored in the DB, then rendered into another query later — many WAFs miss this.

Depends entirely on product policy — this is a clarify-first question. If concurrent sessions are allowed (Netflix, Gmail, GitHub), assert all 5 work simultaneously without state corruption. If limited to N (banking apps often limit to 1–2), assert the (N+1)th device kicks the oldest session and shows a clear 'You've been signed out because you signed in on another device' message.

Also test: session hijack via stolen token — the server must invalidate on logout-everywhere. Session fixation — a new session ID must issue on login. Idle timeout vs absolute timeout. And for financial products, verify that a second device sign-in triggers an email notification to the account owner — an unnoticed second session is how takeover attacks scale.

Never seed via the UI — it's slow, brittle, and doesn't cover edge distributions. Use SQL scripts, DB snapshots (pg_dump restore), a data-factory API, or synthetic data tools (Faker, Mockaroo, Snowflake's synthetic-data service).

Cover five data volumes: empty state, small (10s of rows), medium (1 K), large (100 K), max (1 M+). Test pagination boundaries at each. Reset between tests via transaction rollback (fast) or a nightly restore (isolated) — never manual cleanup, which drifts. For query-performance testing, seed with realistic distributions (Zipf, not uniform) — a table where 90% of orders belong to 10 customers exposes N+1 bugs that a uniform seed hides.

Yes — high-severity data-integrity defect. Attach both call sites' code paths, the inputs, and the two outputs.

Root cause is almost always mixed rounding modes (HALF_UP vs HALF_EVEN, aka banker's rounding) or float vs decimal arithmetic. JavaScript's Number and Java's double are IEEE-754 floats — 0.1 + 0.2 = 0.30000000000000004. Fix requires a single shared rounding utility library (BigDecimal in Java, decimal.js in JS) plus regression tests with edge inputs: 0.5, -0.5, 0.05, ₹0.005, very large numbers, currency-specific rules (JPY has no decimals, KWD has three). Rounding bugs compound — a ₹0.01 discrepancy per transaction becomes crores across a payments platform.

Yes — information-leak security defect (OWASP A05: Security Misconfiguration). Verify in dev, staging, and prod. Assign high priority even if it looks cosmetic — attackers use column names to map schema and craft injection attacks.

Fix: the user sees a generic message (Something went wrong. Please try again.) with a correlation ID; the full stack trace is logged server-side only. Add an automated test that scrapes error responses for regex patterns (column|table|SQL|stack trace|line d+) and fails the build if any match. Also audit 4xx/5xx pages, WAF error pages, and admin panels — they leak too.

Reproduce inside the same Docker image CI uses — this alone solves 60% of these bugs. Then diff the environment: env vars, browser version, screen resolution, timezone, locale, parallel-worker count, headless vs headed, GPU acceleration, and mounted volumes.

Capture CI evidence: Playwright trace, Selenium video, browser console logs, network HAR. Save them as CI artifacts every run, not just on failure — the failure you need to debug is often the one before the current one. Never mark a test 'flaky' before you've reproduced the failure at least once with evidence. 'Flaky' is a diagnosis, not an excuse — every flaky label needs an owner and a due date.

Measure first — per-test wall time, sorted descending. 20% of tests usually eat 80% of runtime.

Attack in this order: (1) Parallelise across shards — Playwright --shard=1/6, TestNG parallel classes, pytest-xdist, GitHub Actions matrix. Aim for 4–8× parallelism. (2) Move low-value UI tests down to the API layer — a login should be tested once via UI and 200× via API. (3) Cache dependencies and browser binaries between runs (GitHub Actions actions/cache). (4) Reset state via API/DB, not UI — DELETE FROM orders WHERE user_id = ? is 100× faster than clicking through a delete flow. (5) Quarantine chronically slow tests (>2 minutes) into a nightly suite. Realistic outcome: 90 min → 12–15 min with 6 shards, API-layer refactor, and cached deps.

Diagnose first — never blanket-retry. Auto-retry hides real regressions and rots the suite over 6 months.

Categorise the root cause: (1) Timing — fix with explicit web-first assertions (expect(locator).toBeVisible()) or polling, never sleep(). (2) Test data — isolate per-run with unique IDs / faker seeds, don't share fixtures across tests. (3) Order-dependence — add proper setup/teardown, run tests in random order in CI to catch this. (4) Infrastructure — CI runner CPU/network flakes, containers dying. Fix if it recurs.

If root cause is unknown after 30 minutes of investigation, quarantine into a separate suite with an owner name and a due date (max 2 weeks) — not indefinitely. Track flaky-test count as a team-health metric and refuse to accept new tests into the suite while quarantine > 5.

Test four states, not two. (1) Flag ON: full happy path + edge cases work. (2) Flag OFF: legacy behaviour intact — this is the rollback path and is often ignored until an incident. (3) Flag at 50% rollout: half of test users see new, half see old, with no cross-contamination in shared caches or downstream systems. (4) Flag flipped mid-session: a user who loaded the old code shouldn't crash when the server switches them mid-request.

Automate with a config-override fixture that pins the flag per test (LaunchDarkly, Unleash, Statsig all support this). Also test the kill-switch: flipping OFF in production should propagate in under 60 s. And test targeting rules: 'only users in India on iOS' should not accidentally include Android users.

Coverage gap — this is the most important scenario to answer well because it's the whole point of QA.

Common root causes: (1) test data doesn't match prod scale (100 rows in test, 10 M in prod), (2) environment-only feature flags off in CI but on in prod, (3) external dependencies stubbed in CI but real in prod, (4) a flaky test silently retried and hid the regression, (5) CI tests one region/language/currency but the bug is region-specific, (6) CI runs against a mock DB with different collation or timezone, (7) the specific browser/device combination isn't in the CI matrix.

Run a blameless post-mortem within 48 hours. Add the missing test at the layer it would have caught (unit / integration / E2E / production monitoring — 'test in production' with feature flags and canaries is a valid answer for some bugs). Audit the CI matrix quarterly against actual prod traffic distribution.

Don't run 100 combinations on every PR — that's cost and time you don't have. Build a device matrix by traffic share, not exhaustively.

Tier the matrix: Tier 1 (top 5 by traffic — Chrome/Windows, Chrome/Android, Safari/iOS, Chrome/Mac, Edge/Windows) runs on every PR in ~5 min. Tier 2 (next 15 by traffic) runs on merge to main in ~15 min. Tier 3 (long tail, 80+ combinations) runs nightly and on release candidates in cloud device farms (BrowserStack, Sauce Labs, LambdaTest, AWS Device Farm). Run smoke tests on all 100; full regression only on Tier 1–2. Post-release, monitor real-user metrics (Datadog RUM, Sentry) to catch anything the matrix missed.

Never a flat no — always quantify the risk.

Say something like: 'Skipping full regression on module X exposes flows A, B, and C. Historical defect escape rate on those flows is 12%, and the last three defects there took an average of 4 days to hotfix. Here's a middle path — I can run targeted regression on the modules that changed plus P0 flows in 90 minutes, versus the full 4-hour suite. Alternatively we ship behind a feature flag and expand rollout after 24 hours of clean metrics.' Then let the PO make the call with data.

Document the decision in the release notes with your name and theirs. If the PO overrides and it breaks in prod, you have receipts; if it ships clean, you've built trust that you can accelerate when needed.

Escalate privately first, not in Slack. Most merges-without-sign-off are process ignorance or deadline panic, not malice. A 1:1 message asking 'Hey, was there a reason the QA check was skipped on PR #482?' surfaces the actual reason 90% of the time.

Systemic fix beats individual blame: (1) reiterate the Definition of Done in the next standup or sprint retro, (2) add a branch-protection rule on the target repo requiring at least one approval from the QA team's GitHub group, (3) enforce a required CI job that fails without a QA label, (4) track 'merged-without-QA' as a team-health metric (not to blame individuals, to show trend). Frame it as protecting the developer from a bad-merge post-mortem, not as gatekeeping.

Not your call alone — ship/no-ship decisions belong to the PO, release manager, or engineering lead depending on org structure. Your job as QA is to present the data cleanly.

For each of the two defects, document: severity, priority, reachability (what % of users hit it), workaround (is there one? one-click or ten-click?), blast radius (does one bad flow break others?), and time-to-fix estimate. Then recommend one of three paths: (1) hotfix and re-cut the release, (2) rollback to the last stable build, (3) ship-with-known-issue with a support runbook, in-app warning, or feature flag off. Whatever the group decides, log it in the release notes and add both defects to the top of the next sprint. This scenario is asked to test whether you understand that QA informs the decision, not owns it.

Ask for their reasoning first, in a way that assumes competence: 'Help me understand — what surfaced this approach for you?' Nine times out of ten, experience has revealed a constraint you missed (a past incident, a compliance requirement, a team-capacity reality).

If you still disagree after hearing them out, don't argue seniority — propose a spike. 'Let's try both approaches on the next small feature — measure defect-find rate, runtime, maintenance cost after 4 weeks — and let the data pick.' Data-driven disagreement builds credibility fast, and even if your approach loses, you've shown senior judgment. Never take the disagreement to Slack channels or over their manager's head — that burns political capital for a technical debate.

Own it — don't hide behind 'devs missed it in code review'. Ownership at senior levels is measured by how you respond to escapes, not by how many you prevented.

Run a blameless post-mortem within 48 hours. Answer five questions: (1) What was the root cause? (2) What test would have caught it — unit, integration, E2E, monitoring, chaos? (3) Why did we not have that test? (4) What's the systemic fix (add the test, change a process, close a coverage gap)? (5) What's the customer-facing remediation (hotfix window, refund, apology)? Share the write-up with the team as a learning, not a blame doc. Track escape rate per quarter to show improvement — senior interviewers care more about the trend than the specific incident.

Reverse-engineer, but do it visibly so no one calls you slow.

(1) 15-minute chat with the developer — ask what the feature does, who uses it, what could go wrong. (2) Explore the UI and inspect API traffic (browser DevTools, Charles Proxy) to build a mental model. (3) Write down your assumptions and share them back on Slack for confirmation — this converts ambiguity into a documented contract in under an hour. (4) Draft a lightweight test charter (feature, personas, risks, in-scope, out-of-scope, coverage plan) — one page, not ten. (5) Run exploratory sessions with session-based test management (SBTM) — log findings, questions, and new charters as you go.

Refuse to 'test blind' without at least the assumption-doc step. Testing without a shared model of the feature is how P1 escapes happen in the first place.

Clarify: percent of user base on that combo, which app version, which feature, first crash after which deploy?

Investigate: pull the Firebase Crashlytics / Sentry stack trace filtered by OS + device. Look for OOM kills (Android LowMemoryKiller signal), missing runtime permissions, or 64-bit vs 32-bit ABI issues. Reproduce on the exact device (Android emulator with capped RAM, or a physical device from BrowserStack App Live). Check whether recent dependency updates dropped support for Android 8 (API 26) or increased minimum RAM.

Act: if the affected user base is > 2%, hotfix with a memory-optimisation or targeted rollback. If < 0.5%, add a graceful-degradation code path (feature-disable + user message) and bump the minimum supported OS in the next major release. Add a low-memory automated test in the mobile CI matrix so future regressions surface pre-release.

Cover all four states of the app: foreground, background, killed, and locked screen. Notifications behave differently in each — a killed iOS app can't run JS handlers, an Android app in Doze mode delays delivery.

Test: (1) delivery latency (p50 and p99, from send to device receipt), (2) deep-linking — tapping the notification opens the correct in-app screen with correct params, (3) badge count updates and resets, (4) grouped/summary notifications on Android, (5) rich media (images, actions), (6) permission-denied state (user rejected notifications — app shouldn't crash and should show an opt-in prompt later), (7) DND / Focus mode, (8) international characters and RTL languages, (9) silent notifications for background sync. Use the FCM/APNs test consoles for direct send, plus a staging environment where you can trigger real production-shaped payloads.

Reproduce with network throttling (Chrome DevTools Network → Slow 3G/Fast 3G, Charles Proxy throttling, or Android Studio's network emulation). Common root causes: (1) uploads timing out because of aggressive server-side timeouts, (2) API calls exceeding the mobile carrier's MTU or being blocked by carrier-side deep packet inspection, (3) IPv6-only carriers when the backend only supports IPv4, (4) HTTP/2 vs HTTP/1.1 differences, (5) certificate pinning failing because the carrier proxy injects certs, (6) large images downloaded on cellular when they should be gated behind a Wi-Fi-only preference.

File the defect with request/response captured via Charles or mitmproxy, note the network type, and add a network-degradation test to your mobile CI matrix. Also test airplane-mode toggling mid-request — the retry logic often has bugs no one sees on Wi-Fi.

Use sandbox accounts — Apple TestFlight sandbox users and Google Play internal-testing tracks with license testers. Never test IAP with production accounts.

Cover: successful purchase, cancelled purchase, purchase interrupted (kill app mid-transaction), restore purchases on new device, subscription renewal, subscription cancellation, grace period (Apple 16 days, Google varies), billing retry, refund, family sharing (iOS), price-change confirmation prompts, promo codes, and receipt-validation on your server. The receipt-validation step is where 80% of IAP bugs hide — always verify on your backend, never trust the client, and handle Apple's sandbox-vs-prod endpoint switch correctly (a sandbox receipt sent to the prod endpoint returns 21007). Add automated tests for receipt-parsing edge cases, but the full purchase flow is manual + charter-based.

Confirm the iOS 15 traffic share — if it's < 3% and dropping, coordinate with product about deprecation. If it's meaningful (still common in emerging markets and enterprise-managed devices), file it.

Root causes are usually: (1) SwiftUI APIs that shipped in iOS 16+ used without @available checks, (2) safe-area or Dynamic Type differences, (3) Auto Layout constraint priorities that render differently on older UIKit versions, (4) SF Symbols added in newer iOS versions falling back to nothing. Fix with backward-compatible APIs, @available guards, or an OS-versioned code path. Add iOS 15 to the CI simulator matrix so regressions are caught pre-release. Push for a documented minimum-supported-iOS policy — 'latest minus two majors' is the industry norm.

Clarify: which deploy exactly, which regions, is p50 also affected or only p95, error rate change?

Investigate: diff the deploy commits (usually 2–20 changes). Check DB slow-query logs for the search query — did the deploy add a WHERE clause without an index? Check APM flame graphs for the hot path. Look at cache hit rate (Redis, CDN) — a stale cache key invalidation can 10× DB load. Verify DB connection pool saturation and lock contention. If it's a search service (Elasticsearch, OpenSearch), check shard health, JVM heap, and query complexity.

Act: if user-facing severity is high, rollback the deploy immediately — you can root-cause in staging. If low severity, add the missing DB index in a follow-up PR, add a performance regression test that fails the build if p95 exceeds 500 ms, and add an alert on p95 latency so the next regression pages the on-call team in minutes, not hours.

Start from real numbers, not guesses. Pull last year's peak RPS, unique users, session duration, and cart size from analytics. Model this year's expected traffic: baseline × marketing multiplier × new-market growth × safety margin (typically 2–3×).

Design three test profiles: (1) soak test — 100% expected load for 4 hours to catch memory leaks and connection-pool exhaustion, (2) spike test — 0 to peak in 60 seconds to catch autoscaling delays, (3) stress test — ramp until failure to find the breaking point. Use realistic user journeys (browse → search → add-to-cart → checkout → payment), not synthetic single-endpoint hits — real users hit caches differently. Run against a production-mirror environment, not shared staging. Coordinate with SRE for autoscaling headroom, DB read-replica count, CDN warm-up, and payment-provider rate limits (Stripe, Razorpay have per-account RPS caps that surprise teams). Add a game-day 2 weeks before Black Friday to rehearse the incident-response runbook.

Test three layers: browser cache, CDN, and application/DB cache.

(1) Cache hits: repeat the same request, assert the response time drops and the response headers include X-Cache: HIT or equivalent. (2) Cache misses: change a query param or bust the cache key, assert freshness. (3) Cache invalidation: mutate the underlying data via API and assert the cache serves fresh content within the documented TTL, not after. (4) Cache poisoning: send a request with a manipulated Host or X-Forwarded-* header and assert the CDN doesn't cache the poisoned response for other users. (5) Stampede protection: simulate 100 concurrent misses on the same key and assert only one backend call fires (request coalescing / singleflight). Caching bugs are among the highest-impact scenarios in senior interviews because they combine correctness, performance, and security.

Pull the top-N queries by total time from pg_stat_statements or the RDS Performance Insights top-queries tab. That's your test target list — most DB CPU issues are 3–5 queries eating 80% of cycles.

For each hot query, test: (1) EXPLAIN ANALYZE on production-shaped data — is there a missing index, a full table scan, or a bad join order? (2) Load test with realistic concurrency — how does p95 latency curve as connections increase? (3) Cache candidacy — can this query be materialised, memoised, or moved to a read replica? (4) Query-plan regression — the same query can flip plans as data grows; add a plan-stability check. Also test the failure modes: connection pool exhaustion, replica lag under write pressure, and vacuum/analyze storms. File follow-ups against product for any query that scales super-linearly with data volume.

Take a heap snapshot in Chrome DevTools → Memory, use the app for 5–10 minutes, take another snapshot, diff them. Growing detached DOM nodes, event listeners, or closures across snapshots is a leak.

Automate with Puppeteer or Playwright + page.metrics() or process.memoryUsage() in the CI environment — run the target flow 100 times in a loop and assert heap growth stays under a threshold (e.g., 20 MB). Common leak sources: uncleaned event listeners, timers not cleared on unmount, growing arrays in a global store, third-party analytics scripts, cached DOM references in React refs, and WebSocket subscriptions that outlive components. On the server side, run soak tests for 4+ hours and monitor RSS/heap in APM — Node.js and JVM leaks compound slowly and only surface after hours.

Test at every layer — this is the classic test-pyramid scenario.

(1) Unit tests in each service for pure logic. (2) Contract tests between A↔B and B↔C using Pact or Spring Cloud Contract — the provider verifies against the consumer's expected schema, so a breaking change fails the provider's CI before it reaches production. (3) Integration tests per service, stubbing its downstream (WireMock, Testcontainers). (4) End-to-end tests only for the top 10 critical user journeys — the whole A→B→C chain live, but few tests. (5) Production monitoring via distributed tracing (OpenTelemetry, Jaeger) so cross-service latency and error rates are visible.

The interviewer is checking whether you know contract testing exists — most candidates over-invest in slow, flaky end-to-end tests and under-invest in contract tests, which are the correct tool for cross-service compatibility.

Test region-specific behaviour, cross-region behaviour, and failover behaviour separately.

(1) Region-specific: latency from each region to its local endpoint, DNS geo-routing (Route 53 / CloudFront), data-residency compliance (EU data stays in EU), region-specific feature flags. (2) Cross-region: replication lag between primary and replica DBs, eventual consistency in DynamoDB global tables, S3 cross-region replication, and cross-region API calls that shouldn't happen (a Mumbai user's request hitting a Virginia DB is a bug). (3) Failover: kill the primary region in a game-day and assert DNS failover completes within RTO, data loss stays within RPO, and the runbook actually works. Automate synthetic monitors (CloudWatch Synthetics, Datadog Synthetics) from each region hitting the local endpoint every minute — most regional degradations show up here first.

This is more debugging than testing, but a senior QA is expected to reason about it.

Check the pod's exit code and restart reason: kubectl describe pod shows OOMKilled (memory limit too low), CrashLoopBackOff (app crashing on startup — read the logs), Liveness probe failure (probe too aggressive or app slow to start), or Evicted (node pressure). Common root causes: memory limit set below actual working set, liveness probe hits an endpoint that's slow during warmup (fix with a startup probe), config map / secret missing so app crashes on init, or a dependency (DB, Redis) unreachable so the readiness probe never turns green.

From a QA lens, add automated tests that: (1) hit the health endpoints during load, (2) verify graceful shutdown on SIGTERM within the terminationGracePeriodSeconds, (3) run chaos tests that kill random pods and assert user-facing SLOs stay green.

Test at the message contract, the consumer, and the end-to-end flow — but never test the queue itself (that's the platform's job).

(1) Message contract: schema tests (Avro/Protobuf/JSON Schema) fail the build on breaking changes. Use a schema registry (Confluent, AWS Glue) with backward-compatibility enforcement. (2) Consumer correctness: idempotency (same message processed twice = one state change), poison-pill handling (malformed message routed to DLQ, not looping), ordering (does your consumer require per-key ordering? Kafka partitioning must match), and offset commit semantics (at-least-once vs exactly-once). (3) End-to-end: produce a synthetic event, assert the downstream state (DB row, email sent, webhook fired) within the SLO. (4) Failure modes: consumer lag alerts, DLQ growth alerts, replay-from-timestamp runbook. Also test consumer scale-up: add 3× consumers and assert throughput scales without reprocessing or duplicate side effects.

Depends on the function's purpose. Clarify: is 30 s the platform default (Lambda's default is 3 s; API Gateway caps at 29 s) or a deliberate limit for a batch job? What's the p95 execution time — is 30 s a rare edge case or the norm?

If it's exceeding intended runtime, it's a bug. Investigate: (1) cold start amplifying a slow init, (2) downstream call blocking (DB, external API) without a timeout, (3) synchronous work that should be async — fan out to a queue, (4) data-volume regression (function was tested with 10 rows, prod hit 10 K). Fix by adding downstream timeouts (never leave HTTP clients on infinite wait), moving long jobs to Step Functions / SQS + a worker, or splitting the function.

Add tests: (1) load test with realistic input sizes, (2) alert on p95 duration crossing 50% of the timeout — you want to know before users do, (3) test the timeout path — does your caller retry safely or double-charge?

Use STAR here, not CIA, because this is behavioural.

Situation: 'Two days before our payments module release, I was doing exploratory testing on the refund flow.' Task: 'I noticed refunds over ₹50,000 rounded down by 1 rupee due to a float precision bug.' Action: 'I reproduced across 10 amounts, captured the exact code path with the dev, filed as P0, and proposed a targeted fix using BigDecimal. We agreed to a 2-day slip rather than ship with a data-integrity bug in payments.' Result: 'Release slipped by 2 days but zero customer-facing rupee discrepancies in the first quarter. I added a regression test for edge amounts and shared the pattern with the team, and we've since caught two more float bugs pre-release using it.'

Keep it under 3 minutes. End with the systemic improvement, not just the personal win.

Separate the technical problem from the interpersonal one.

First, audit your own bug reports for the last month — are they reproducible, clearly severity-tagged, with logs and evidence? Many 'ignored' bugs are actually 'unactionable'. Second, have a private 1:1 with the developer — 'I've noticed a few of my reports haven't been picked up. Is there a format or a severity threshold that would make them easier to act on?' Nine times out of ten, this surfaces a real gap (they need repro steps, or they think a bug is intended behaviour).

If the pattern continues after you've adjusted, escalate to your and their manager with data: 'These 8 bugs sat for > 30 days, here's the customer impact.' Frame it as team-process not personal complaint. Never Slack-shame or CC-the-VP as the first step — that burns the relationship you need to work with them tomorrow.

Don't propose 'let's add 500 tests' — that's how you get ignored. Show ROI in weeks, not quarters.

(1) Weeks 1–2: pick the single most business-critical flow (usually login + checkout). Write 5–10 API-layer tests using Playwright, RestAssured, or Postman. Wire them into CI so PRs run them. Show 'these 10 tests would have caught 3 of the last 5 escapes.' (2) Month 2: add a smoke suite (10–20 tests) that runs on every deploy, blocks bad releases. (3) Month 3: partner with 1 dev to shift some coverage to unit tests, freeing QA to focus on exploratory + integration. (4) Quarter 2: cross-browser + performance smoke, contract tests for critical APIs, quarantine list with owners.

Report defect escape rate before/after each phase. Executives fund what has visible ROI; abstract 'test coverage %' rarely lands.

STAR. Situation: 'A critical vendor API changed its response schema on a Friday evening, breaking our checkout flow. Full regression normally takes 4 hours; we had 90 minutes before the weekend traffic peak.' Task: 'Decide what to test and what to skip, then own the release.' Action: 'I mapped the schema diff to the 6 flows that used it, ran targeted API + E2E tests on those flows (35 minutes), spot-checked the top-5 traffic-share pages (20 minutes), and had one team member watch RUM dashboards during the deploy. I skipped mobile-app regression because the API layer was shared and iOS/Android would surface issues via the same monitors.' Result: 'Shipped on time, zero P1 escapes over the weekend. Wrote the runbook so the next vendor-schema-change incident is a 30-minute playbook, not a fire drill.'

The interviewer is checking whether you can prioritise risk under pressure and whether you build systems that outlast the incident.

Be specific — vague answers ('I read blogs') read as inauthentic.

Concrete answer: 'I set 30 minutes a day for one of three things — a hands-on lab (Playwright new features, k6 load tests, chaos engineering on a toy service), a real-world write-up (Google Testing Blog, Increment, Netflix TechBlog), or contributing to my team's testing tooling (last quarter I built an internal Playwright fixture library that cut our test-write time by 40%). I attend one QA conference per year (Selenium Conf, EuroSTAR, StarWest) and pick 2 talks to actually apply. I also run a monthly "bug of the month" session in my team where we deep-dive one production escape — I learn more from those than from any course.'

Interviewers grade this by whether your examples are recent (last 3 months), specific, and result-backed — not by the volume of what you list.

Assume good faith first — 'by design' is often true. Ask two questions: 'Which requirement or design doc calls out this behaviour?' and 'What does the user expect here based on the story's acceptance criteria?'

If a doc backs them up, close the bug and add a test that pins the intended behaviour so it doesn't regress. If no doc exists, escalate to the PO / designer with the ambiguity: 'The current behaviour is X, the story says Y, users in this session recording expected Z — which is intended?' Never argue design with the dev — arguments about intent belong to the PO. This scenario tests whether you can distinguish implementation defects (dev's decision) from design defects (PO's decision) and route each correctly.

Listen before acting. A new lead who ships a 90-day roadmap in week 1 loses the team's trust.

Week 1: 1:1s with every QA, key devs, PM, and the manager who hired you. Read the last 3 sprints' bug reports and the last 2 post-mortems. Shadow one release cycle end-to-end without changing anything. Week 2: map the current process — where do bugs escape, where does the pipeline stall, what tools are duct-taped together? Week 3: pick one high-impact, low-risk improvement to ship in the next sprint — usually reducing the smoke suite runtime, adding a missing critical-path test, or fixing a flaky-test alert that everyone ignores. Ship it with the team, not for them. Week 4: present a 90-day plan with 3 outcomes (measurable), 3 experiments, and 1 thing you'll stop doing — reviewed by the team before it goes up.

The interviewer is checking whether you understand that leadership starts with earning permission to change things.