A tip straight from the previous Scrum Guide (The guide updated and the undone TIP is removed, read The 2011 Scrum Guide – A Lot of Changes! ). But, the TIP still works, although it isn’t an ‘official’ tip anymore…
End to end testing, is not an agile specific testing practice, it’s a common sense testing practice. Create test cases to detected defects anywhere in the chain. This type of testing has been growing the couple of years enormous due to the rise of Service Oriented Architectures and more recent Cloud Computing. as the TMap end-To-End Testing books describes
“End-to-end testing is a form of testing in which the (business) process is tracked through an interconnected series of systems, which may be based in different organizations, aiming to answer the following questions:
- Does the IT process support the business process adequately? - Are the process and systems integrated with each other in the right way?”
TMap.net End-To-End Testing
End-to-End testing is seen as a challenges in Agile environments, with the most important challenge that systems under development aren’t ready for End-to-End testing. Not every service is finished to test the complete end-to-end business process. Stubs are a solution, but can these be made in the current sprint and are stubs good enough to say something about the quality of the system. And, when the system are ready and a change in a service is needed, how and can we re-run all the end-to-end tests, is there time enough.
All these challenges with end-to-end testing in agile projects can be summarized in two topics:
Scrum solves this problem, this problem of not able to be compliant on the definition of done at sprint finish, by defining ‘Undone work’. the scrum guide mentions this in a TIP and in the final thoughts of the scrum guide
Some organizations are incapable of building a complete increment within one Sprint. They may not yet have the automated testing infrastructure to complete all of the testing. In this case, two categories are created for each increment: the “done” work and the “undone” work. The “undone” work is the portion of each increment that will have to be completed at a later time. The Product Owner knows exactly what he or she is inspecting at the end of the Sprint because the increment meets the definition of “done” and the Product Owner understands the definition. “Undone” work is added to a Product Backlog item named “undone work” so it accumulates and correctly reflects on the Release Burndown graph. This technique creates transparency in progress toward a release. The inspect and adapt in the Sprint Review is as accurate as this transparency.
Within the Visual Studio 2010 Scrum process template this means that you have to link or create tasks to a specific ‘Undone Work’ product backlog item. this ‘Undone Work’ product backlog item accumulates the undone work regarding to End-to-End Testing (and others) over time and can be monitored just as other backlog items.
In TFS with the Scrum process template we can create Backlog Items very easy.
So, creating an undone backlog item isn’t that hard, the challenge is take it with you every sprint. for example in my undone backlog item I’ve got some undone tasks from sprint 1 and some from sprint 4. The iteration paths for these tasks still point to the sprint 1 and 4 sprints.
This will result in a wrong sprint backlog, because the tasks who point to other sprints as the current sprint won’t appear in the sprint backlog. So, when moving this Undone backlog item to another sprint because not all tasks are done, you also have to change the iteration path for the corresponding tasks.
Just keep in mind TFS doesn't update the hierarchy, you have to do it manually (or use Excel, my favorite).
01. Getting Testing Done in the Sprint - The Team and Activities
02. Getting Testing Done in the Sprint – Regression Test Sets
03. Getting Testing Done in the Sprint – Test Automation
05. Getting Testing Done in the Sprint – No Double, Triple Testing
06. Getting Testing Done in the Sprint – PBI Implementation Sequence
07. Getting Testing Done in the Sprint – Risk and Business driven Tests
08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
09. Getting Testing Done in the Sprint – Test Tasks on the Board
10. Getting Testing Done in the Sprint – Done
11. Getting Testing Done in the Sprint - The Customer Test Team
12. Getting Testing Done in the Sprint – The Test Branch