82 agile testing interview questions with answers

What they are assessing

Basic orientation.

Model answer

Testing practised as a continuous activity within an iterative delivery process rather than as a phase after development. Testers are involved from the moment a story is discussed, testing happens alongside development within the iteration, and feedback is given continuously rather than in a report at the end. The defining difference is not the techniques used, which are largely the same, but when testing happens and who is responsible for it.

Likely follow-up

What changes about the tester role compared with a waterfall project?

What they are assessing

Whether the candidate knows the source material.

Model answer

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. The manifesto explicitly states that the items on the right have value, and the ones on the left have more, which is the part most often dropped when people quote it. That qualification matters for testing, because it does not say documentation is worthless, only that working software matters more.

Trap to avoid

Reciting the values as if the right-hand items have no value. The manifesto says the opposite, and misquoting it is how people justify having no test documentation at all.

What they are assessing

A comparison asked in almost every agile testing interview.

Model answer

Timing, ownership and documentation. Testing is continuous rather than a phase, so defects are found days after being written rather than months. Quality is a whole team responsibility rather than a testing department gate, so a tester influences rather than inspects. Documentation is lighter, with conversations and acceptance criteria replacing large test plans, though not disappearing. And the tester is involved before the code exists, which is where most of the value comes from, because preventing a misunderstanding costs a conversation while detecting it costs a rebuild.

What they are assessing

A nuanced question with an easy wrong answer.

Model answer

Less of the documentation that exists to satisfy a process, not less of what the team actually uses. Acceptance criteria, automated tests as living specification, exploratory session notes and a record of release risk all remain necessary. What goes is the hundred page test plan nobody reads and the detailed scripted case for a feature that will change next sprint. The honest framing is that documentation should be sized to its audience and its lifespan, and in a regulated environment agile does not reduce the requirement at all.

Likely follow-up

What documentation would you insist on keeping?

What they are assessing

Attitude rather than process knowledge.

Model answer

Collaborative rather than adversarial, so the tester works with developers to prevent defects rather than competing to find them. Oriented toward the whole team owning quality rather than defending testing as a separate function. Comfortable with incomplete information, since in agile you will never have a finished specification and waiting for one means never starting. Willing to automate and to work technically, because manual regression does not scale with iteration. And focused on risk and feedback speed rather than on exhaustive coverage.

What they are assessing

Framework basics.

Model answer

Sprint Planning, where the team decides what to deliver and how. The Daily Scrum, a short daily synchronisation for the developers. Sprint Review, where the increment is inspected with stakeholders. And Sprint Retrospective, where the team inspects how it worked and agrees improvements. The Sprint itself is also an event, acting as the container for the others. Backlog refinement is an ongoing activity rather than a formal event, though most teams schedule it.

What they are assessing

Current terminology.

Model answer

Product Owner, accountable for the product backlog and maximising value. Scrum Master, accountable for the effectiveness of Scrum within the team. And Developers, which since the 2020 Scrum Guide is the term for everyone doing the work, including testers. That change matters for this question: Scrum has no tester role, and the official position is that testers are developers in the Scrum sense. In practice teams still distinguish specialisms, but the framework deliberately does not.

Likely follow-up

What is the practical consequence of Scrum having no tester role?

What they are assessing

Involvement beyond execution.

Model answer

Testability questions, which is the highest value contribution: how will we know this works, what data will we need, which environment, and does anything block testing. Effort estimates that include testing rather than development alone, since teams that estimate only coding consistently overcommit. Risk input on which stories carry more than their size suggests. And identifying dependencies, such as a third party integration that cannot be tested until a sandbox is available, which is far cheaper raised in planning than discovered on day seven.

What they are assessing

Upstream involvement.

Model answer

The ongoing activity of adding detail, estimates and order to backlog items so they are ready for a future sprint. A tester attends because that is where ambiguity is cheapest to resolve. Asking what happens if the payment fails halfway, or what the system should do when the field is empty, changes the story before anyone writes code. It also produces better estimates, because the team sees the testing implications early. A tester who first sees a story in sprint planning has missed the only opportunity to influence what gets built.

What they are assessing

Improvement contribution.

Model answer

A regular session where the team inspects how it worked and commits to improvements. As a tester the things worth raising are usually about flow rather than about testing itself: stories arriving all at once late in the sprint, environments unavailable, acceptance criteria written too thinly, or defects being found that earlier practice would have prevented. The framing matters, because raising it as testing was squeezed invites defensiveness, while raising it as work arrived in the last two days and here is what that cost invites a team level fix.

Likely follow-up

How would you raise a recurring problem that the team keeps agreeing to fix and does not?

What they are assessing

A less commonly discussed Scrum artefact.

Model answer

A time-boxed investigation to answer a question or reduce uncertainty, producing knowledge rather than shippable functionality. Testing is involved when the uncertainty is about testability or risk: can this integration be tested without the real third party, what does the performance profile look like before we commit to a design, or is this library viable. A spike is also the right response when a story cannot be estimated because nobody knows how it would be verified, and proposing one is often more useful than accepting a story that will stall mid sprint.

