82 software testing interview questions with answers

What they are assessing

Whether you understand the purpose rather than reciting a textbook line.

Model answer

Software testing is evaluating a product to find where its actual behaviour differs from the behaviour someone expected. The purpose is information: it tells the people making release decisions what risk they are carrying. It is not about proving the software works, because you cannot prove that by testing. Testing can show defects are present; it can never show they are absent. Framing the job as quality gatekeeping also tends to be the wrong framing, because quality is built by the whole team, not inspected in at the end by one person.

Likely follow-up

If testing cannot prove software is correct, why do it at all?

What they are assessing

Whether you can distinguish process work from product work.

Model answer

Quality assurance is process oriented and preventive: defining how work is done so defects are less likely to be created, through standards, reviews, definition of done and training. Quality control is product oriented and detective: examining the actual artefact to find defects that were created anyway, which is where testing sits. QA is about building it right, QC is about checking what was built. Most job titles use the terms loosely, so in an interview it is worth saying that and then giving the textbook distinction.

Trap to avoid

Claiming testing and QA are the same thing. They overlap in practice but the interviewer is checking whether you know the distinction exists.

What they are assessing

Precision with two terms that candidates routinely swap.

Model answer

Verification asks whether we are building the product right: does it meet its specification. It is usually static, done through reviews, walkthroughs and inspections of documents and code. Validation asks whether we are building the right product: does it meet the actual user need. It is usually dynamic, done by executing the software. A build can pass verification completely and still fail validation, which is what happens when a team implements a specification that was wrong in the first place.

Likely follow-up

Give an example of software that passed verification but failed validation.

What they are assessing

Recall, and more importantly whether you can apply one.

Model answer

Testing shows the presence of defects, not their absence. Exhaustive testing is impossible. Early testing saves time and money. Defects cluster, so a small number of modules usually contain most problems. The pesticide paradox: repeating the same tests stops finding new defects, so tests must be reviewed and varied. Testing is context dependent, so a payments system and a game are tested differently. And the absence of errors is a fallacy: a product can be defect free against its spec and still be useless if it does not meet user needs.

Trap to avoid

Listing all seven and stopping. Interviewers usually follow up by asking you to apply one to your last project, so have an example ready.

What they are assessing

Whether you have actually written both.

Model answer

A test scenario is a high level description of what to test, usually one line: verify that a user can reset a forgotten password. A test case is the detailed instruction set that proves it: preconditions, specific steps, test data and an expected result precise enough that two people executing it would agree on pass or fail. One scenario typically produces several test cases, covering the happy path plus negative, boundary and edge conditions. Scenarios give coverage at a glance; test cases give repeatability.

Likely follow-up

How many test cases would you write for that password reset scenario?

What they are assessing

Terminology discipline. Sloppiness here shows up later in defect reports.

Model answer

An error is the human mistake, for example a developer misreading a requirement. A defect, used interchangeably with bug, is the resulting flaw sitting in the code or the document. A failure is what an observer sees when that defect is executed under the right conditions. So an error causes a defect, and a defect may cause a failure. The distinction matters because a defect can exist for years without ever producing a failure, if nothing exercises that path.

What they are assessing

Awareness that testing starts before code runs.

Model answer

Static testing examines artefacts without executing them: requirement reviews, design walkthroughs, code review, and static analysis tooling. It catches things dynamic testing structurally cannot reach: ambiguous or contradictory requirements, missing error handling paths, dead code, and maintainability problems. It is also the cheapest place to catch anything, because a defect removed from a requirement document never becomes code, a test, a ticket and a fix. In most teams code review is the single largest static testing activity and is rarely counted as testing at all.

Likely follow-up

What proportion of defects would you expect review to catch versus execution?

What they are assessing

Whether you can argue for testing in business terms.

Model answer

The cost of fixing a defect rises the later it is found, because more work has been built on top of it and more people are involved in the fix. A requirement ambiguity caught in review costs a conversation. The same problem caught in production costs support handling, an expedited fix, a hotfix release, regression re-runs and possibly customer trust. The multiplier commonly quoted is ten to thirty times between pre-release and post-release, though the exact figure depends on the organisation. The argument for shifting testing earlier rests on this multiplier, not on testing being intrinsically virtuous.

What they are assessing

Whether you understand combinatorics, and what you do about it.

Model answer

Because the number of possible input combinations, sequences and states is effectively infinite for any non-trivial system. A single form with ten fields, each accepting a modest range of values, produces more combinations than could be executed in a lifetime, and that ignores ordering and timing. The practical response is risk based testing: identify what matters most by likelihood and impact, use design techniques such as equivalence partitioning and boundary value analysis to cover classes of input rather than every input, and be explicit about what you chose not to test.

Trap to avoid

Answering only that it takes too long. The interviewer wants to hear what you do instead, which is where risk based testing comes in.

What they are assessing

Whether you understand that a passing suite can become worthless.

Model answer

Running the same set of tests repeatedly stops finding new defects, because those tests have already found everything they are capable of finding, in the same way pests become resistant to a repeated pesticide. A suite that has been green for six months may be telling you nothing. The counter is to review and revise tests regularly, add cases driven by new risk areas and production incidents, and supplement scripted regression with exploratory testing, which by design goes where the scripts do not.

What they are assessing

