Software testing interview questions, with sample answers

Verification checks that we're building the product right: reviewing requirements, designs and code against the specification, often without running the software — reviews, walkthroughs and inspections. Validation checks that we're building the right product: running the software to confirm it meets the user's real needs, through functional, system and acceptance testing.

A short way to put it: verification asks "are we following the plan?", and validation asks "does it work for the user?"

Severity is how badly a defect affects the system; priority is how soon it needs to be fixed. The two are independent:

• High severity, low priority: the app crashes on a rarely used legacy report.
• Low severity, high priority: the company's name is misspelled on the home page.

Testers usually set severity, while priority is often decided with the product owner or lead, based on business impact.

Retesting means running a failed test again after a fix, to confirm that particular defect is resolved. Regression testing means re-running a wider set of tests to make sure the fix, or a new feature, hasn't broken anything that worked before.

Retesting is targeted at specific defects; regression is broad and repeated every release, which makes it the best candidate for automation.

Smoke testing is a quick, broad check on a new build that the most important functions work at all — signing in, the main pages, a key transaction — before anyone spends time on detailed testing. If it fails, the build goes back to the developers.

Sanity testing is a quick, narrow check after a small change or fix, confirming that one specific area behaves sensibly. Smoke testing asks "is this build stable enough to test?", and sanity testing asks "does this change make sense?"

In black-box testing, you test behaviour from the outside without looking at the code, designing tests from the requirements — with techniques like equivalence partitioning, boundary values and decision tables. In white-box testing, you design tests from the code's structure, aiming to cover its statements, branches and paths; developers usually do this through unit tests.

Grey-box testing mixes the two — for example, a tester checking the database after performing an action in the UI.

Both techniques reduce the number of test cases while keeping good coverage. Equivalence partitioning splits the inputs into groups that should behave the same way and tests one value from each group. Boundary value analysis tests at and just around the edges of those groups, where bugs tend to cluster.

For an age field that accepts 18 to 60: the partitions are below 18, 18 to 60, and above 60, so you might test 10, 35 and 70. The boundaries to test are 17, 18, 60 and 61.

The stages a defect moves through: New (logged), Assigned to a developer, Open (being worked on), Fixed, Retest by the tester, and then Closed if it passes or Reopened if it fails.

Other states depend on the team and the tool: Rejected (not a bug), Duplicate, Deferred (to be fixed in a later release) and Cannot reproduce.

A good test case is clear enough that anyone can run it and get the same result. It has an ID and a title, preconditions, test data, numbered steps, an expected result and a link to the requirement it covers.

Each test case checks one thing, the set of cases covers both valid and invalid inputs, and every case is independent of the others, so they can run in any order.

A developer should be able to reproduce the bug without asking you anything. Include:

• a short, specific title, such as "Checkout fails with error 500 when the coupon contains a space"
• the environment: build number, browser or device, operating system
• exact steps to reproduce
• the expected result and the actual result
• the severity
• evidence: screenshots, a screen recording, logs or the API response

Report one bug per ticket, and search for duplicates before logging a new one.

A guide to the mix of automated tests in a project: many fast, cheap unit tests at the bottom; fewer integration and API tests in the middle, checking that the parts work together; and a small number of slow, fragile end-to-end UI tests at the top, covering the most critical user journeys.

Teams that rely mostly on UI tests — the "ice-cream cone" — end up with slow, flaky pipelines.

Automate tests that run again and again and are stable: regression suites, smoke tests on every build, data-driven tests with many input combinations, and API checks.

Keep testing manual when it needs human judgement or the feature still changes often: exploratory testing, usability, one-off checks and screens whose design isn't settled yet. A rule of thumb: if you'll run it many times and the expected result is clear, automate it.

Selenium is an open-source tool for automating web browsers. Its main parts:

• WebDriver — the API that controls real browsers, such as Chrome, Firefox and Edge, through their drivers
• Selenium Grid — runs tests in parallel across many machines and browsers
• Selenium IDE — a browser extension that records and plays back simple tests

Tests are written in Java, Python, C# or JavaScript, usually with a framework such as TestNG, JUnit or pytest, and organised with the Page Object Model so each page's locators live in one place.

An implicit wait sets a global time for WebDriver to keep looking for an element before it throws NoSuchElementException, and it applies to every findElement call. An explicit wait waits for a specific condition on a specific element, such as being visible or clickable:

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.elementToBeClickable(By.id("submit"))).click();

Explicit waits are preferred because they're precise. Mixing implicit and explicit waits can cause unpredictable timeouts, and fixed Thread.sleep() calls should be avoided.

API testing checks the service layer directly, without the user interface, which makes it faster and more stable than UI testing. For each endpoint you check:

• the status code — 200, 201, 400, 401, 404, 500 and so on
• the response body, and that it matches the expected structure
• error messages for invalid input
• authentication and permissions
• headers and response time

Common tools are Postman for manual testing and collections, and REST Assured (Java) or requests with pytest (Python) for automation.

Exploratory testing means learning the application, designing tests and running them at the same time, guided by the tester's experience rather than a written script. It's usually time-boxed and given a focus, such as "explore checkout with invalid payment details for 45 minutes", with notes taken along the way.

It finds bugs that scripted tests miss, especially in new features and unusual edge cases.

From the smallest scope to the largest:

1. Unit testing — individual functions or classes, usually written by developers
2. Integration testing — modules working together, such as API and database calls
3. System testing — the complete application tested against its requirements, both functional and non-functional
4. Acceptance testing — user acceptance testing (UAT) by the client or end users, to decide whether the product is ready to release