What they are assessing

Understanding of the flow model.

Model answer

There is no sprint boundary, so work flows continuously and testing happens when an item reaches the test column rather than within a time box. The practical differences are that there is no end of sprint crunch, which removes one of the main causes of compressed testing, and that work in progress limits make a testing bottleneck visible immediately rather than at a sprint review. Releases are decoupled from iterations, so regression and release readiness become continuous activities rather than scheduled ones.

What they are assessing

The core Kanban mechanism.

Model answer

A cap on how many items may be in a column at once. It matters to testing because the test column is almost always where work accumulates, and a limit makes that visible and forces a response. Without one, developers keep starting new work while testing falls behind, and the imbalance only surfaces at the end. With one, the limit is reached and the team must decide whether to help with testing or stop starting new work, which is precisely the conversation that needed to happen.

Likely follow-up

What should the team actually do when the testing column hits its limit?

What they are assessing

Flow metrics.

Model answer

Lead time is from the item being requested to being delivered, which is what a customer experiences. Cycle time is from work starting to being delivered, which is what the team controls. Both matter, and for testing the useful refinement is the time an item spends in the testing state, because a long and variable testing time points at a bottleneck, an environment problem or a story arriving untestable. Tracking that separately usually shows that the delay is waiting rather than testing, which changes what you fix.

What they are assessing

Reading a flow chart diagnostically.

Model answer

It shows the quantity of work in each state over time as stacked bands. A band that widens over time is a state where work is accumulating faster than it leaves, and when that band is testing it means the team is producing faster than it can verify. The width of the band is the queue, and the horizontal distance through the bands is the cycle time. It is a better argument than a complaint, because it shows the accumulation as a trend rather than as an opinion about one bad week.

What they are assessing

The most practically important question in the bank.

Model answer

By starting before the code exists and finishing before the sprint ends. That means reviewing acceptance criteria during refinement, writing test ideas while development is in progress, testing each story as it becomes available rather than batching, and keeping regression automated so it does not consume the window. It also requires the team to deliver stories throughout the sprint rather than all on day nine, which is a team agreement rather than something testing can fix alone. The definition of done including testing is the lever that makes it stick.

Likely follow-up

What do you do when every story arrives on the last two days anyway?

What they are assessing

Handling a very common situation.

Model answer

The story is not done, and I would say so rather than let it be accepted. The useful response is not to argue but to state precisely what was and was not verified and what risk that leaves, so the product owner decides knowingly. The story then carries to the next sprint, which is uncomfortable and correct, because accepting untested work makes velocity meaningless and moves the risk somewhere nobody is tracking. If this happens repeatedly, it is a retrospective topic about flow rather than a per-story negotiation.

Trap to avoid

Agreeing to mark it done and test it next sprint. It is the single most common way a team accumulates untested work while reporting a healthy velocity.

What they are assessing

Recognition of the most common agile anti-pattern.

Model answer

By changing how work flows rather than by asking testers to work faster. Smaller stories, so each is finished and verified quickly rather than arriving as a large block. Developers and testers working on the same story concurrently, with the tester testing part of it while the rest is built. Pairing on acceptance criteria before the code starts. A work in progress limit on the development column so the team cannot run ahead. And unit and integration coverage from developers so the end of sprint testing is exploratory and risk based rather than the first time anything is verified.

What they are assessing

Practical unblocking.

Model answer

By testing what exists rather than waiting. Stubbing or mocking the dependency at the boundary lets the story be verified in isolation, which covers most of its behaviour. API level testing often works before the interface exists. Contract testing verifies the integration assumption without the other side being complete. Where none of that is possible, the honest answer is that the stories should not have been planned into the same sprint separately, and raising that in planning is the real fix. What I would avoid is leaving it untested and marking it done on the assumption it will be covered later.

What they are assessing

A model interviewers frequently ask about by name.

Model answer

A model from Brian Marick, popularised by Lisa Crispin and Janet Gregory, classifying tests on two axes: whether they are business facing or technology facing, and whether they support the team or critique the product. Quadrant one is technology facing and supports the team: unit and component tests. Quadrant two is business facing and supports the team: functional tests, examples, story tests and prototypes. Quadrant three is business facing and critiques the product: exploratory, usability and acceptance testing. Quadrant four is technology facing and critiques the product: performance, security, load and the other quality attributes.

Likely follow-up

Which quadrants are typically automated and which are not?

What they are assessing

Whether the model is applied or only recited.

Model answer

As a coverage checklist rather than a sequence, since the numbering implies no order. Its practical value is exposing gaps: most teams have reasonable coverage in quadrants one and two, because those are the tests that get automated, and very thin coverage in three and four, because exploratory and non functional work is the first thing squeezed. Walking a team through the quadrants usually surfaces that nobody has considered performance or security at all, which is a more productive conversation than asking whether testing is sufficient in the abstract.