Whether you see testing as a process with entry and exit criteria.

Model answer

Requirement analysis, where you review what is to be built and identify what is testable. Test planning, where scope, approach, resource and schedule are agreed. Test case design and development, including test data. Environment setup, which often runs in parallel and is the stage most likely to slip. Test execution, where cases are run and defects logged and retested. And test closure, where you report results, agree exit criteria are met, and capture lessons. Each phase has entry and exit criteria, which is what makes it a lifecycle rather than a list.

Likely follow-up

Which phase most often gets compressed when a release is late, and what happens?

What they are assessing

Whether you have worked somewhere that enforced them.

Model answer

Entry criteria are the conditions that must be true before a phase starts: requirements signed off, build deployed to the test environment, smoke test passing. Exit criteria are the conditions that must be true before it ends: planned cases executed, no open critical or high defects, coverage target met, and remaining known issues documented and accepted. Their real value is that they make a release decision explicit rather than a feeling, and they give a tester something concrete to point at when asked to sign off early.

What they are assessing

Whether you have written one rather than read about one.

Model answer

Scope, stating explicitly what is in and what is out. The approach and levels of testing. Entry and exit criteria. Environment and test data requirements. Roles and responsibilities. Schedule and milestones. Risks and mitigations. Deliverables. And the suspension and resumption criteria for when the build is too broken to continue. The section that earns its place most often is what is out of scope, because that is the one people refer back to when something was missed.

Trap to avoid

Reciting the IEEE 829 section list without judgement. A good answer names the two or three sections that actually change decisions.

What they are assessing

Whether you apply process selectively or follow it blindly.

Model answer

It maps requirements to the test cases that cover them, in both directions, so you can show coverage and spot requirements with no tests or tests with no requirement. It is genuinely worth the maintenance in regulated environments such as medical, aviation or finance where you must demonstrate coverage to an auditor, and on large projects with formal sign-off. On a small agile product with rapidly changing scope it often becomes a document nobody updates, and the same value is better obtained by linking tests to stories in the tracker.

What they are assessing

Practical judgement. This is the reality on most projects.

Model answer

Start by finding the implicit sources: existing behaviour, comparable features elsewhere in the product, the ticket history, and whatever the support team hears from users. Write down the assumptions you are testing against and circulate them, because an assumption stated in writing usually gets corrected quickly by someone who knows. Use exploratory testing with chartered sessions rather than trying to write scripted cases against a vacuum. And raise ambiguities as defects against the requirement itself, early, because that is the cheapest point to fix them.

Likely follow-up

What do you do if the product owner is unavailable for two weeks?

What they are assessing

Whether you can make a risk call rather than hide behind a checklist.

Model answer

Against agreed exit criteria first: planned coverage executed, no open critical or high severity defects in the release scope, regression green, non-functional checks done where relevant. Then the judgement layer on top: what is still open and who is affected, whether the untested areas carry real risk, whether there is a rollback path, and how quickly a fix could ship if something escapes. My job is to state the risk clearly and recommend, not to give a binary yes. The decision belongs to the business, but it should be an informed one.

Trap to avoid

Saying you would block the release until zero defects remain. No product ships with zero defects, and an interviewer hears that answer as inexperience.

What they are assessing

Whether you can reduce test count without losing coverage.

Model answer

You divide input data into partitions where every value in a partition should be handled the same way, then test one representative value from each rather than all of them. For an age field accepting 18 to 60, the partitions are below 18, 18 to 60, and above 60, so you test one value from each, say 15, 35 and 70. The assumption is that if 35 works, 36 works too. It reduces test count dramatically, and it pairs with boundary value analysis because partition edges are where defects actually cluster.

What they are assessing

Whether you know where defects actually live.

Model answer

You test the values at the edges of each partition, plus one either side. For a field accepting 18 to 60 that means 17, 18, 19 and 59, 60, 61. Boundaries matter because they are where off-by-one errors live: a developer writing less than when they meant less than or equal produces a defect that is invisible in the middle of the range and obvious at the edge. In practice boundary value analysis finds more defects per test written than any other technique, which is why it is worth applying even under time pressure.

Likely follow-up

How would you apply this to a date field, or to a file upload size limit?

What they are assessing

Whether you can handle combinational logic systematically.

Model answer

A decision table lists conditions and the actions that result from each combination of them, so every rule gets a column. You reach for it when behaviour depends on several inputs interacting: discount rules that depend on customer type, order value and promotion status, or eligibility logic in insurance and lending. Its value is that it exposes combinations nobody specified, which is usually where the defects are. If you have four boolean conditions you have sixteen rules, and the business will often discover they only ever thought about six of them.

What they are assessing

Whether you can test features that remember things.

Model answer

You model the system as states and the events that move it between them, then test valid transitions, invalid transitions, and the sequences that reach each state. It suits anything with a lifecycle: an order moving from created to paid to shipped to delivered to returned, or a session moving through logged out, logged in, locked and expired. The defects it finds are the ones scripted single-path testing misses entirely, such as being able to cancel an order that has already shipped, or a state that is reachable but has no exit.

Likely follow-up

How would you model a payment that fails midway and is retried?

What they are assessing

Whether you understand that unscripted does not mean undisciplined.

Model answer

