Agile and Scrum for testers

Foundations

1. How are Agile and Scrum different?

Agile describes values and principles for adapting delivery through feedback. Scrum is a framework with defined accountabilities, events and artifacts. A team using Jira and daily meetings is not automatically practising Scrum or getting useful feedback.

2. Where does a tester fit in a Scrum Team?

Scrum does not define a separate QA accountability. People who create the Increment are Developers, including specialists in testing. A tester contributes risk analysis, exploration and automation while quality remains a responsibility of the team.

3. What does the Product Owner decide?

The Product Owner is accountable for maximizing product value and ordering the Product Backlog. A tester supplies evidence about defects and user impact to inform those choices. Ordering work does not permit calling unfinished work Done.

4. What does the Scrum Master do for testing?

The Scrum Master helps the team understand Scrum and improve its effectiveness. They can help expose recurring environment blockers or a testing bottleneck. They are not a default approver who signs off every test case or assigns every task.

5. What are Scrum’s events?

The Sprint contains Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Teams also refine backlog items as an ongoing activity. Calling refinement a mandatory extra Scrum event confuses common practice with the framework.

6. What does a tester contribute to Sprint Planning?

Identify important risks, needed environments and data, and ways to establish that the selected work is Done. For a UPI refund story, discuss delayed callbacks as well as the happy path. Raise dependencies before the team forecasts more work than it can finish.

7. What should a tester say in the Daily Scrum?

Discuss progress toward the Sprint Goal and adapt the plan with the other Developers. A blocked test environment matters because it affects that plan, not because everyone owes a manager a personal status report. Take detailed debugging into a separate discussion.

8. How do Sprint Review and Retrospective differ?

The Review inspects the Sprint’s outcome with stakeholders and considers future adaptations. The Retrospective examines how the team worked and chooses improvements. Showing a feature and investigating why test data kept breaking are different conversations.

Stories, quality and estimation

9. Does Scrum require user stories?

No particular backlog-item format is mandated. User stories are a common way to discuss a user’s need and value. A technical item can still be clear and testable without forcing it into an artificial user persona.

10. What makes acceptance criteria testable?

They describe observable outcomes and relevant conditions. For OTP expiry, specify the validity period, how time is measured and what the user sees after expiry. “Works correctly” leaves both implementation and evaluation ambiguous.

11. How do acceptance criteria differ from the Definition of Done?

Acceptance criteria describe expectations for a particular item; the Definition of Done describes the quality state required of an Increment. A coupon story may meet its discount examples but still miss required security checks. Meeting only the story’s happy path is insufficient.

12. Who owns the Definition of Done?

Follow an organizational standard when one exists; otherwise the Scrum Team creates an appropriate Definition of Done. Developers must conform to it. Testers help make its evidence specific, such as required automated checks and treatment of unresolved critical risks.

13. What happens to work that misses Done?

It is not part of the Increment and returns to the Product Backlog for future consideration. Explain the remaining work and delivery impact transparently. A “testing complete next Sprint” label must not disguise unfinished work as a completed Increment.

14. What is a Definition of Ready?

Some teams use an agreement about useful input before taking work into a Sprint. It is not a required Scrum artifact or commitment. Use it to expose unknowns, not as a gate that prevents conversation until every detail is frozen.

15. How do testers participate in estimation?

Bring uncertainty about integrations, data, exploration and automation into the team’s sizing discussion. Relative sizing is an aid to planning, not an exact conversion into tester hours. Splitting an unclear refund feature may be more useful than arguing about one point value.

16. Does Scrum require story points or velocity?

No. Teams can use different forecasting approaches. If velocity is used, interpret it within that team’s own context; comparing teams or treating more points as better quality encourages distorted estimates.

Testing through the Sprint

17. How do you avoid testing only at the end of a Sprint?

Collaborate on examples before development, test small completed slices and provide feedback while changes are still easy to adjust. Pair on risky behavior rather than waiting for every screen. A queue of almost-finished stories is an early warning, not a normal QA phase.

18. What does shift-left mean in practice?

Move useful feedback earlier: discuss acceptance examples, review API contracts and run fast checks before integration. It does not remove production monitoring or exploratory testing later. Finding an unclear rounding rule before code is written is a concrete example.

19. What belongs in an Agile test strategy?

State major risks, test layers, data and environment needs, automation responsibilities and release evidence. Keep it easy to update as architecture changes. Agile does not mean discarding a strategy; it means avoiding a document that nobody uses to make decisions.

20. How do you choose what to automate?

Automate stable, repeated checks where fast reliable feedback has value. Put calculation rules below the UI where possible and reserve browser tests for important user journeys. Do not turn every exploratory observation into a fragile end-to-end script.

21. Is exploratory testing compatible with Scrum?

Yes. Use a focused charter, such as exploring retry behavior during a payment timeout, and retain observations and evidence. Exploration complements automated examples by investigating unexpected behavior. It is neither unplanned clicking nor a substitute for repeatable regression checks.

22. How do you handle regression within a Sprint?

Run targeted checks during development and a broader reliable suite at appropriate integration points. Expand coverage around changed risks and affected dependencies. Deferring all regression to a later hardening Sprint hides whether the current Increment meets Done.

23. What do you do when an environment blocks testing?

Explain what cannot be evaluated and its impact on the Sprint Goal, then work with the team on restoration or another valid test layer. A mock can unblock contract work but cannot prove the unavailable integration. Keep that evidence gap visible.

24. How should defects found during a Sprint be handled?

Assess their impact and agree the response with the team and Product Owner. A failure of the current item’s acceptance criteria is unfinished work, even if tracked as a separate defect. Unrelated older defects may enter the backlog with an explicit priority.

Interview scenarios and anti-patterns

25. A requirement changes mid-Sprint. What would you do?

Clarify the change and its impact on the Sprint Goal, scope and quality evidence. Developers and Product Owner can renegotiate scope as more is learned without endangering the Goal. Silently adding work while retaining the old forecast creates an unreliable plan.

26. Can a team release before the Sprint ends?

A usable Increment that meets Done can be delivered before Sprint Review. The Review is not a mandatory release approval gate. The organization may still have separate regulatory or operational release controls; describe those honestly.

27. What is wrong with separate development and testing Sprints?

It delays feedback and makes claims of completion hard to trust. Investigate why small slices cannot reach Done together: missing environments, excessive work in progress or unclear contracts. Improve the constraint rather than merely renaming the testing queue.

28. How do you respond to pressure to lower quality to finish?

Describe the missing evidence and user risk in concrete terms, then discuss reducing scope or changing the forecast. Do not silently redefine Done for one story. A smaller validated refund flow is more transparent than a larger feature marked complete without checks.

29. Which measures are useful for sprint testing?

Track information that changes decisions: aging blocked work, escaped defects with context, unreliable checks and time to useful feedback. Raw test-case counts do not establish risk coverage. A rise in escaped defects calls for investigation rather than blame or a target to log fewer bugs.

30. How would you explain an improvement in a retrospective?

Name the observed problem, its effect and one experiment with an owner and review point. For example, agree refund examples before development and inspect whether rework falls on the next related story. Do not claim a percentage improvement without measurements.

Likely follow-up: What if the experiment fails? Keep the evidence, adjust the approach and avoid treating the action item as permanent ceremony.

Practise it

Take one ShopLite checkout feature. Write acceptance examples, identify risks and explain the evidence required for Done before planning any automation.