What they are assessing

Precision about the model.

Model answer

Quadrant three, business facing and critiquing the product, because it evaluates whether the product is actually good rather than confirming it matches an expectation. That placement matters because it is the quadrant automation cannot serve: automated tests confirm what someone already knew to check, while exploratory testing discovers what nobody anticipated. Teams that interpret agile as automate everything end up with quadrants one and two well covered and quadrant three empty, which is why they keep being surprised in production.

What they are assessing

Basic vocabulary.

Model answer

A short description of a feature from the user perspective, conventionally written as: as a role, I want a capability, so that I get a benefit. The format is a convention rather than a requirement, and the important part is the last clause, since the benefit is what tells you whether the implementation actually solved anything. A story is intended as a placeholder for a conversation rather than a complete specification, which is why acceptance criteria and refinement exist alongside it.

What they are assessing

Story quality, from the tester perspective.

Model answer

Independent, Negotiable, Valuable, Estimable, Small, Testable. As a tester the one I weight most is Testable, since a story nobody can describe a verification for is a story that will stall. Independent matters because dependent stories cannot be delivered or tested in isolation. Small matters because large stories are the main cause of the end of sprint crunch. Using it as a checklist during refinement is a concrete way to improve stories before they reach a sprint rather than complaining about them afterwards.

Likely follow-up

What would you do with a story that fails the Testable criterion?

What they are assessing

The artefact a tester depends on most.

Model answer

Specific, observable and agreed before development starts. Each criterion should describe a condition that can be demonstrated, not a quality that must be judged. They should cover the main flow and the significant alternatives, including at least the important error cases, which is where thin criteria usually fail. They are not a complete test specification and should not try to be, since the tester will design more cases than the criteria list. The test I apply is whether a developer, a tester and the product owner would all demonstrate the same thing to prove it is met.

What they are assessing

Collaborative refinement.

Model answer

A conversation between a business representative, a developer and a tester before a story is built, to agree what it means and what done looks like. Each brings a different question: the business asks what the user needs, the developer asks how it will be built, and the tester asks how it could fail and how we would know it works. The tester question is the one most often missing and usually the one that changes the story, because the error and edge cases are rarely in the original description.

What they are assessing

A distinction candidates frequently blur.

Model answer

TDD is a developer practice: write a failing unit test, make it pass, refactor, driving design at the code level. ATDD is acceptance test driven development, where the team agrees acceptance tests before implementation so the criteria are concrete and shared. BDD is a collaboration practice focused on discovering behaviour through conversation and expressing it in a shared language, often but not necessarily using Gherkin. The common confusion is treating BDD as a tooling choice, when writing Gherkin after the code is written is automation with different wording rather than BDD.

Trap to avoid

Describing BDD as using Cucumber. The tool is incidental; the practice is having the conversation before the code exists.

What they are assessing

The main quality lever available to a tester in agile.

Model answer

A shared checklist every item must satisfy before it is called complete, applying to all work rather than being negotiated per story. From a testing standpoint I would insist on: acceptance criteria verified by someone other than the author, automated tests written and passing, no open defects above an agreed severity, regression impact considered, and the change deployed to a shared environment rather than working locally. It matters because without it a story is done when a developer says so, and testing becomes a negotiation every sprint rather than a standard.

Likely follow-up

Who owns the definition of done, and can a product owner override it?

What they are assessing

The upstream equivalent.

Model answer

A checklist an item must satisfy before being pulled into a sprint: acceptance criteria written, dependencies identified, designs available, sized, and testable. It helps testing because the most expensive problem in a sprint is a story that cannot be tested when it arrives, usually because nobody agreed what correct looks like. Insisting on testability at the ready stage costs a conversation; discovering the ambiguity on day eight costs the sprint. The caution is that an over-strict definition of ready can recreate a requirements phase, so it should be short.

What they are assessing

Handling pressure on the standard.

Model answer

By making the specific gap and its consequence visible rather than citing the rule. If the gap is that the regression impact was not checked, I would say what that means in practice: we do not know whether this affected the three areas that share this code. Then the decision is theirs, recorded, with the follow-up work made explicit rather than assumed. What I would resist is an informal exception becoming the norm, because a definition of done that is waived whenever it is inconvenient has already stopped functioning, and the right venue for that pattern is the retrospective.

What they are assessing

The structural argument.

Model answer

Because the regression surface grows every iteration while the iteration length stays fixed. Manual regression that takes two days is manageable in sprint three and impossible by sprint twenty, so the cost curve makes it a mathematical certainty rather than a preference. Automation also enables the fast feedback agile depends on: a team cannot integrate continuously if verifying a change takes a day. The point worth adding is that this is an argument for automated regression specifically, not for automating everything.

Likely follow-up

What should not be automated even in an agile team?

What they are assessing

Timing within the sprint.

Model answer