Exploratory testing is simultaneous learning, test design and execution, where what you find shapes what you try next. It is structured: it uses time-boxed sessions against a written charter stating what area you are investigating, and it produces notes, questions and defects that can be reviewed. Ad hoc testing has no charter, no time box and no record, so it cannot be repeated or reported on. Exploratory testing is where most of the interesting defects come from, because scripted cases can only find what someone already thought of.

Trap to avoid

Describing it as random clicking. That is ad hoc testing, and saying so suggests you have never run a chartered session.

What they are assessing

Risk reasoning under pressure, which is most of the job.

Model answer

By risk, which is likelihood times impact. Highest priority goes to what would hurt most if it broke and is most likely to break: revenue paths, authentication, data integrity, anything touched by this release, and areas with a history of defects. Then recently changed code, then integration points. I would also consider what is hardest to fix after release and what has no workaround. And I would state explicitly what I am not running, so the decision to skip it is visible rather than silent.

Likely follow-up

The release is in four hours and full regression takes two days. Talk me through it.

What they are assessing

Maintenance thinking, which separates seniors from mid-levels.

Model answer

Write it against intent rather than implementation. Describe what outcome is expected, not which button is at which coordinate, so a UI redesign does not invalidate it. Keep test data out of the steps and in a data table so it can be updated in one place. Give it a stable identifier and link it to the requirement so its purpose survives the person who wrote it. Keep it independent of other cases, because chained cases fail in cascades. And delete cases that no longer carry risk rather than carrying them forever.

What they are assessing

Whether you can handle configuration explosion.

Model answer

Pairwise, or all-pairs, testing generates a set of combinations such that every pair of parameter values appears together at least once, rather than every full combination. It rests on the empirical finding that most defects arise from a single parameter or an interaction between two, rather than complex higher order interactions. It is the right tool for configuration heavy testing: browser by operating system by locale by payment method. It can cut a few thousand combinations to a few dozen while retaining most of the defect finding power.

What they are assessing

A very common question, and candidates get it backwards often.

Model answer

Smoke testing is a broad, shallow check that the build is stable enough to test at all: can you log in, does the main flow load, do the critical paths respond. It is usually scripted and often automated, and it runs on every build. Sanity testing is narrow and deeper, run after a specific fix or small change to confirm that particular area now behaves and nothing obvious nearby broke. Smoke is wide and shallow on a new build, sanity is narrow and focused after a change.

Trap to avoid

Swapping the two. Remember smoke is wide and shallow, sanity is narrow and deep.

What they are assessing

Whether you have owned a regression suite rather than just run one.

Model answer

Regression testing re-runs existing tests after a change to confirm previously working behaviour still works. The growth problem is real: every release adds cases and nobody removes any, until the suite takes longer than the release cycle. You control it by selecting by impact rather than running everything, automating the stable high value paths, retiring cases whose risk has gone, and periodically reviewing which cases have not failed in years, since those are candidates for removal or for being moved to a less frequent cycle.

Likely follow-up

How do you decide which regression cases to automate first?

What they are assessing

Breadth. Candidates who only think functionally miss whole risk classes.

Model answer

Functional testing checks what the system does against requirements: does the transfer move the right amount to the right account. Non-functional testing checks how well it does it: performance, load, security, usability, accessibility, compatibility, reliability and maintainability. Non-functional failures are often the ones that damage a product most, because a feature that works correctly but takes eleven seconds to respond, or is unusable with a screen reader, has failed the user even though every functional test passed.

What they are assessing

Whether you understand where responsibility sits at each level.

Model answer

Unit testing, checking individual components in isolation, usually written by developers. Integration testing, checking that components work together and that interfaces and data contracts hold. System testing, checking the complete integrated product against requirements, which is typically where a dedicated test team operates. And acceptance testing, checking the product meets business needs, done with or by users, including UAT, alpha and beta. Each level catches a different class of defect, which is why skipping one pushes its defects downstream rather than removing them.

What they are assessing

Basic recall with a practical follow-on.

Model answer

Alpha testing is done in house, in a controlled environment, usually by an internal team standing in for users, before the product goes outside. Beta testing is done by real users in their own environment, with their own data, devices and network conditions, which is precisely where it earns its value: it surfaces the environmental and usage problems no internal environment reproduces. Alpha catches remaining functional defects cheaply; beta catches reality.

What they are assessing

Whether accessibility is part of your definition of done or an afterthought.

Model answer

Against WCAG 2.2 at the level the organisation has committed to, usually AA. Automated tooling such as axe catches roughly a third of issues and should run in CI, but it cannot judge whether alternative text is meaningful or whether focus order makes sense. So the manual layer matters: keyboard only navigation through the whole flow, screen reader testing with at least one real reader, colour contrast checks, zoom to two hundred per cent, and checking that error messages are announced rather than only shown in red.

Likely follow-up

What proportion of accessibility issues would you expect tooling to catch?

What they are assessing

Whether you distinguish the performance test types.

Model answer

Load testing at expected concurrency to confirm response times hold. Stress testing beyond expected load to find the breaking point and confirm it degrades gracefully rather than corrupting data. Soak testing over hours to expose memory leaks and connection pool exhaustion. Spike testing for sudden surges, which matters for anything with a launch or a sale. And I would measure the right things: not just average response time, which hides everything, but the ninety-fifth and ninety-ninth percentiles, error rate and throughput.

