Why this matters on the job
Almost every QA opening in India today, from large service companies running client projects to funded product startups in Bengaluru, Pune and Hyderabad, says "experience working in Agile/Scrum teams". In a Scrum team you do not wait for a "build drop" at the end of the month. You are inside the team from the first conversation about a feature, you test while the code is being written, and the team cannot call a story Done until testing agrees. Interviewers check this quickly with questions like "What do you do in sprint planning?" or "What is in your Definition of Done?". Candidates who answer with real examples stand out from those who only memorised the Scrum Guide.
Throughout this course you will work on ShopEasy, a sample e-commerce web app. To give us a real, clickable system to test, ShopEasy is played by the public demo store saucedemo.com (login standard_user / secret_sauce). By the end of the course you will have run two full sprints for it in Jira.
Concepts
Agile in one minute
Agile is a mindset described by four values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. For testers this means: talk to people early, test small increments continuously, and expect requirements to change between sprints.
Scrum: accountabilities, events and artifacts
The 2020 Scrum Guide defines three accountabilities: Product Owner (owns and orders the Product Backlog), Scrum Master (coaches the team and removes impediments) and Developers (everyone who builds the increment). Testers are part of the Developers. There is no separate "QA team" inside Scrum; quality is a whole-team responsibility, and you are the person who brings the testing skill to that team.
| Event | Typical timebox (2-week sprint) | What the tester actually does |
|---|---|---|
| Sprint Planning | Up to 4 hours | Asks testability questions, adds testing effort to estimates, creates test sub-tasks, flags stories that are not Ready |
| Daily Scrum | 15 minutes | Shares testing progress against the Sprint Goal, raises blockers (no build, test data missing, environment down) |
| Backlog Refinement (ongoing activity) | About 10% of team capacity | Reviews upcoming stories, drafts acceptance criteria and scenarios, joins three amigos sessions |
| Sprint Review | Up to 2 hours | Helps demo tested stories, shares quality status and known issues honestly |
| Sprint Retrospective | Up to 1.5 hours | Brings data: bugs reopened, late builds, escaped defects; proposes one concrete improvement |
The three artifacts each have a commitment: the Product Backlog has a Product Goal, the Sprint Backlog has a Sprint Goal, and the Increment has the Definition of Done.
Definition of Ready vs Definition of Done
| Definition of Ready (DoR) | Definition of Done (DoD) | |
|---|---|---|
| Question it answers | Can the team start this story? | Can we call this increment finished? |
| Applies to | A backlog item before planning | Every increment / story at the end |
| Official in Scrum Guide? | No, a popular team practice | Yes, a formal commitment |
| Tester's contribution | Acceptance criteria are testable, test data and environment are known | Tests executed, no open critical bugs, regression passed, automation updated |
Testing in Agile vs traditional projects
- Shift-left: review stories and design tests before code exists, so defects are prevented rather than found late.
- Continuous testing: each story is tested as soon as it is deployed to the QA environment, not in a final testing phase.
- Test pyramid: many fast unit tests, fewer API/service tests, a small set of UI end-to-end tests, plus focused exploratory testing.
- Agile testing quadrants: a simple way to plan test types: technology-facing tests that support the team (unit, component), business-facing tests that support the team (story tests, examples), business-facing tests that critique the product (exploratory, usability, UAT), and technology-facing tests that critique the product (performance, security).
Hands-on Lab: Set up the ShopEasy team's way of working
You will produce a one-page QA Working Agreement that you will reuse in every later lesson. Use Google Sheets or Google Docs (free) or any spreadsheet tool.
- Open saucedemo.com and spend 10 minutes exploring as
standard_user: login, product list, sorting, product details, cart, checkout (3 steps) and logout. Write down the 6 to 8 features you see. This is the ShopEasy scope. - Create a sheet named
ShopEasy-Sprint-Calendar. Lay out a 2-week sprint from Monday of Week 1 to Friday of Week 2. Fill in: Sprint Planning (Day 1, 10:00-12:00), Daily Scrum every day at 10:00 for 15 minutes, Backlog Refinement (Day 6, 1 hour), Sprint Review (Day 10, 15:00) and Retrospective (Day 10, 16:30). - Next to each event, write two or three concrete actions you as the tester will take (use the table above as a starting point, but make it specific to ShopEasy, for example: "In planning, ask how coupon codes interact with tax on the order summary page").
- Write a Definition of Ready for ShopEasy stories. Start from the sample below and adapt at least two items.
- Write a Definition of Done. Make sure at least four items are about quality and testing.
- Practise a Daily Scrum update out loud, under 60 seconds, using the template below. Record it on your phone and listen back: did you mention the Sprint Goal and any blocker clearly?
- Map the ShopEasy checkout feature onto the four testing quadrants: list at least one test idea per quadrant.
SHOPEASY - DEFINITION OF READY (story level)
[ ] Story follows 'As a <user>, I want <goal>, so that <value>'
[ ] Acceptance criteria written and reviewed by PO, Dev and QA (three amigos)
[ ] UI design / API contract attached or linked
[ ] Dependencies identified (payment sandbox, test data, other teams)
[ ] Test data needs listed (users, products, coupon codes)
[ ] Estimated in story points, including testing effort
[ ] Small enough to finish and test within one sprint
SHOPEASY - DEFINITION OF DONE (increment level)
[ ] Code reviewed and merged to main; build deployed to QA environment
[ ] Unit tests written and passing in CI
[ ] All acceptance criteria verified; test cases linked to the story in Jira
[ ] No open Critical/High (S1/S2) bugs against the story
[ ] Regression suite for impacted areas executed and passed
[ ] Automation updated for stable, repeatable scenarios
[ ] PO has accepted the story in the Sprint ReviewDAILY SCRUM - TESTER UPDATE TEMPLATE
Toward Sprint Goal: "Shoppers can complete checkout with correct totals"
Yesterday : Tested SHOP-8 (checkout info form) - 9/10 cases passed, raised SHOP-31 (S2)
Today : Retest SHOP-31 after fix, start SHOP-9 order summary tests
Blockers : QA environment had an old build since 6 pm - need redeploy (owner: DevOps)Expected result: a one-page document containing the sprint calendar, your tester actions per event, DoR (7+ items), DoD (7+ items), a quadrant map for checkout and a sample stand-up script. Keep it; Lesson 9 and the capstone build on it.
Common mistakes testers make in Scrum
- Running a mini-waterfall inside the sprint: developers code for 8 days and hand everything to QA on day 9. Push for small stories and early deployments to the QA environment.
- Staying silent in Sprint Planning and then complaining that testing time was not considered. Your estimate of test effort belongs in the story points.
- A DoD with no quality items ("code merged" only). If testing is not in the DoD, it will be skipped under pressure.
- Treating "QA sign-off" as a gate that only QA owns. In Scrum, the whole team owns quality; you provide the information to decide.
- Saying in interviews that the Definition of Ready is part of the Scrum Guide. It is a useful team practice, not an official artifact.
Real-world assignment
Your delivery manager writes: "The ShopEasy team is moving from monthly releases to 2-week Scrum sprints from next Monday. Please share a short note on how QA will work in the new process." Prepare a one-page note (max 400 words) covering: where testing happens in each event, the proposed DoR and DoD, how bugs found during the sprint will be handled, and one risk with a mitigation (for example, the shared QA environment being unstable). Write it as you would send it on Teams or email, with clear headings.
Key takeaways
- Testers are Developers in Scrum; quality is a whole-team responsibility.
- Know the five events and what you personally contribute in each, with examples.
- DoR protects the team from starting unclear work; DoD protects users from unfinished work.
- Shift-left: design tests during refinement, not after coding.
- Use the pyramid and quadrants to plan a balanced mix of test types.