Within the same sprint as the story, as part of the definition of done, rather than as a follow-up task in a later sprint. The reason is that deferred automation does not get written: the next sprint has its own stories, and an automation backlog accumulates until someone proposes a dedicated sprint for it that never arrives. Writing it in sprint also means the developer and tester are both still holding the context. The practical compromise where a story is unstable is to automate once it has settled, but with a stated boundary rather than an open deferral.

Trap to avoid

Planning to automate a sprint behind. It is the most common way teams end up with a large manual regression suite and an automation backlog nobody will ever clear.

What they are assessing

Judgement about when automation pays.

Model answer

By automating at the level least affected by the change. If the interface is in flux but the business logic is settled, API or component level tests are stable and worth writing immediately, while interface tests would be rewritten three times. If the behaviour itself is still being decided, automation of any kind is premature and exploratory testing is the better investment. The judgement is about the cost of rewriting against the cost of manual repetition, and the honest answer in a genuinely unstable area is to wait and say so rather than produce tests that will be deleted.

What they are assessing

Automation strategy.

Model answer

The model says many fast unit tests, fewer integration tests and a small number of end to end tests, because cost and fragility rise with scope. It applies particularly in agile, because the suite must run fast enough to give feedback within the development cycle, and an inverted pyramid of hundreds of end to end tests produces a suite too slow to run per commit and too fragile to trust. The qualification worth making is that the pyramid describes automated checks only and says nothing about exploratory testing, which does not fit the shape at all.

What they are assessing

The practice automation serves.

Model answer

Developers integrating work into a shared branch frequently, with each integration verified by an automated build and test run. What it requires from testing is a suite fast enough to run on every commit, reliable enough that a red build means something, and broad enough that passing gives real confidence. The second of those is the one that fails in practice: a suite with intermittent failures trains the team to ignore red, at which point continuous integration has stopped providing any signal regardless of how often it runs.

Likely follow-up

What do you do about a flaky test that fails one build in ten?

What they are assessing

A distinction often stated loosely.

Model answer

Continuous delivery means every change that passes the pipeline is releasable, with the decision to release remaining a human one. Continuous deployment means every change that passes is automatically released to production with no manual gate. The testing implication of the second is substantial: there is no opportunity for a manual verification step before release, so the automated suite is the only gate, and the compensating practices become production monitoring, feature flags and the ability to roll back quickly.

What they are assessing

A genuinely different model.

Model answer

The emphasis moves from gating to detection and recovery. Pre-release testing still matters but cannot be the whole strategy, so investment shifts toward observability, synthetic monitoring in production, and progressive delivery techniques such as canary releases and feature flags that limit exposure. Testing in production becomes legitimate rather than a failure, and the key metric becomes time to detect and time to recover rather than defects found before release. The role of the tester shifts toward designing those safety mechanisms rather than executing a final check.

What they are assessing

A practice with real testing consequences.

Model answer

A switch that enables or disables functionality at runtime, allowing incomplete work to be merged and released without being visible. It helps testing by decoupling deployment from release, so a feature can be enabled for internal users first. It complicates testing because every flag doubles the configuration space, and a system with ten flags has a combinatorial number of states nobody is testing. The practical discipline is to test the flag on and off for the paths that matter, and to remove flags once a feature is fully released, since stale flags are where this becomes unmanageable.

Trap to avoid

Treating flags as free. Each one is a branch in behaviour, and teams routinely accumulate dozens that nobody has removed or tested in combination.

What they are assessing

The structural problem of agile testing.

Model answer

Automate the regression suite and keep it maintained as part of the definition of done, because manual regression grows linearly while the sprint stays fixed. Alongside that, apply risk based selection rather than running everything: the critical paths every build, the areas touched by this sprint in depth, and a sampled rotation across the rest. And prune actively, since a suite that only ever grows becomes slow enough that nobody runs it, at which point the coverage is theoretical.

What they are assessing

A principle with a practical consequence.

Model answer

Running the same tests repeatedly stops finding new defects, because the ones those tests detect have already been fixed. In agile it applies strongly, because an automated regression suite by its nature asks only the questions it was written to ask, and it is run many times. The consequence is that automated regression must be complemented by exploratory testing of each new increment, and that the suite itself needs to evolve rather than being treated as finished. A team relying solely on a stable automated suite will see its defect detection rate fall while believing coverage is improving.

What they are assessing

Risk based selection.

Model answer

By impact rather than habit. What the sprint changed directly, what shares code or data with it, what calls it, and what historically breaks when that area moves, since defect history is a strong predictor. Then weighted by business criticality, so the payment path is covered even on an apparently unrelated change. Where the sprint touched shared infrastructure or a cross-cutting component, that reasoning breaks down and a full regression is the honest answer. The output should be a tiered set rather than a binary decision about running everything.

What they are assessing

A principle often repeated without substance.

Model answer

