QA & SDET Interview Help — AI for Test Design, Automation & Coding

1. Test case design & "how would you test X"

The signature question: "how would you test a login form / an elevator / a vending machine?" Graded on coverage and method — functional, boundary, negative, edge, security, and usability. The AI surfaces a structured checklist (equivalence partitioning, boundary values) so you don't miss a category.

2. Automation & API testing

Selenium/Playwright structure (Page Object Model, waits, flakiness), API testing (status codes, schema, auth, idempotency), and the test pyramid (unit > integration > E2E). The AI writes clean automation snippets and flags flakiness causes.

3. SDET coding

SDETs code: DS&A plus "write a function and its tests." The AI returns a working solution and a thorough test set (happy path, edges, errors) — exactly what SDET interviewers want to see.

1. "Explain the test pyramid."

A broad base of fast, isolated unit tests, a thinner layer of integration tests, and a small cap of slow end-to-end (E2E) tests. The shape keeps suites fast and stable; an inverted pyramid (too many E2E) is flaky and slow, which is the trap interviewers probe.

2. "When do you choose manual testing over automation?"

Automate stable, repetitive, regression-prone paths where the ROI compounds. Keep humans on exploratory, usability, and one-off or rapidly-changing flows where scripting cost outweighs the benefit. The signal is judgment, not "automate everything."

3. "Design test cases for this input — how do you pick values?"

Use equivalence partitioning to group inputs that behave the same, then boundary value analysis to test the edges (min, min−1, max, max+1). It maximizes defect-finding coverage with the fewest cases — name both techniques explicitly.

4. "Which automation tools have you used and why?"

Talk through Selenium, Playwright, or Cypress for browser/UI automation, and structure (Page Object Model, explicit waits over sleeps). Choose based on language fit, parallelism, and built-in waiting — show you pick tools for reasons, not hype.

5. "How would you test a REST API?"

Validate status codes, response schema and body, authentication and authorization, error handling, and idempotency of safe methods — using Postman or code-level REST assertions. Mention negative and boundary cases on the payload, not just the happy path.

6. "What's the difference between regression, smoke, and sanity testing?"

Smoke is a shallow build-acceptance check ("does it boot?"); sanity narrowly verifies a specific fix or area; regression broadly re-checks that existing functionality still works after a change. Knowing when each runs in the pipeline is the real signal.

7. "A test is flaky — how do you handle it, and what makes a good bug report?"

For flakiness, hunt the root cause (timing, test interdependence, shared state) with explicit waits and isolation rather than blind retries. A good bug report has clear repro steps, expected vs actual, environment, severity/priority, and evidence (logs, screenshots) — and respects the bug lifecycle from New to Closed.