Trap to avoid

Reporting average response time alone. Averages conceal the tail, and the tail is what users complain about.

What they are assessing

Realistic scope. You are not expected to be a penetration tester.

Model answer

Within my scope I would cover the things functional testing naturally reaches: authentication and session handling, authorisation checks on every endpoint rather than only in the UI, input validation against injection, sensitive data exposure in responses, logs and error messages, and secure defaults. I would use the OWASP Top Ten as a checklist to structure that. What I would not claim is that this replaces a specialist penetration test or a code level security review, and I would say so explicitly rather than implying coverage we do not have.

What they are assessing

Whether your reports get fixed or bounced back.

Model answer

A title that states the problem specifically enough to be understood in a queue. Environment and build number. Precise steps to reproduce, starting from a known state. Expected versus actual result. Evidence: screenshot, video, console output, network trace or logs. Severity and priority with a reason. And frequency, because intermittent behaves differently from always. The test of a good report is whether a developer can reproduce it without messaging you, and whether it still makes sense to someone reading it in six months.

Likely follow-up

How would you report a defect you can only reproduce one time in ten?

What they are assessing

A classic, and the example you give reveals real experience.

Model answer

Severity is the technical impact of the defect on the system and is normally set by the tester. Priority is how urgently it should be fixed and is normally set by the product owner or triage. They vary independently, which is the point. A company logo misspelled on the home page is low severity and top priority because everyone sees it. A crash in an admin report used twice a year is high severity and low priority. Being able to give both examples is usually what the question is looking for.

What they are assessing

Whether you know the states and what happens at the awkward ones.

Model answer

New when logged, assigned to a developer, open while being worked, fixed when the change is made, then retested by the tester and either closed or reopened. The other states are where the interesting conversations happen: deferred when it is real but not for this release, duplicate, rejected when the developer disputes it, and not a defect when behaviour matches the specification. Reopened and rejected are the two worth talking about, because how a team handles disagreement says more than the happy path does.

What they are assessing

Conflict handling. The answer reveals how you work with people.

Model answer

First I check whether they are right, by going back to the requirement, the acceptance criteria and the design. Often they are. If the specification genuinely says this, but the behaviour will still harm users, I reframe it: not a defect against the spec but a defect in the spec, and raise it with the product owner with evidence of user impact. If I think the developer has misread it, I add the missing evidence rather than re-arguing: the exact requirement text, the reproduction, the data. What I avoid is escalating before doing that work, because it costs credibility.

Trap to avoid

Saying you would escalate to the manager immediately. That answer reads as someone who creates friction rather than resolving it.

What they are assessing

Persistence and method, rather than giving up and closing it.

Model answer

Log it anyway, with the frequency stated and everything captured from the occurrence I did see: timestamp, build, environment, data, logs, network trace and video if available. Then work the variables systematically: timing, concurrency, cached state, specific data, device or network conditions. Check whether server logs show it even when the UI does not. Add temporary instrumentation if the team will allow it. Intermittent defects are usually timing or state related, and they are the ones most likely to reappear in production at scale, so closing them for lack of reproduction is the wrong instinct.

What they are assessing

Whether you have actually worked in both.

Model answer

Testing stops being a phase at the end and becomes continuous within each iteration, so the tester is involved from refinement onwards rather than receiving a build. Documentation gets lighter and more disposable: charters and checklists instead of large test plans. Automation moves from optional to necessary, because you cannot regression test manually every two weeks. And the tester takes on more advocacy work, questioning acceptance criteria before code is written, which is where most of the value actually is.

Likely follow-up

What testing documentation would you still keep in an agile team, and why?

What they are assessing

Whether you shape process or just follow it.

Model answer

It is the shared agreement on what must be true before a story is considered complete, applied to every story rather than negotiated each time. Testing contributes the conditions that prevent work being declared done while risk remains: acceptance criteria verified, unit tests written and passing, regression impact considered, no open critical defects, and any non-functional checks the story needs such as accessibility or performance. Its value is that it removes the per-story argument about whether something is finished.

What they are assessing

Whether you can describe behaviour change rather than a slogan.

Model answer

Moving testing activity earlier so defects are prevented or found when they are cheap. In practice that means testers in refinement asking what happens when this fails, acceptance criteria written to be testable before development starts, static analysis and unit tests in the pipeline, and API level tests running before a UI exists. It does not mean testers writing unit tests for developers, and it does not remove the need for testing later. The measurable outcome is a higher proportion of defects found before the code is merged.

Trap to avoid

Treating shift left as purely an automation initiative. Most of the gain comes from the conversations before code is written.

What they are assessing

Whether you address the cause or just absorb the pain.

Model answer

In the short term, risk based: cover the acceptance criteria and the highest risk paths, be explicit about what was not covered, and let the team decide whether to carry it over rather than quietly shipping untested work. In the longer term this is a symptom, not an event, and I would raise it in the retrospective with data on how often it happens. The usual fixes are smaller stories, agreeing a code complete point before the sprint end, and testers pairing with developers during the build rather than waiting for a handover.

What they are assessing

Judgement. Knowing what not to automate is the more valuable half.

Model answer

