The decision on what types of tests to run within a sprint is the subject of much debate within the Agile community and organizations implementing Scrum. The methodology supports writing acceptance criteria for each unit of work (story) that defines when that item is “done”. That criteria is used to create a validation plan that is executed when the story has completed development. The story must pass validation to be declared “done”.
People usually struggle with the other types of testing that occur in software development, such as epic testing, regression testing, performance testing, and others.
I’d like to share an approach that has been used on other projects in the past. This is by no means the only way to structure this testing work, but it may give you a starting point from which to make your own improvements.
Keeping the Agile principles in mind, it is a better use of time to actually test the software than to have long debates about HOW to test it.
A software release, Bank Shot 3.2, has two epics:
Epic 1: Allow customer to view credit scores online
Epic 2: Allow user-defined field on customer profile screen
These epics are assign to two teams, Team 1 and Team 2 respectively. These stories will be integrated into Bank Shot Release 3.2. Each epic has 10 stories.
The diagram below shows the hierarchy of epics and stories, along with the acceptance and validation activity. For each story, the acceptance criteria and the “doneness” validation are closely related.
How to Manage this Work in a Scrum Team
Story acceptance criteria should be developed in conjunction with the customer or customer-representative on the team. In that regard, they are user acceptance tests at the story level.
Here are two simple rules that will allow you to manage the testing work within a scrum team
- The acceptance criteria and doneness validation work should be done as part of the story. No additional work should be put on the board for these two activities.
- Create a story card for the epic that will track any design, specification, test planning, and test execution that is done at the epic level. This card may need “special treatment” since it will have a longer duration than a typical story
With small projects that have one or two teams, all of the system testing activities can be done as part of the epic acceptance testing. Larger software systems often require separate integration, system, and performance testing.
The diagram below shows an approach for this type of test planning and execution
The concept is that the epic acceptance criteria is fed into an already existing system test plan. The changes are reviewed and the system test plan is updated to reflect the new function. This activity is run by an independent test organization. An option is to have one of the development teams act in this role .
Continuous integration and regression testing should be occurring throughout the life of the project, so the final regression testing should be minimal.
Here is a summary of the three rules that can help you to manage testing:
- Story tests are defined and run by the scrum team as part of the story work.
- Create a story card for your epics to track activities such as testing that are part of the epic and not reflected in the individual stories.
- Designate a release test team (if you don’t have one), to create a system test plan from a combination of the existing tests and the validation information from the new epics.