Software Testing Interview Questions for 3 Years Experience (1970)

Structure: Requirement analysis (attend refinement, raise ambiguities, add acceptance criteria) → Test planning (risk-based prioritization, effort estimate, environment needs) → Test design (BVA, EP, decision tables, exploratory charters) → Execution (smoke → regression → new-feature) → Defect triage (daily standup with dev + PO) → UAT support → Test closure report (leakage %, coverage %, lessons learned). At 3 YOE you're expected to own a sprint's QA from refinement to closure.

Break the feature into user stories → identify test types needed (functional, API, integration, non-functional) → estimate per story using historical velocity (e.g., 20 test cases/day, 4 hours per automation script) → add 20–30% buffer for defect fix retest + regression + environment setup. Present in ideal hours, then convert to sprint capacity.

An RTM maps requirements → test cases → defects → business objectives. At 3 YOE you own the RTM for your module — it proves 100% coverage in audits, exposes untested requirements early, and simplifies impact analysis when a requirement changes mid-sprint.

Risk = Probability × Impact. Rank features by combined risk (payments, auth, and data-mutation flows are always high; static pages are low). Exhaustively test high-risk paths (BVA + EP + negative + non-functional); sample low-risk paths. Publish the risk matrix and get PO sign-off before sprint start.

Log the change in Jira with impact analysis (test cases affected, automation scripts to update, regression scope). Renegotiate scope with PO — either extend sprint or de-scope another item. Never absorb silently; documented change control protects the team.

Reach out in writing to PO/BA, refer to related user stories, competitor products, or industry standards. Write assumptions in the test plan, get sign-off, log clarifications in a shared doc. If still ambiguous, run exploratory charters and file clarification tickets — never guess silently, undocumented assumptions cause leakage.

Combine: (1) all planned test cases executed with pass rate ≥ target, (2) exit criteria met (zero P1, ≤ N P2 open), (3) risk-based coverage complete, (4) defect-arrival rate flattens over 2–3 days, (5) deadline reached with stakeholder sign-off. Never stop on a single metric.

Test strategy = project-agnostic policy (e.g., all APIs get contract tests, all UIs get smoke automation, all releases get performance regression). Test plan = project-specific execution of that strategy. At 3 YOE you often draft the test plan and get the QA lead to sign off.

Answer template: (1) tech stack — Selenium/Playwright + Java/Python/TS + TestNG/Pytest + Maven/Gradle. (2) pattern — POM + data-driven via CSV/Excel/JSON. (3) config — env-driven properties (dev/qa/staging/prod). (4) reporting — Allure + screenshots/videos on failure. (5) CI/CD — Jenkins/GitHub Actions with parallel execution. (6) coverage today vs baseline. Ready to sketch the folder structure on whiteboard.

POM — each page/component has a class exposing methods; hides locators; easy for teams new to automation. Screenplay — actors perform tasks, using abilities and asking questions; more testable, reads like BDD, but steeper learning curve. Enterprise Java teams still default to POM in 2026.

Trigger via GitHub Actions/Jenkins/GitLab CI. Pipeline: checkout → install deps → smoke on PR (5 min) → full regression on merge to main (30 min, parallel) → publish Allure report → notify Slack. Tag tests (@smoke, @regression, @perf) to control scope per stage. Fail the build on smoke failure only, warn on regression flake.

Root-cause first — is it wait, data, environment, timing, or third-party? Fix implicit waits with explicit conditions, replace unstable selectors with data-testid, isolate test data (unique UUID per run), mock third parties, stabilize animations. Retry 2× in CI (test.retries). If still flaky, quarantine + file a bug + own the fix within the sprint.

TestNG parallel="methods" with thread-count tuned to CI runner cores; ThreadLocal WebDriver for isolation; unique test data per thread; per-thread screenshot/log folders. Playwright: projects + workers. Cypress: parallelization via Dashboard. Always verify with -DthreadCount=10 locally before pushing.

Page Object, Singleton (driver factory), Factory (browser/env factory), Builder (test data builder), Strategy (data-source strategy), Fluent Interface (chainable page methods), Facade (business-flow wrapper).

Three tiers: (1) static data in JSON/CSV per env, (2) generated data with Faker/JavaFaker per test run, (3) API-seeded data (call setup APIs to create fixtures, tear down after). Never share mutable state across tests. Store secrets in Vault/Secrets Manager, never in Git.

Local: Selenium Grid 4 in Docker Compose or Playwright's built-in projects (chromium, firefox, webkit). Cloud: BrowserStack/Sauce Labs/LambdaTest for real device + version matrix. Run cross-browser as a nightly job, not per PR — too slow for fast feedback loops.

Postman collections + Newman in CI for smoke; RestAssured/Playwright APIRequestContext for regression. Validate: status code, response time, headers, body (JSON schema, JSONPath), error handling (4xx/5xx), auth/authz, idempotency, and rate limiting. Add contract tests (Pact) between consumer and provider services.

Contract testing (Pact, Spring Cloud Contract) validates that a consumer and provider agree on request/response shape. The provider runs consumer-generated contract tests in its pipeline. Use it in microservice architectures where E2E is too slow/flaky to gate every merge.

