QA and software testing interview questions

What QA interviewers are scoring

The US Bureau of Labor Statistics describes the role in one line: software quality assurance analysts and testers identify problems with applications or programs and report defects. The listed duties are a fair syllabus for the interview, since they cover creating test plans, scenarios and procedures for new software, identifying project risks and recommending steps to minimize them, implementing testing using manual, automated and exploratory approaches, documenting and reporting defects, and giving feedback to developers and stakeholders on usability and functionality.

Read that list again as an interviewer would. Every item is judgement under incomplete information: which risks matter, which tests are worth writing, which defect is worth arguing about. That is why a candidate who recites definitions perfectly can lose to one who asks two good clarifying questions first.

So split your preparation in two. Keep the vocabulary sharp, because the opening minutes are definitions and a wrong one is expensive. Then practise the second half out loud: here is a feature, what do you test, in what order, and what would make you refuse to sign off.

The definitions, stated precisely

Quality assurance is about the process that prevents defects; quality control is about checking the product that came out of it. That distinction is the point of most qc and qa interview questions, and the short version is that QA is preventive and process-focused while QC is detective and product-focused.

Verification asks whether the product was built to the specification, validation asks whether the specification solved the user’s problem. A build can pass verification and fail validation, and naming an example of that from your own work is a strong answer.

Severity and priority are the pair most often confused. Severity is how badly the defect damages the product; priority is how soon it should be fixed. A crash in a feature nobody uses yet is high severity and low priority. A misspelled company name on the landing page is low severity and high priority. Expect to be asked for exactly that kind of crossover example.

A test scenario is what you intend to exercise, stated in a line; a test case is the concrete steps, data and expected result that make it repeatable. Smoke testing is a shallow pass over the critical paths to decide whether a build is worth testing at all; sanity testing is a narrow check that one fix works; regression testing re-runs a wider set to confirm nothing else broke; retesting is running the exact failed case again after the fix. Finally, be able to walk a defect through its life: new, triaged, assigned, fixed, ready for test, verified and closed, with reopened and “cannot reproduce” as the branches that need the most careful notes.

The live exercise: how would you test this?

You will be handed something small and vague: a login form, a search box, a lift, a vending machine, or a shipping cost rule. Interviewers are watching for structure, not for a long list.

Start with questions, because the missing specification is part of the test. Who uses it, what must never happen, which platforms are supported, where does the data come from, is there a legal or payment consequence to getting it wrong? Then say your order of attack: the main path first, then the boundaries, then the invalid inputs, then the environment, then the non-functional checks such as accessibility, performance and security, as far as the role covers them.

Boundary analysis is the technique to show explicitly. Suppose shipping bands are defined by weight.

def shipping_band(weight_kg):
    if weight_kg <= 0:
        raise ValueError("weight must be greater than zero")
    if weight_kg <= 2:
        return "small"
    if weight_kg <= 10:
        return "medium"
    return "large"

The equivalence classes are rejected, small, medium and large, so one value from each gives you four tests. The interesting cases sit on the edges: 0 is rejected, 0.1 and 2 are small, 2.01 is medium, 10 is still medium, 10.01 is large. Then attack the type and the absence of a value: text, an empty field, a negative number, a value with a comma as the decimal separator, a weight in pounds pasted by a user in another country. Say that last one out loud, because noticing units is exactly the judgement the exercise is designed to find.

Finish by stating what you would not test and why. Ruling something out on risk grounds, rather than trying to cover everything, is what senior candidates do differently.

Writing the defect report

A common follow-up is: you have found the bug, write it up. The answer is a report a developer can act on without a conversation, and you can say it aloud in this shape.

Title: Checkout returns a server error when the postcode contains a space

Environment: current Chrome on Windows 11, staging build of 13 October, test account with a UK address

Steps: add any item to the basket, enter a delivery address with the postcode SW1A 1AA, then select Pay

Expected: the order is created and the confirmation page loads

