Software testing and QA interviews cover testing fundamentals, test design techniques, automation tools and how you think about quality and risk. These questions suit manual testers, automation engineers and SDETs.
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Verification asks "are we building the product right?": checking work against specifications through reviews, walkthroughs and inspections, often without running the code. Validation asks "are we building the right product?": testing the working software against real user needs. Both are needed; a feature can match its specification perfectly and still not solve the user's problem.
Severity is how much a defect affects the system; priority is how urgently it should be fixed. They do not always match. A misspelled company name on the home page is low severity but high priority. A crash in a rarely used admin report is high severity but may be lower priority. Testers usually set severity, and the product owner or lead sets priority.
Smoke testing is a quick, broad check that a new build is stable enough to test at all. Sanity testing is a quick, narrow check that a specific fix or area works after a change. Regression testing re-runs a wider set of tests to make sure new changes have not broken existing features, and is the best candidate for automation.
A unique ID, a clear title, the linked requirement, preconditions, the test data, numbered steps, the expected result, and fields for the actual result and status. Priority helps decide what to run first. Good test cases are specific enough that anyone can run them and get the same result, and they cover one scenario each.
Applied problems, trade-offs and questions about your own projects.
Equivalence partitioning splits inputs into groups that the system should treat the same way and tests one value from each group, which reduces the number of tests. Boundary value analysis tests at the edges, where bugs cluster. For an age field accepting 18 to 60, I would test 17, 18, 19, 59, 60 and 61, plus one value from the middle and invalid types such as letters.
The pyramid recommends many fast, cheap unit tests at the bottom, fewer integration and API tests in the middle, and a small number of end-to-end UI tests at the top. This gives quick, reliable feedback. The anti-pattern is the "ice cream cone", relying mostly on slow, flaky UI tests, which makes the suite expensive to run and maintain.
I first confirm the flakiness by re-running and tracking failure rates, then find the cause. Common causes are timing (fixed by explicit or automatic waits instead of sleeps), shared or leftover test data, tests that depend on running order, and unstable environments or third-party services. I quarantine the test so it does not block releases, fix the root cause, and avoid hiding the problem with endless retries.
Selenium uses the WebDriver standard, supports many languages and browsers and is very mature, but needs more setup and explicit waits. Cypress runs inside the browser with JavaScript or TypeScript and has an excellent debugging experience, but historically had limits with multiple tabs and origins. Playwright supports Chromium, Firefox and WebKit, auto-waits, runs tests in parallel, handles multiple tabs well and offers several languages.
System design, deep internals, leadership and tough follow-ups.
I start with risks and scope. Unit tests cover amount calculations, rounding and currency handling. API tests cover success, failures, timeouts, duplicate submissions and idempotency, and refunds. Integration tests run against the payment gateway's sandbox, and end-to-end UI tests cover the main journeys. I add security checks (no card data in logs, PCI DSS requirements), performance tests for peak load, and monitoring after release.
I check status codes, response schema and data, headers, and behaviour with missing, expired or wrong-role tokens. I test invalid and boundary inputs, pagination, idempotency of PUT and DELETE, error messages and response times. Tools include Postman with Newman, REST Assured or Playwright's API testing, all run in CI. Between services, contract testing with a tool like Pact catches breaking changes early.
I first agree measurable goals, such as 95th-percentile response time under 500 ms at 1,000 concurrent users with under 1% errors. I model realistic user journeys and data, then run load, stress, soak (long-duration) and spike tests with JMeter, k6 or Gatling. I monitor server CPU, memory, database and network during the test, find the bottleneck, and re-test after each fix.
Shift-left means testing earlier in development, because defects are cheaper to fix the earlier they are found. In practice testers review requirements and designs, acceptance criteria are written before coding, developers write unit tests, static analysis and automated tests run in CI on every commit, and testers pair with developers during the sprint instead of waiting for a finished build.