That quality is not delegated to a testing function that inspects at the end. Developers write unit and integration tests, the product owner defines acceptance criteria clearly, and testers contribute technique, risk thinking and exploratory skill. It does not mean everyone tests equally or that testing expertise is unnecessary, which is the misreading that leads teams to remove testers and then discover what they were doing. The practical test of whether a team believes it is whether a production defect is treated as a team failure or as something testing missed.

Likely follow-up

How do you build that culture on a team that currently throws work over the wall?

What they are assessing

A question with a confident wrong answer available.

Model answer

Usually yes, though not in the role of a gate. The skills that make a good tester, meaning risk assessment, test design, exploratory technique and the habit of asking how this could fail, are genuine specialisms that developers largely do not have, in the same way testers largely cannot architect a system. Teams that remove testers typically see unit coverage stay fine while exploratory and integration defects rise, because the work the tester was doing was never unit testing. The caveat is that the tester must be embedded in the team rather than a separate function receiving completed work.

What they are assessing

Collaboration in concrete terms.

Model answer

Pairing on acceptance criteria before the code starts, which prevents more defects than any amount of testing afterwards. Reviewing unit test coverage for the edge cases developers routinely under-test, since they test what they built rather than what could break. Sharing the failure patterns I see, so the same class of defect stops recurring. Pairing on debugging a failure rather than handing it over. And being available during development rather than waiting for a handover, so a question takes two minutes instead of becoming a defect.

What they are assessing

Role expectations.

Model answer

Deep expertise in one area with working breadth across others, so a tester has depth in test design and exploratory technique plus enough breadth in automation, APIs, databases and the domain to contribute elsewhere. It is relevant because agile teams are small and cross-functional, so someone who can only execute manual scripts has narrow applicability within a sprint. It is also the honest answer to the automation question: a tester who cannot read code is increasingly limited, without needing to be a developer.

What they are assessing

A metric frequently misused.

Model answer

The amount of work a team completes per sprint, measured in story points. Testing must be included in the estimate, because a story is not complete until it is verified, and teams that estimate development effort alone systematically overcommit and then compress testing to compensate. Velocity is useful for forecasting within a team and useless for comparing teams, since points are relative. It is also not a productivity measure, and treating it as one reliably produces inflation rather than improvement.

Trap to avoid

Treating velocity as a performance target. The moment it becomes one, estimates grow and the metric stops meaning anything.

What they are assessing

Metric selection with judgement.

Model answer

Defect escape rate, meaning how many defects reach production, because that measures the outcome the function exists to produce. Time to detect and time to fix. The proportion of stories that fail acceptance, which indicates how well refinement is working. Automated test coverage of critical paths, not as a percentage target but as a gap list. And build stability, since a frequently red or flaky pipeline is a leading indicator of everything else. What I would avoid is defects found per tester, which rewards volume, punishes prevention, and falls when quality genuinely improves.

Likely follow-up

Why is defect count a particularly bad metric in an agile team?

What they are assessing

Outcome thinking.

Model answer

Primarily by what escapes rather than by what is found, since finding defects late is not a success. Beyond escape rate, I would look at where defects originate, because a pattern of requirement misunderstandings points at refinement while a pattern of regression points at automation coverage. Cycle time through the testing state shows whether testing is a bottleneck. And the proportion of defects prevented, which cannot be measured directly but shows up as a falling defect count alongside stable or increasing delivery, which is the shape you want.

What they are assessing

Awareness beyond a single team.

Model answer

The hard problems move to the boundaries. Individual teams can test their own increments, but the integration between them, the end to end journeys crossing team ownership, and the shared environments become nobody obvious responsibility. So the additions are cross-team integration testing, contract testing so teams can verify assumptions without waiting for each other, a shared environment strategy, and alignment on the definition of done so one team shipping untested work does not break another. Communities of practice also become useful for keeping technique consistent without centralising the function.

Likely follow-up

Who should own the end to end journey that crosses four teams?

What they are assessing

Familiarity with the common scaled framework.

Model answer

The Scaled Agile Framework organises teams into an Agile Release Train delivering on a Program Increment cadence, typically eight to twelve weeks, with PI Planning aligning the teams. For testing the relevant parts are the system team, which supports integration and the shared environments, continuous integration across teams being explicitly part of the model, and the Innovation and Planning iteration, which teams often misuse as a testing catch-up. The criticism worth being able to voice is that the PI cadence can reintroduce a release-phase feel, with integration testing concentrated near the end.

What they are assessing

Organisational design.

Model answer

Testers embedded in the teams rather than pooled, because quality cannot be achieved by a function receiving completed work. Alongside that, a small central capability for the things that do not fit one team: the shared automation framework, cross-team integration and end to end journeys, test environments and data, and performance and security specialisms too scarce to place in every team. Plus a community of practice so technique and tooling stay consistent without central control. The failure modes at both extremes are real: a central QA department recreates the gate, and fully independent teams produce ten incompatible frameworks.

What they are assessing

Recognition of a common compromise.

Model answer