Automate what is repetitive, stable, high risk and will run many times: regression paths, smoke tests, data driven cases with many combinations, and anything that is impractical manually such as load. I would not automate one-off checks, areas still changing shape weekly, anything requiring human judgement about look and feel, or tests whose maintenance would cost more than running them by hand. The test I apply is how many times it will run before it changes, because a case that runs twice and then needs rewriting is a net loss.

Likely follow-up

Give me an example of something you deliberately chose not to automate.

What they are assessing

Whether you diagnose causes or reach for retries.

Model answer

The usual causes are timing, where the test does not wait properly for an asynchronous state; shared or polluted test data; test interdependence where order matters; environment instability; and brittle selectors tied to layout rather than intent. The fix is diagnosis by category, not blanket retries. Retries hide the signal and eventually train the team to ignore red builds, which is worse than the flakiness. I would quarantine the flaky test so it stops blocking, fix the cause, and track flake rate as a metric rather than an anecdote.

Trap to avoid

Answering that you would add a retry or a fixed sleep. Both are the recognised wrong answers to this question.

What they are assessing

Commercial literacy at senior level.

Model answer

With a payback model rather than a principle. Cost side: build hours at the automation engineer rate, framework and environment setup, annual maintenance at fifteen to thirty per cent of build cost, CI compute, and triage time. Benefit side: manual cycle cost times frequency, minus the manual effort that will remain, because it never falls to zero. That gives a payback period and a break-even number of runs. I would also state the benefit I cannot quantify, which is faster feedback, rather than inventing a number for it.

What they are assessing

Whether you distinguish useful measures from vanity ones.

Model answer

Defect escape rate, meaning defects found in production against total found, because it measures whether testing is working. Defect density by module, to find where risk concentrates. Test execution progress against plan during a release. Mean time to detect and to resolve. And requirement coverage. What I avoid presenting as a quality measure is the raw count of test cases or defects logged, because both are easily gamed and neither tells you anything about risk.

Likely follow-up

How would you calculate defect escape rate in practice?

What they are assessing

Whether you understand incentives.

Model answer

Because it measures activity, not risk coverage. A thousand shallow cases covering the same happy path tell you less than fifty well designed ones that exercise boundaries and error handling. Worse, once it becomes a target people optimise for it: cases get split unnecessarily to raise the count, and nobody deletes obsolete ones. The same applies to code coverage percentage, which can be high while assertions are weak or absent. Measure outcomes such as escaped defects rather than volume of work produced.

What they are assessing

Structured thinking, and whether you start by listening.

Model answer

I would start by understanding the risk: what the product does, who depends on it, what a failure costs, and where it has hurt before, which means reading the incident history and talking to support. Then assess what exists: current coverage, automation state, environments, test data, and where defects are actually escaping. Then define levels and ownership, what gets automated and at which layer, environment and data strategy, and entry and exit criteria. And I would sequence it, fixing the largest source of escaped defects first rather than trying to change everything at once.

What they are assessing

Practical handling of external dependencies.

Model answer

Use the sandbox the provider offers for functional coverage, and their documented test cards or accounts to drive specific outcomes such as declines, timeouts and fraud flags. Mock or stub the integration for the cases the sandbox cannot produce, particularly failure and latency scenarios, so you can test your own error handling deterministically. Contract test the interface so a provider change is caught early. And keep a small set of real transactions in a controlled environment, because sandboxes never behave exactly like production.

Likely follow-up

How would you test what happens if the gateway responds after your timeout?

What they are assessing

Whether you can state risk without becoming an obstacle.

Model answer

I would separate the two things: the decision is the business owner's, the information is mine. So I would put the risk in writing, specifically: what is untested or failing, what the realistic impact is, which users are affected, whether a workaround or rollback exists, and what additional time would reduce the risk by how much. Then I would recommend clearly. If the business accepts the risk with that information in front of them, that is a legitimate decision and I would support the release and prepare monitoring for the areas of concern.

Trap to avoid

Refusing outright. Testers do not own release decisions, and an interviewer hears a refusal as someone who will block delivery rather than inform it.

What they are assessing

Whether you diagnose before prescribing.

Model answer

I would start with the escapes themselves rather than assumptions: categorise the last three months of production defects by root cause and by the stage that should have caught them. That usually shows a pattern, such as most escapes being integration or data related rather than functional, or clustering in one module or one type of change. Then fix the largest category first, whether that means better environments, contract tests, earlier involvement in refinement, or improving the definition of done. Adding more test cases without doing this analysis is the common mistake and rarely changes the escape rate.

Likely follow-up

What if the analysis shows most escapes come from urgent hotfixes bypassing process?

What they are assessing

Whether you have worked in a real deployment pipeline.

Model answer

Typically development, where engineers work and nothing is stable. Test or QA, where the test team runs planned testing against a controlled build. Staging or pre-production, which should mirror production in configuration and data shape and is where release validation and performance work happen. And production. Some organisations add integration or UAT environments. The important part is that each has a defined purpose and a defined data state, because testing in an environment whose configuration drifts from production produces results nobody can trust.

What they are assessing

Whether you treat environment instability as a first-class problem.

Model answer

Quantify it first: hours lost per sprint and what specifically failed, because environment pain is usually tolerated precisely because nobody has measured it. Then separate the causes, which are normally shared environments with conflicting changes, manual configuration drift, and data being consumed or corrupted by other testers. The durable fixes are infrastructure as code so environments are rebuilt rather than repaired, containerisation for isolation, and seeded data reset on a schedule. In the short term I would agree booking or branching so two teams are not deploying over each other.

