When starting to use Scrum for software development, many teams approach acceptance testing in a more or less traditional way. Developers focus on implementing the spring backlog items within the sprint. At the end of the sprint a new release of the system is delivered and declared ready for acceptance testing.
There are is a problem with this approach. When a Product Backlog Item is not tested for acceptance, is is not completely Done. When acceptance testing is done after the sprint, that is, during the next sprint, any corrections resulting from its feedback can only be planned in the sprint after that. Much too late! This approach tends to result in an ever increasing stack of corrections taking time that should be used to implement new Product Backlog Items, and thus slowing down development.
So, why don't we do acceptance testing within the sprint? In this way we receive earlier feedback and have the opportunity to repair any issues right away and have the Backlog Item really done by the end of the sprint. But this approach has its own problems. For instance, team members cannot do acceptance testing themselves, but someone outside has to do this. This means that the software must be made available to some acceptance testing environment, where outsiders can perform their tests. They need a reasonable amount of time for that, which means that near the end of the sprint developers have to stop developing because whatever they deliver cannot be tested anymore. That means loss of precious time.
Do you have experience with acceptance testing within Scrum sprints? By the way, this problem exists in every iterative style of development; not just in Scrum. What solutions work for you?
