We are new to Agile, and we have been noticing that user stories usually get completed by the end of the iteration. Testers have very little time to test stories thoroughly; they're idle for most part of the iteration. This seems wrong.

What is the right way to get the user stories tested?



You are likely having this problem because testing isn't being included in your "definition of done" for each story. You should include testing for each story in your Sprint Backlog, and as a column on your kanban if you use one.

Testing as a Story Requirement

Generally, Scrum teams will include unit testing in the development work, and Quality Assurance (QA) or User Acceptance Testing (UAT) as a defined process step before a story can be considered complete.

When decomposing stories for the Sprint Backlog, it may be useful to add an explicit task for QA/UAT to the backlog for each story. This makes it a checklist item, and any story that hasn't completed this task at the end of the Sprint is counted as incomplete.

In many cases, experienced teams don't include testing as an explicit item because it is baked into their estimates, and part of the team's "definition of done." In such cases, testing is an implicit requirement for a story to be considered complete, but the same rule applies: if the testing hasn't been done, then the story is incomplete.

Furthermore, many agile practitioners use kanbans to track stories through the team's work-flow. Having unique columns for testing that stories must pass through before being placed in the "done" column ensures that there is a visual reminder that testing is intrinsic to the process.

Finally, because testing should be part of the definition of done, adequate buffers for testing should be included in your story estimates. When testers don't participate in planning sessions, or when testing isn't part of the formal definition of done, this essential practice might be overlooked.

When to Test

Testing should be inter-weaved throughout your process. Testers should:

  1. Be involved in Sprint Planning and story estimation.
  2. Work with developers to identify and build tests during feature development.
  3. Work with the technical writers to build tests that act as self-documentation for the product.
  4. Have their own process step or kanban column through which stories flow during each iteration.
  5. Actively participate in the daily stand-up to coordinate with developers, technical writers, and other members of the team.
  6. Raise blocked tasks during the daily stand-up.
  7. Raise process issues (such as waiting until the end of the Sprint to test) during Sprint Retrospectives.

If testing becomes integral to your team's process, you are less likely to require last-minute testapaloozas at the end of each iteration. Additionally, because testing is a team responsibility, all members of the team will need to pitch in on testing tasks that are behind schedule in order to complete stories by the end of each Sprint.

Create a strong incentive for the whole team to be cognizant of the resource and time requirements for testing, both during planning and during each iteration. If you do that, testing will stop being something that is "thrown over the wall" to the testers at the end.

| improve this answer | |
  • Adding to this good answer. Every iteration sprint should deliver potentially shippable software. This normally means it is coded, tested and packaged ready for deployment. What "done" is, is defined in your definition of done. – Brett Maytom PST Aug 5 '13 at 0:50
  • I would add that the size of the stories may lead to idle testing time at the start of the Sprint. Ensure there are some smaller stories in the mix started early. – Venture2099 Aug 16 '18 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.