Most Indian product companies and a large share of service-based projects now work in Agile, usually using the Scrum framework. In Agile, testing is not a phase that starts after development finishes. Testers are part of the team from day one, review requirements, write acceptance criteria with the product owner and test each story as soon as it is ready. This lesson shows you what that looks like in a real sprint.
Agile in One Paragraph
Agile delivers software in small, working increments, collects feedback quickly and adapts. The Agile Manifesto values individuals and interactions, working software, customer collaboration and responding to change. For testers this means shorter cycles, constant collaboration with developers, and a strong focus on regression because the product changes every few weeks.
Scrum Roles
| Role | Responsibility | How testers work with them |
|---|---|---|
| Product Owner (PO) | Owns the product backlog, defines and prioritises user stories | Clarify requirements, agree acceptance criteria, raise priority questions |
| Scrum Master | Facilitates Scrum events, removes blockers, coaches the team | Escalate blockers such as a broken test environment |
| Developers | Everyone who builds the increment, including testers | Testers are part of this group and share responsibility for quality |
The Scrum Guide calls everyone who builds the product a "Developer". In practice, companies still hire QA engineers, but within the team, quality is everyone's job.
Scrum Ceremonies (Events)
| Event | When | Tester's contribution |
|---|---|---|
| Sprint Planning | Start of sprint | Estimate testing effort, highlight test data and environment needs, flag risky stories |
| Daily Scrum | Every day, about 15 minutes | Share what you tested, what you will test today, and any blockers |
| Backlog Refinement | Mid-sprint, ongoing | Ask "what if" questions, identify edge cases, help write acceptance criteria |
| Sprint Review | End of sprint | Help demo completed stories; capture stakeholder feedback |
| Sprint Retrospective | After the review | Suggest process improvements, e.g. earlier builds or better test data |
User Stories and Acceptance Criteria
A user story describes a requirement from the user's point of view:
As a registered customer, I want to pay for my order using a UPI ID, so that I can complete checkout without entering card details.
Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. Acceptance criteria are the specific conditions a story must satisfy to be accepted by the product owner. They are the tester's most important input, because each criterion becomes one or more test cases.
Writing Acceptance Criteria in Gherkin
Many teams write acceptance criteria in Gherkin, a structured format using Given (context), When (action) and Then (outcome). It is readable by business people and can later be automated with BDD tools such as Cucumber.
Feature: Pay for an order using a UPI ID
Scenario: Successful payment with a valid UPI ID
Given the customer has items worth Rs 1,250 in the cart
And the customer is on the payment page
When the customer enters a valid UPI ID "priya@okbank"
And approves the collect request in the UPI app
Then the order status should be "Confirmed"
And an order confirmation SMS should be sent
Scenario: Invalid UPI ID format
Given the customer is on the payment page
When the customer enters the UPI ID "priya.okbank"
Then the error "Enter a valid UPI ID" should be displayed
And the Pay button should remain disabled
Scenario: Payment request expires
Given a collect request has been sent to the customer
When the customer does not approve it within 5 minutes
Then the payment status should be "Failed"
And the cart items should remain available for retryDefinition of Done (DoD)
The Definition of Done is a shared checklist that applies to every story. A story is not "done" just because the code is written. A typical DoD includes:
- Code is complete, peer-reviewed and merged.
- Unit tests are written and passing.
- All acceptance criteria are tested and passed in the QA environment.
- No open Critical or High defects against the story.
- Regression tests for impacted areas are passed.
- Test cases are updated in the test management tool.
- The product owner has accepted the story.
Acceptance criteria are specific to one story. The Definition of Done is common to all stories. Interviewers often ask for this difference.
A Tester's Day in a Two-Week Sprint
| Time | Activity |
|---|---|
| 9:30 AM | Check overnight automation results and new builds deployed to QA |
| 10:00 AM | Daily Scrum: update on stories under test and blockers |
| 10:30 AM | Test stories marked "Ready for QA"; log defects in Jira |
| 1:30 PM | Write test cases for upcoming stories; clarify doubts with the PO |
| 3:00 PM | Retest fixed defects; run regression on impacted modules |
| 4:30 PM | Backlog refinement or pairing with a developer on an edge case |
| 5:30 PM | Update Jira statuses and test execution results |
Shift-Left Testing
Shift-left means moving testing activities earlier in the life cycle. Instead of waiting for a build, testers review stories during refinement, question ambiguous requirements, write test cases before code is ready, and test APIs before the UI exists. A defect found in a requirement review costs minutes to fix; the same defect found in production can cost days and customer trust. Shift-left directly supports the testing principle "early testing saves time and money".