Likely follow-up

How would you argue for that investment to a delivery manager focused on features?

What they are assessing

Practicality. Test data is where most automation efforts quietly fail.

Model answer

Prefer data the test creates and cleans up itself, so tests are independent and can run in parallel. Where a shared seed set is needed, keep it in version control and reset it on a schedule rather than letting it erode. Never depend on data a human created manually last month. For volume, generate it. For production-like data, mask or synthesise rather than copying, which is both a legal requirement under data protection rules and a practical one because real data contains cases nobody can explain. And keep data out of test steps so it can be changed in one place.

Trap to avoid

Saying you would copy production data down. Without masking that is a data protection breach in most jurisdictions, and interviewers in regulated sectors are listening for it.

What they are assessing

Whether you can unblock yourself rather than wait.

Model answer

Agree the contract first, because that is what lets both sides proceed: the endpoint shape, status codes, error responses and timeouts. Then stub or mock against that contract so functional work continues, and add contract tests so the real implementation is checked against the agreement when it lands. I would also deliberately test the failure modes the stub makes easy and reality makes hard: timeouts, malformed payloads, partial responses and slow responses. The risk to name openly is that passing against a mock proves your handling works, not that the integration works.

What they are assessing

Whether you estimate from evidence or from optimism.

Model answer

I break the feature into testable areas and estimate each, rather than giving one number for the whole thing. Inputs are the number of acceptance criteria, the integration points, the data conditions, and how much regression the change touches. I use historical actuals from similar work where they exist, because they beat judgement. Then I add explicitly for test design, environment setup, defect retesting and the regression pass, since those are the parts routinely left out. And I give a range with the assumptions stated rather than a single figure.

Likely follow-up

Your estimate is halved by the delivery manager. What do you do?

What they are assessing

Whether you resist a bad question sensibly.

Model answer

There is no defensible universal ratio, and quoting one such as thirty per cent invites a budget conversation detached from risk. It depends on the risk profile, the maturity of the codebase, how much is automated, and the regulatory context: a payments change and a marketing page are not comparable. I would answer by estimating this work from its own characteristics, and if pushed for a rule of thumb I would give a range from our own historical data on comparable features, which is at least evidence rather than folklore.

What they are assessing

Structure. This is the most asked question in testing interviews.

Model answer

I would work outward in layers rather than list cases randomly. Functional: valid credentials, invalid password, unknown user, empty fields, case sensitivity, trailing whitespace. Boundary: field length limits. Security: lockout after repeated failures, whether the error message reveals which field was wrong, SQL injection and script injection attempts, credentials not in the URL, session token regenerated on login. Usability: tab order, password manager support, show password, error clarity. Compatibility: browsers, devices, screen readers. Then state management: back button after logout, concurrent sessions, session expiry, remember me.

Likely follow-up

Which of those would you automate, and which would you leave manual?

Trap to avoid

Listing twenty functional cases and stopping. The security and state questions are what distinguish a mid-level answer from a fresher one.

What they are assessing

Whether you can structure testing for something with no specification.

Model answer

The point of the question is structure, not the object. I would cover functional behaviour, boundary conditions such as maximum load or capacity, negative cases such as conflicting inputs, usability, safety, performance under repeated use, and failure modes including power loss mid-operation. I would state my assumptions first, since there is no specification, and ask clarifying questions about context: a lift in a hospital and a lift in an office block have different requirements. Interviewers are watching whether you ask anything at all before answering.

Likely follow-up

What are the failure modes of a lift, and how would you test each safely?

What they are assessing

Investigative method rather than dismissal.

Model answer

Gather the specifics: exact time, account, device, browser and version, network, and the sequence they actually took rather than the one they described. Then check server-side evidence for that timestamp, since logs and monitoring often show the failure even when the UI cannot be reproduced. Look at what differs between them and me: data state, permissions, feature flags, locale, timezone, cached assets, extensions. Feature flags and per-account data are the two most common answers. If it stays unreproducible I would log it with everything gathered rather than closing it, and add monitoring for the pattern.

What they are assessing

Prioritisation when everything is broken.

Model answer

Week one, understand rather than fix: read the incident history, talk to support and developers, and map what the product does and who depends on it. Week two, stop the bleeding by covering the highest risk paths with a small smoke suite, so the worst failures are caught before release. Week three, categorise recent escapes by root cause to find where the leak actually is. Week four, propose a sequenced plan with the single largest cause first. The mistake would be starting by writing a comprehensive test plan nobody reads while incidents continue.

Likely follow-up

What if you find the real problem is deployment practice rather than testing?

What they are assessing

Proportionality. Over-testing is also a failure.

Model answer

Proportionately to the risk rather than the usage. Low usage does not mean low impact: an admin function used twice a year may be the one that corrects payroll. So I would ask what happens if it fails, who is affected, whether it touches money or data integrity, and whether there is a manual workaround. If impact is genuinely low, a focused happy path plus the main error cases is enough, and I would say explicitly that deeper coverage was not done and why. Spending a week on it would be the wrong call and worth resisting.

What they are assessing

Whether you think past typing a word and pressing enter.

