Most modern teams work with Agile — a flexible approach where the product is built in small pieces and short cycles, rather than one giant push. The most common flavour is Scrum. For a tester, this means one thing: you don't wait for a finished product at the end — you work alongside development, from the very first day of the cycle.
Let's go through how Scrum is structured and where you fit in, so that on the job you understand what's happening around you and what's expected from you at every meeting.
Sprint and backlog
Work in Scrum is broken into sprints — short stretches, usually one or two weeks. During a sprint, the team picks a small set of tasks and gets them to done.
Where do the tasks come from? There's a backlog — a prioritised list of everything that needs to be done in the product. For each sprint, the team selects from the top of the backlog what they can realistically finish. Tasks are often written as user stories — a short description from the user's point of view: "As a customer, I want to pay for my order by card, so that I don't have to use cash."
The key idea for a tester: within a single sprint, a task travels the full journey — from discussion to done, including testing. Not "write it this sprint, test it next sprint" — everything at once.
Scrum ceremonies and your role in them
Scrum has several recurring meetings ("ceremonies"). Each one has a role for the tester:
- Planning. At the start of the sprint the team decides what to take on. Your job: figure out what and how you'll test, ask questions about the tasks, estimate what you can cover. This is often where you surface ambiguities in requirements.
- Daily (daily stand-up). A short daily check-in: "what I did, what I'll do, what's blocking me." You share what you're testing, where you're waiting on fixes, and what's blocking you.
- Review (demo). At the end of the sprint the team shows what was built. You've already verified it before the demo — no surprises should appear on the day.
- Retrospective (retro). The team talks about what went well in the process and what to improve. The tester raises quality issues: for example, "tasks arrive for testing on the last day — we don't have time."
Why testing happens alongside development
In the older waterfall approach testing was a separate phase at the end. In Agile that doesn't work — the cycle is too short. So testing is spread across the whole sprint:
- At the start you review tasks and ask questions (bugs in requirements are caught here).
- While the developer writes code, you prepare test cases and test data.
- As soon as a feature is ready — you check it right away, without waiting for the end of the sprint.
- Towards the end — regression: make sure the new work hasn't broken anything old.
The important takeaway: a tester and a developer are partners working side by side, not an assembly line where one hands off and the other receives.
Definition of Done — when a task is done
A useful concept is the Definition of Done (DoD) — a shared team checklist describing the conditions that must be met for a task to count as complete. "Tested" is usually on the list: for example, "code written, code review passed, tests passed, no high-priority bugs open."
For a tester, the DoD is protection: a task isn't "done" until it's been verified. It prevents untested work from shipping under deadline pressure.
Where this applies
Understanding Scrum helps you be more than "the person who gets tossed the finished thing" — you become a full member of the team. You know why each meeting exists and what to say in it; you join early and catch problems cheaply; you understand why testing throughout the sprint beats leaving everything to the last day. That's exactly the teamwork expected from a tester in a real job.
Where beginners stumble:
- Waiting until "everything is done" and ending up with all the work on the last day of the sprint. In Agile you need to jump in right away and test as features land.
- Staying silent in meetings. Planning and the daily are your chance to ask questions and flag blockers. Silence means problems surface late.
- Treating the developer as an opponent. You're working toward the same goal; a bug is not an accusation — it's a shared finding.
What to learn next. A lot in a sprint starts with tasks and their requirements. How to verify exactly what's described, and how to work with the people who write requirements — that's the topic of testing requirements.