SDET Scenarios

Tell a specific automation war story you owned, the problem and its impact, why it was hard, how you investigated, the solution and technologies, the trade-offs, and the measurable improvement in flakiness, runtime, or scale, and what you learned.

A CI pipeline runs the suite on every commit, install dependencies, install browsers, run in parallel with per-environment config, collect screenshots, videos, and traces, publish a report, and notify on failure, with secrets injected from the platform's secret store and masked, never committed.

On a mass post-deploy failure, classify the failures by symptom using logs, traces, and health checks to distinguish a real product regression from a contract, locator, auth, data, or environment change, because assuming one root cause leads to the wrong action, crying wolf or missing a real defect.

Solve first-non-repeating-char with a count map, reverse a string with a two-pointer or index loop, dedupe arrays with a set and objects with a seen-by-key set, and second-highest salary with DENSE_RANK or a subquery, always stating complexity and edge cases, because the interviewer values your reasoning over the answer.

Common chaos experiments kill a pod to test failover, add network latency to test timeouts and retries, fill disk to test resource handling, simulate database failure to test fallback and recovery, and block a dependency to test circuit breakers, and in every case the system should degrade gracefully, not fail totally.

BDD describes behavior in plain Given-When-Then language that business, testers, and developers all share, then binds those scenarios to step definitions so they run as automated tests, using tools like Cucumber with Gherkin or JBehave in Java.

Chaos engineering deliberately injects controlled failures, killing servers, slowing networks, filling disks, to verify the system survives real-world faults gracefully, forming a hypothesis and observing steady state, popularized by Netflix's Chaos Monkey.

Code coverage measures how much code the tests execute, by line, branch, or path, and it is a useful signal of gaps, but one hundred percent is not the goal because coverage proves code ran, not that behavior was asserted, so focus on meaningful tests of the important, risky logic.

A stub returns preset values to control what the code sees, a mock also records calls so you can verify interactions, and you create them with Mockito for Java objects and WireMock for HTTP services.

TDD means write a failing test first, write just enough code to pass it, then refactor, repeating this Red-Green-Refactor loop, which catches bugs early, drives simpler testable design, and leaves tests that document the intended behavior.

TDD is developer-focused unit tests in code that drive implementation, BDD is business-focused behavior in plain Given-When-Then that drives acceptance, and you use them together, BDD for acceptance tests and TDD for the unit tests beneath.

Find duplicates with GROUP BY key HAVING COUNT greater than one, then delete the extras safely by keeping the MIN or MAX id via a self-join or a ROW_NUMBER CTE, always inside a transaction and after a backup.