SQL validation post-transaction: run selects with joins and aggregate against expected values; verify referential integrity, constraints, triggers. Use snapshots for regression; rollback via transaction wrappers in test. Never write to prod. Tools: JDBC in RestAssured, Cypress DB tasks, pytest-postgres.

Service virtualization simulates unstable, expensive, or restricted third-party APIs (payment gateway, mainframe, partner service). Tools: WireMock, MockServer, Hoverfly. Use when the dependency is rate-limited, costs money per call, or unavailable in lower environments.

Consumer test: produce a test event, assert consumer processes it and writes expected DB state. Producer test: trigger the app action, assert the correct event lands on the topic with expected schema. Use ephemeral test topics + testcontainers for isolation.

JWT = header.payload.signature encoded token. In tests, decode payload (Base64), assert claims (sub, exp, roles). Never hardcode secrets in tests; use env-injected signing key. Test negative cases: expired token, tampered signature, missing scopes, wrong audience.

Pair on story acceptance criteria during refinement, review PRs for testability (data-testid, seams for mocking), pair on test-writing for critical logic, and co-own defect triage. Shift-left mindset — bugs caught in review or unit tests are 10× cheaper than in system testing.

Shift-Left — testing activities move earlier: static analysis in IDE, unit tests, contract tests, TDD, story-level acceptance in refinement. Shift-Right — testing in production: canary releases, feature flags, synthetic monitoring, chaos engineering, A/B tests.

Join war-room; help reproduce; capture logs, traces, DB state; identify why QA missed it (test gap? environment gap? unclear requirement?). File a follow-up test + regression + monitor alert as the RCA action item. Never blame; own the leakage.

Test both states (flag on / flag off) in the regression suite; parameterize via env var. Coordinate with dev on flag lifecycle — remove stale flags to prevent combinatorial explosion. Automate flag toggling in CI where the SDK allows.

Attend refinement + planning; challenge ambiguous acceptance criteria; suggest edge cases the PO may have missed; own the definition-of-done checklist for QA (functional + non-functional + accessibility). Publish sprint-end quality summary to keep PO informed.

DevOps = fast, safe, frequent releases via automation and shared ownership. Tester contribution: fast automated feedback in CI (smoke < 5 min), IaC-based test envs, observability of tests (report, trend, flake dashboard), and blameless post-mortems on leakage.

Test execution %, pass rate, defect leakage %, defect density, MTTD/MTTR, automation coverage, requirements coverage, flaky-test rate. Track trends over releases, not absolute numbers; publish monthly to leadership.

Defect leakage = defects that escape to a later stage or production. Formula: leaked ÷ total × 100. Target < 5%. Reduce by: RCA every leak, add regression tests, close environment/data gaps, tighten exit criteria, and shift-left with dev pairing on risky changes.

Acknowledge → reproduce → capture logs + DB state → escalate to on-call dev + PO → coordinate hotfix. Post-fix: add regression test, add monitor/alert, run RCA in blameless post-mortem, publish process improvement. Update the risk matrix so future releases test similar surfaces.

RCA uses techniques like 5 Whys or Fishbone to trace an incident to its root — not the symptom. Conduct: gather facts (logs, timeline, code diff), ask 5 Whys, agree on root cause, agree on preventive action (test, monitor, process), publish + track to closure. Blameless, always.

Reproduce with them in a call, share exact steps + env + video. If truly intermittent, add logging around suspected code paths and re-test. Capture the intermittent nature in the ticket (frequency, conditions). Escalate to eng lead if repeatedly closed as 'not reproducible' without RCA.

Parallelize (Grid/Playwright workers); tag and split (smoke vs full regression); test-impact analysis (run only tests affected by the diff); mock unstable third parties; move slow E2E to API/component level; prune duplicate tests quarterly.

Situation — payment webhook occasionally credited wrong amount in staging. Task — reproduce and root-cause before release. Action — added structured logs, ran 100 concurrent requests, isolated a race condition in webhook handler; paired with dev on a mutex fix; added regression + concurrency test. Result — released on-time, zero leakage, added standard concurrency test pattern for team.

STAR — the developer said an accessibility issue was low priority; I disagreed because it blocked screen-reader users on a payment flow. Shared WCAG 2.1 spec + screen-reader recording. Escalated to PO with impact estimate. Result — fix was pulled into the same release; team added accessibility to definition-of-done.

STAR — a currency conversion bug shipped to prod because the test data covered only USD. Owned the leakage in retro; added multi-currency test data provider; created currency regression pack; published RCA. Result — zero currency defects in next 6 releases; team adopted the data-provider pattern.

STAR — regression suite was 4 hours, blocking daily releases. Analyzed slow tests, moved 60% of UI tests to API level, parallelized remainder across 8 workers. Result — regression cut to 25 minutes, release frequency doubled, flake rate dropped from 8% to 2%.

STAR — junior struggled with bug reports being closed as 'insufficient info.' Pair-tested for a week, gave a bug-report template + video-recording tool, reviewed their first 10 reports. Result — junior's bug acceptance rate went from 40% to 90% in 3 weeks; template adopted team-wide.

Focus on: (1) breadth — manual + automation + API + basic performance, (2) ownership — you've run a sprint's QA end-to-end, (3) measurable impact — quantify one metric improvement, (4) alignment — one thing about the JD/company that excites you specifically. Keep to 60 seconds, follow with a question about their biggest QA pain point.