How should we handle the testing effort in a scrum sprint?

Mark Erickson_nnuh6s

We are currently on a two week sprint, and at the end of the sprint we have working functionality that we start delivering through a Beta/Staging/Production type environment.  When the developer is done with their Jira issue, they set it to "Ready to test" custom status.  The testers then see these issues and start testing them.  However, the tester may or may not finish the testing task within the sprint.  We want to track the Velocity of the developers so we have better insight to estimations etc...

Has anyone been able to successfully integrate testing into a sprint without killing the velocity?  I know velocity is a (and should be) a team velocity, not an individual.  But if it's not an individual developer, how should we estimate using velocity numbers?

Marianne Miller

I think it depends on your definition of DONE.  If the item is supposed to be ready for release (the output of a Sprint increment), then this poses a challenge.  I struggle with the fact that there really isn't a testing role Agile, and that quality is part of the equation.   We started out trying the leapfrog the QA/testing effort in a follow on Sprint and found that we were not able to release on a reliable schedule.  We now ensure that there is an immediate hand off to QA/testing as Dev work is done and make every effort to get it thoroughly tested and ready for release.  The Testers estimate story points as part of the development team, and if there appears to be a more complex testing effort, we make sure that the backlog items reflects that.

Since incorporating testing into the Sprint cycle, we have been fairly predictable, and only miss a few items.  if it's not complete and ready for release, it rolls to the next Sprint, just like anything else.  but that is usually the exception now and not the rule.