Model answer

Relevance first: exact match, partial match, ranking order, and whether the expected result appears for a realistic query. Then input handling: empty search, whitespace only, very long strings, special characters, injection attempts, unicode and non-Latin scripts, case and accent insensitivity, misspellings and whether fuzzy matching exists. Then behaviour: no results state, pagination, filters combined with search, result counts matching reality. Then performance with a large data set, and state such as whether the query survives a back navigation. Relevance is the part usually under-tested because it needs judgement.

What they are assessing

Breadth across function, security and failure.

Model answer

Valid formats and sizes first, then the boundaries: zero byte file, exactly at the limit, one byte over, and something very large. Invalid types, including a file renamed to a permitted extension, which is the security case. Malicious content such as a script in an image or a zip bomb. Concurrency: two uploads at once, upload cancelled midway, network dropped midway, and whether a partial file is left behind. Then storage and retrieval: is it scanned, where is it stored, is the URL guessable, can another user access it. Filenames with unicode, spaces and path traversal sequences.

Trap to avoid

Covering only valid and invalid formats. The interesting defects are in interrupted uploads and in access control on the stored file.

What they are assessing

Behaviour in an incident, where testers often add most value.

Model answer

Not to debug the code, but to establish facts fast: what exactly is failing, for whom, since when, and what changed. I would reproduce the failure in a controlled way if possible, confirm the blast radius, and check whether a known recent change correlates. Once a fix is proposed I verify it in a non-production environment and then verify it in production after deploy, including the surrounding paths a hotfix might have disturbed. Afterwards I own the question of why testing did not catch it, and add the case to regression.

Likely follow-up

The fix is ready and there is no time for full regression. What do you tell the incident lead?

What they are assessing

Whether you know where interface defects are caught.

Model answer

Integration testing checks that components work together correctly, focusing on the interfaces and the data passed across them. Big bang integrates everything and tests at once, which is quick to set up and slow to diagnose. Top down starts from high level modules using stubs for the lower ones. Bottom up starts from low level modules using drivers. Sandwich or hybrid combines both. Incremental approaches cost more setup but localise failures, which is why they are usually preferred on anything non-trivial.

What they are assessing

Understanding of where sign-off authority sits.

Model answer

UAT confirms the product meets business needs and is fit for real use, performed by business users or their representatives rather than the test team. The test team usually supports it: preparing environments and realistic data, writing scenarios in business language, and triaging what comes back. It is not a repeat of system testing, and using it as one is a common failure: if UAT is finding functional defects, testing upstream has not done its job. Its purpose is validating fitness for purpose, not finding bugs.

What they are assessing

Pragmatism about the device matrix.

Model answer

Drive it with data rather than instinct: analytics tells you which browsers, operating systems and devices your users actually use, and usually a small set covers the large majority. Cover that set on real devices, then use a device cloud for the long tail and for versions you cannot hold. Apply pairwise combination to avoid multiplying out every permutation. And be explicit about the cut-off, stating which configurations are supported and which are best effort, so an unsupported combination failing is a known position rather than a surprise.

What they are assessing

Awareness of a commonly skipped area.

Model answer

It verifies the product works correctly for a target locale, beyond translation. The things that break most often are text expansion overflowing layouts, because German and Finnish run much longer than English; date, time, number and currency formats; sort order and collation for non-Latin scripts; right to left layouts for Arabic and Hebrew; timezone handling; and hard-coded strings that were never externalised. Character encoding problems in search and in database storage are the other recurring class. Pseudo-localisation is a cheap way to find most layout and hard-coding issues before real translation exists.

What they are assessing

Whether you distinguish correctness from effectiveness.

Model answer

UI testing verifies the interface behaves as specified: the button is present, it is enabled at the right time, it does what it should. Usability testing evaluates whether real users can accomplish their goal efficiently and without confusion, which is a question about people rather than code. It is done by observing users attempting realistic tasks and measuring completion, errors, time and where they hesitate. A screen can pass every UI test and still fail usability, which is why the two are not substitutes.

What they are assessing

Whether you can test things that do not answer immediately.

Model answer

The hard part is knowing when to assert. I would avoid fixed sleeps and instead poll for the expected end state with a timeout, or subscribe to the completion event where one exists. Beyond timing, the cases that matter are ordering, duplicate delivery since most queues guarantee at least once rather than exactly once, message loss, poison messages and dead letter handling, replay behaviour, and idempotency of the consumer. I would also test what the user sees while processing is in flight, because that intermediate state is frequently unspecified.

Likely follow-up

How would you verify a consumer is genuinely idempotent?

What they are assessing

Whether you have facilitated one rather than attended.

Model answer

With the right people in the room, meaning someone who can decide priority, someone who can assign work and someone who knows the technical impact. Work the queue in priority order, timeboxed, deciding one of four things for each: fix now, fix later with a target, reject with a reason recorded, or need more information with an owner. The discipline that makes it work is refusing to debug in the meeting. If a defect needs investigation it gets an owner and leaves the room, otherwise the meeting runs for two hours and clears six items.

What they are assessing

Whether you fix causes or symptoms.

Model answer