Actual: the page shows a generic error, the payment API returns a 500 and no order is created

Notes: reproducible on every attempt; the same address without the space succeeds; the server log records a validation failure on the postcode field; no workaround a user would find, so severity is high and priority is this release

The parts interviewers listen for are reproducibility, the expected against actual split, the evidence, and a severity claim with a reason attached. Add what you would include in practice: a screen recording, the request identifier from the log, and the narrowest steps rather than the whole journey you happened to take. If the fault is intermittent, say so and say how often, because a flaky defect dressed up in confident wording wastes a developer’s afternoon.

The automation round

Automation qa engineer interview questions start from a question about judgement: what do you automate? The expected answer is the stable, repetitive, high-value checks, with exploratory and one-off testing left to people, and nothing automated against a screen that is still changing weekly.

Then come locators and waits, which is where real experience shows. Prefer stable identifiers over positional selectors, because a path copied from the browser breaks the moment anyone edits the markup. On timing, know the vocabulary exactly. Selenium’s documentation describes the mismatch between browser and script speed as one of the primary causes of flaky tests, defines an implicit wait as a built-in automatic wait whose default value is 0, so a missing element errors immediately, and defines explicit waits as loops that poll the application for a specific condition to evaluate as true. It also gives a flat warning worth quoting in an interview: do not mix implicit and explicit waits, since doing so can cause unpredictable wait times.

Expect the test pyramid question too: more unit than integration tests, more integration than end-to-end tests, because the cheap fast layers catch most regressions and the slow layer is where flakiness lives. Then say how you keep a suite trustworthy: no sleeps, independent tests that create their own data, one place where selectors live, and a rule that an intermittent test is fixed or removed rather than retried until it passes.

API, data and performance questions

API testing questions are usually practical: how do you test an endpoint without a user interface? Cover the contract, the status codes, the required and optional fields, what happens with a malformed body, authorization on somebody else’s record, and idempotency when the same request arrives twice.

ETL testing interview questions are really SQL questions. Expect to be asked how you prove a load is correct, and the answer is counts, sums and keys, not eyeballing a sample.

SELECT 'source' AS side, COUNT(*) AS row_count, SUM(amount) AS total_amount
FROM stage_orders
UNION ALL
SELECT 'target' AS side, COUNT(*) AS row_count, SUM(amount) AS total_amount
FROM dw_orders;

SELECT order_id, COUNT(*) AS copies
FROM dw_orders
GROUP BY order_id
HAVING COUNT(*) > 1;

The first query reconciles volume and value between the two sides, and the second catches the duplicate rows that a re-run of a job quietly creates. Add the checks around them: rows present in the source and missing in the target, nulls appearing in columns that were populated upstream, and a type or precision change that rounds money.

Performance testing interview questions check whether you know what you are measuring. Separate load, stress, soak and spike tests, and insist on a defined scenario and a baseline before any number means anything. Report response times as percentiles rather than averages, because an average hides the slow tail users complain about.

Test lead and behavioral questions

Software testing interview questions for test lead and quality assurance manager roles move off technique and onto decisions. The core one is the release call: how do you say a build is ready? A defensible answer names the exit criteria agreed in advance, the open defects by severity, the areas you could not cover and why, and the risk you are handing to whoever signs off. Saying “it is ready” without that is the wrong answer.

Expect questions about disagreement, because QA lives in it. A developer closes your defect as “works as designed”. A product owner wants to ship with a known data loss bug. A deadline arrives with half the regression suite unrun. Answer with evidence and options rather than position: what the user impact is, what you could cover in the remaining time, and what you recommend. Keep blame out of it.

Leads also get asked about metrics, which is a trap worth naming. Defect and test case counts are easy to game and say little about quality, so talk about escaped defects, coverage of agreed risk areas and cycle time, and admit that no single number replaces judgement. For the behavioral half, use situation, task, action and result and keep most of each answer on what you did; the STAR method page covers the structure and behavioral interview questions the common prompts.