A sprint dedicated to stabilisation, bug fixing and testing before a release. It is a problem because it means the preceding sprints did not produce potentially shippable increments, so the definition of done was not actually being met, and it reintroduces a testing phase under a different name. It also tends to become permanent, since a team that expects a hardening sprint stops treating the definition of done as binding. Where one is genuinely needed, the useful response is to treat it as a signal for the retrospective rather than as a planning technique.

What they are assessing

A pattern many teams drift into.

Model answer

It is waterfall with a shorter cycle. Feedback reaches developers after they have moved on, so the context is lost and the fix is more expensive. Stories are marked done while unverified, so velocity becomes meaningless and the increment is not shippable. Defects accumulate in a parallel stream that is never prioritised against new work. And the tester is permanently working on something different from everyone else, which removes the collaboration the model depends on. The underlying cause is usually stories being too large or the team starting more than it can finish.

Trap to avoid

Presenting it as a reasonable adaptation. Interviewers ask this specifically to see whether you recognise it as a failure mode rather than a working arrangement.

What they are assessing

Diagnosis of a systemic problem.

Model answer

Where the time actually goes, because squeezed testing is a symptom with several causes. If stories all complete on the last two days, it is a flow problem and the fix is smaller stories and work in progress limits. If regression consumes the window, it is an automation problem. If testers are rebuilding environments or data, it is an infrastructure problem. If testing effort is not in the estimates, the team is overcommitting by design. Each has a different fix, and treating the symptom by asking testers to work faster addresses none of them.

What they are assessing

Critical judgement.

Model answer

Stories accepted without being verified. A definition of done that is routinely waived. Testing happening after the sprint rather than within it. Retrospectives that produce the same actions repeatedly without change. A product backlog that is a requirements document split into fixed scope. Velocity used as a performance target. And no automated regression, which makes genuine iteration impossible regardless of the ceremonies being observed. The common thread is that the events are held while the practices that make them meaningful are absent.

What they are assessing

A judgement call teams disagree about.

Model answer

Usually not by raising a formal defect, because a problem found while the story is still being built is unfinished work rather than a defect. Raising tickets for it inflates defect metrics, creates administration and makes a careful team look worse than a careless one. A conversation or a note on the story is enough. Once the story is done or released, anything found afterwards is a defect, because it is a failure of something previously declared complete. The boundary worth agreeing explicitly with the team is where done falls, since the rule hinges on it.

What they are assessing

Backlog handling.

Model answer

Into the product backlog, prioritised against new work by the product owner rather than held in a separate defect list that never competes with features. The reason is that a parallel defect backlog is never prioritised and grows indefinitely, while a defect sitting in the product backlog has to be explicitly ranked below a feature, which is a visible decision. The exception is anything above an agreed severity, which should block the story or the release rather than being deferred at all.

What they are assessing

Ownership, which teams argue about.

Model answer

Whoever is best placed, with the suite owned by the team rather than by the tester. Unit and integration tests are developer work by necessity. Acceptance and end to end tests are often written by testers, and are better when written collaboratively, because a developer writes more maintainable code and a tester chooses better cases. What does not work is automation owned entirely by one person, because it becomes a bottleneck and the rest of the team feels no responsibility when it breaks, which is how suites end up permanently red.

Likely follow-up

What happens when the automation suite is owned by one person who then leaves?

What they are assessing

Build health.

Model answer

Treat it as the highest priority, because a suite nobody trusts provides no protection and the team has already started ignoring it. Practically: separate genuine failures from flaky ones with data rather than impression, fix or quarantine the flaky ones with an owner and a deadline so the signal is restored quickly, and establish an agreement that a red build is fixed before new work continues. The cultural part matters more than the technical part, since the real failure is the moment the team starts assuming red means nothing.

What they are assessing

Protecting a practice that gets squeezed.

Model answer

By making it visible and planned rather than treating it as what happens if there is time. Session based test management gives it a charter, a time box and an output, which makes it reportable and therefore defensible. Including exploratory sessions in the sprint as explicit work means they are accounted for in capacity. And framing the argument correctly helps: automated tests confirm what we already knew to check, so without exploratory testing the team only ever verifies its own existing assumptions, which is why automation-heavy teams keep being surprised by things nobody wrote a test for.

What they are assessing

Event purpose.

Model answer

A working session where the increment is inspected with stakeholders and the backlog is adapted based on feedback. It is not a presentation or a sign-off gate. A tester contributes by making sure what is demonstrated is actually the tested increment rather than a local build, by being honest about what was verified and what was not, and by capturing the feedback that implies new test conditions. The failure mode is a polished demo on a developer machine, which demonstrates nothing about whether the increment works where it will run.

What they are assessing

Quadrant four, which teams routinely neglect.

Model answer