It is establishing why a defect existed rather than only what it was, usually by asking why repeatedly or with a fishbone diagram for contributing factors. The useful output is a category: was it a requirement ambiguity, a design gap, a coding error, a missing test, an environment difference, or a process bypass. Categorising a quarter of escapes this way tells you where to invest, and the answer is very often not more test cases. I would run it on escaped and severe defects rather than every defect, because it costs real time.

Likely follow-up

What would you change if most escapes traced back to requirement ambiguity?

What they are assessing

Whether you shape work before it is built.

Model answer

The questions that prevent defects rather than find them. What happens when this fails, what the error state looks like, what the boundaries are, what data conditions exist, whether it affects existing behaviour, and how we will know it works. Most of my value in refinement is turning vague acceptance criteria into testable ones, and surfacing the edge case nobody had considered while it still costs a conversation rather than a sprint. I would also flag where a story is too large to test meaningfully within the sprint.

What they are assessing

Whether you understand it as collaboration rather than syntax.

Model answer

BDD is a collaboration practice where business, development and testing agree examples of behaviour in a shared language before code is written, often expressed as given, when, then. Its value is in the conversation that produces the examples, which is where ambiguity gets removed. The automation layer underneath is optional and secondary. Teams that adopt only the Gherkin syntax without the three-way conversation usually end up with a slow, brittle suite and a translation layer nobody wanted, which is the most common way BDD fails.

Trap to avoid

Describing BDD purely as Cucumber and given-when-then. That is the artefact, not the practice.

What they are assessing

Whether you can make regression fit the cadence.

Model answer

Full manual regression is impossible at that cadence, so the suite has to be layered. A fast automated smoke on every build. A fuller automated regression nightly, pushed down to API and unit level wherever possible because UI tests will not run fast enough. Then risk-based manual testing of what actually changed, guided by impact analysis rather than by re-running everything. And feature flags so unfinished work ships dark. If regression still does not fit, that is evidence to bring to the team about test architecture rather than a reason to work weekends.

What they are assessing

Whether you think about feedback speed.

Model answer

By speed and reliability. Unit tests and static analysis on every commit, finishing in a couple of minutes. API and integration tests on merge to the main branch. A UI smoke suite on deployment to the test environment. Full UI regression nightly, since it is too slow to gate a merge. Performance and security scans on a schedule or before release. The organising principle is that the earlier a stage runs, the faster and more deterministic it must be, because a slow or flaky gate is a gate people learn to bypass.

What they are assessing

Whether you understand what coverage does and does not measure.

Model answer

Coverage measures which lines executed during the test run, not whether anything meaningful was asserted. A suite can execute almost every line and assert almost nothing, or assert only that no exception was thrown. It also says nothing about the cases that were never written: boundaries, error paths, integration behaviour and data conditions. So high coverage with escaping defects usually means weak assertions, missing negative cases, or defects living between components where unit tests do not reach. I would look at the escaped defects themselves rather than the percentage.

Likely follow-up

What would you measure instead?

What they are assessing

Test architecture thinking.

Model answer

At the lowest level that can answer the question honestly. Business logic belongs in unit tests, where feedback is in seconds and failures point at a function. Contract and data handling belongs at API level. Only genuine end-to-end journeys belong in the UI, because those are the slowest, most brittle and least precise. The common failure is pushing everything to the UI because that is where the tester is comfortable, which produces a suite that takes hours and fails for reasons unrelated to the feature under test.

What they are assessing

Whether you can adapt when expected results are probabilistic.

Model answer

You stop asserting exact outputs and start asserting properties and thresholds. Accuracy, precision and recall against a held-out labelled set, with an agreed minimum. Behavioural tests for invariants that must hold regardless of the model, such as a negative sentiment input never being classified positive. Bias testing across demographic slices. Robustness against adversarial or malformed input. And the system around the model: how it behaves on timeout, on low confidence, and whether there is a fallback. Data quality testing on the training and inference pipeline usually matters more than testing the model itself.

Likely follow-up

How would you catch model drift after release?

What they are assessing

Change management, not just testing knowledge.

Model answer

Start by earning the right to be listened to: find and fix something visible quickly, such as a smoke suite that catches a class of failure the team keeps hitting. Then introduce practices one at a time and tie each to a problem the team already feels, because process introduced for its own sake gets dropped. Bring developers in rather than positioning testing as a separate gate, usually through shared ownership of the definition of done. And measure escaped defects from the start, so the value of what you are building is visible in numbers rather than assertion.

What they are assessing

Whether you can develop people rather than just correct them.

Model answer

Show rather than tell: sit with them and walk through a defect a developer bounced, and one that was fixed the same day, so the difference is concrete rather than abstract. Give them a checklist for the first few weeks covering steps, environment, evidence and expected versus actual. Then review a sample of their reports weekly with specific feedback rather than a general instruction to improve. And explain the consequence, which is that a vague report costs a developer twenty minutes of reproduction and erodes trust in the whole team.

What they are assessing

Whether you have a considered view rather than buzzwords.

Model answer

Three things I would defend. AI assistance is real for test generation and maintenance but shifts the work rather than removing it, because someone still has to judge whether generated tests assert anything useful. Testing continues moving earlier and into the pipeline, so the skill mix tilts toward engineering and away from execution. And non-functional concerns, particularly accessibility, privacy and now AI governance, are moving from optional to contractual. What I would avoid claiming is that AI will replace testers, because the judgement part is precisely what it does not do.