By treating them as acceptance criteria on stories where they matter, rather than as a separate phase at the end. Performance budgets on specific operations, security considerations on anything touching authentication or data, accessibility criteria on user interface stories. Automated checks for the ones that can be automated, running in the pipeline so a regression is caught immediately. And periodic deeper assessment for the areas that need specialist work, scheduled as its own backlog item. The pattern that fails is leaving all of it until a pre-release phase, which is how it gets dropped.

Likely follow-up

How would you make a performance budget a practical sprint criterion?

What they are assessing

Splitting, which is a testing concern as much as a planning one.

Model answer

By splitting it, and testers are often best placed to suggest how, because the natural seams are frequently about verifiable behaviour. Useful splits are by workflow step, by business rule variation, by happy path first with error handling following, by data type, or by interface versus service. What does not work is splitting horizontally by layer, so the front end is one story and the back end another, because neither is independently valuable or testable. If the story genuinely cannot be split, that is worth saying, but it is rarer than teams assume.

What they are assessing

Interpersonal judgement.

Model answer

Privately, specifically and with examples, framed as a shared problem rather than a performance complaint. Often the underlying cause is something addressable: unclear acceptance criteria, no local environment to check against, or time pressure, and asking rather than telling surfaces that. If it continues, I would stop handling it one defect at a time and bring the pattern to the retrospective or the lead with data: how many were returned, what the common cause was, and what it cost in rework. Escalating before having the conversation is what marks someone out as difficult to work with.

What they are assessing

Pipeline design.

Model answer

On every commit: unit tests, a fast integration subset and a small smoke suite, short enough that people wait for it, which in practice means under about ten minutes. Nightly or on a schedule: the full regression suite, cross-browser and cross-device coverage, performance checks and anything data heavy. The design work is in keeping the fast set curated rather than letting it accumulate, and the discipline is that a nightly failure gets triaged the next morning with an owner, because a scheduled suite nobody reads creates the impression of coverage without the substance.

What they are assessing

Communication in a different shape.

Model answer

Continuously and in terms of risk rather than progress through a plan. On the board, so the state of each story is visible without a report. In the daily scrum, where blockers and risks are raised as they arise rather than accumulated. And at the sprint review, in terms of what was verified, what was not, and what that means. The thing to avoid is recreating a weekly status report with percentages, because a number like eighty percent of tests executed implies a fixed denominator that does not exist and tells nobody what risk remains.

What they are assessing

Awareness of a force that shapes quality.

Model answer

Accumulated shortcuts in design, code or tests that make future change slower and riskier. A tester should care because it shows up as rising regression risk, as areas that break whenever anything near them changes, and as a growing proportion of defects concentrated in the same modules. Testers often have the best evidence for it, since defect clustering data points directly at where the debt is. Making that visible is one of the more useful things a tester can do, because technical debt arguments usually fail for lack of evidence rather than lack of agreement.

What they are assessing

A nuanced infrastructure question.

Model answer

Nothing inherently, and it is often necessary, but it becomes a problem when it is the only place anything is verified and it differs from production. The failure modes are that developers cannot reproduce what testers see, that the environment drifts in configuration and data until results from it mean little, and that it becomes a queue which serialises the team. The better pattern is ephemeral environments created per branch or per story where the architecture allows, with a stable shared environment reserved for integration and performance work.

What they are assessing

A specific and commonly debated inclusion.

Model answer

Yes for the levels that are practical within the sprint, which normally means unit and integration coverage plus acceptance tests for the new behaviour. Including it is what prevents automation debt accumulating, since anything deferred to a later sprint competes with that sprint stories and loses. Where I would be careful is mandating end to end automation for every story, because some stories do not warrant it and a blanket rule produces a slow suite full of low value tests. The criterion I prefer is that the appropriate level of automated coverage exists, agreed story by story.

What they are assessing

A technique specific to multi-team delivery.

Model answer

Testing the agreement between a consumer and a provider service in isolation, with the consumer defining expectations and the provider verifying it meets them, so neither needs the other deployed. It matters in scaled agile because the alternative is integrated end to end testing across teams, which requires everything to be deployed together and reintroduces the coordination agile was meant to remove. Contract testing lets teams deploy independently while still catching the integration breakages that would otherwise only appear in a shared environment.

Likely follow-up

What does contract testing not cover?

What they are assessing

The flow principle.

Model answer

Work is pulled by the next stage when it has capacity, rather than pushed when the previous stage finishes. For testing it changes the dynamic: instead of development pushing completed stories into a testing queue regardless of capacity, testing pulls when ready and the development column fills, which makes the imbalance visible upstream. That visibility is the point, because the team then has to decide whether to help with testing or stop starting new work, rather than letting the queue grow invisibly.

What they are assessing

Influence.

Model answer

By quantifying the alternative rather than arguing for it as good practice. Manual regression takes a measurable number of hours per sprint, and that number grows every sprint, so the cost of not automating is a forecastable and rising line. Against that, the automation effort is one-off per test. I would also point at the delivery consequence rather than the testing one, since teams accept slower releases and later feedback as a cost more readily when it is framed as throughput. And I would propose incremental automation of the highest value paths rather than asking for a dedicated sprint, which rarely gets approved.

What they are assessing

Event purpose and contribution.

Model answer

A short daily synchronisation for the developers to inspect progress toward the sprint goal and adapt the plan, not a status report to a manager. A tester contributes what affects the team plan: what is blocking testing, which stories are waiting for verification, any risk that has emerged, and anything needed from someone else. What is not useful is listing tests executed, which tells the team nothing actionable. The most valuable thing a tester can raise is usually a dependency or a blocker, because that is what the event exists to surface.

What they are assessing

Practical application of the model.

Model answer

Quadrant four, the technology facing quality attributes: performance, security, reliability and the other non functional concerns. The consequence is that they are discovered in production, where they are most expensive and most visible. The reason they are neglected is structural rather than negligent: they do not fit neatly into a story, they need specialist skill, and nothing on the board represents them, so they are never prioritised against features. The remedy is to attach specific non functional criteria to the stories where they matter, so they become part of done rather than a separate effort.

What they are assessing

Change management.

Model answer

Incrementally and by demonstrating value rather than by announcing a new process. I would start with the highest leverage change, which is getting the tester into refinement so ambiguity is caught before code exists, because it produces visible results within a sprint or two. Then automated regression on the critical paths, which is what makes iteration sustainable. Then the definition of done, once there is enough trust for it to be agreed rather than imposed. What I would not do is start by removing the test plan and the documentation, because that reads as removing rigour and creates resistance to everything that follows.

Likely follow-up

What would you expect to be the hardest change for a waterfall-trained team?

What they are assessing

A popular concept, tested for depth.

Model answer

Moving testing activity earlier: reviewing requirements, contributing to acceptance criteria, testing components as they are built, and automating checks that run on commit. It works because defects cost more the later they are found. Its limits are real: some defects only appear in an integrated system with production-like data and realistic concurrency, so shifting left does not remove the need for system level and exploratory testing. A team treating shift left as a reason to cut later testing usually finds the gap in production, which is why it is an addition to the lifecycle rather than a redistribution of fixed effort.

What they are assessing

A practical constraint that limits iteration speed.

Model answer

By making it reproducible rather than curated. Data created by script or API as part of test setup, so a test establishes its own preconditions and is independent of whatever state the environment is in. That matters more in agile than elsewhere because environments are refreshed and shared frequently, and hand-built data is destroyed each time. The alternative, a maintained golden data set, becomes a bottleneck and a source of inter-test coupling. Where production-like data is genuinely needed, masked copies with crafted edge cases added is the usual compromise.

What they are assessing

Reading a standard chart with a QA eye.

Model answer

The informative pattern is the shape rather than the endpoint. A line that stays flat for most of the sprint then drops sharply at the end almost always means stories were being completed by developers throughout but only closed once tested in the final days. That shape says testing is compressed into the last part of the sprint, which is where defects get missed and where the team has no time to react to what is found. A healthy chart steps down steadily, meaning work was genuinely finished, including verification, across the sprint.

What they are assessing

Progressive delivery.

Model answer

Releasing a change to a small proportion of users or servers first, monitoring, then widening if the signals are good. Testing relates to it in two ways. It reduces the consequence of an escaped defect, which changes the risk calculation on how much pre-release testing is proportionate. And it creates a new testing responsibility, because somebody has to define what signals indicate a problem and what thresholds trigger a rollback, which is test design applied to production telemetry rather than to a test environment.

What they are assessing

Constructive pushback.

Model answer

By agreeing with what they want, which is to know whether testing is working, and explaining why that number will not tell them. It rewards volume, so it encourages splitting one problem into five tickets and raising trivia, and it punishes the most valuable work, which is preventing defects before they exist. In agile it is worse still, because a tester contributing in refinement reduces the defect count by doing the job well, so success looks like failure. Then I would offer alternatives: escape rate, time to detect, the proportion of stories failing acceptance. Offering a replacement rather than only objecting is what makes the pushback land.

What they are assessing

A considered overall view.

Model answer

Testers involved before code exists, so most of their value is prevention rather than detection. Automated regression that the team trusts and maintains collectively, fast enough to run continuously. Exploratory testing planned and visible rather than squeezed into gaps. A definition of done that holds under pressure. Non functional criteria attached to stories rather than deferred. And production feedback closing the loop, so an escaped defect leads to a test and a process change rather than only a fix. The underlying signal is whether a production defect is discussed as a team failure or as something testing missed.

What they are assessing

A closing question revealing depth of experience.

Model answer

Keeping the waterfall testing model and shortening the timeline. The ceremonies get adopted, the terminology changes, and testing still happens at the end, now with two days instead of two weeks. Everything that follows comes from that: stories accepted untested, a growing manual regression burden, automation permanently deferred, and testers working on last sprint work while everyone else moves on. The change that actually matters is not the process framework, it is testers engaging before the code exists and the team treating verification as part of building rather than as a stage after it.