View into test planning at the release level

View into test planning at the release level

One of the common pitfalls of agile teams is “Forgetting the big picture”.  Lisa Crispin and I wrote an  article for informIT in May 2012 http://www.informit.com/articles/article.aspx?p=1905881 .  Teams tend to focus on individual stories, and often don’t think about the feature or the system until the end game when they get ready to release to the customer or put it into production.              

Using a tool such as a test matrix at the release level gives the team a different viewpoint into the testing needed.   After the release planning meeting, the team usually has a fairly good idea of what will be included in the release. Plan a workshop for the testers, domain experts, in fact anyone who is interested.  The outcome of this collaboration workshop is a high level testing matrix. Start the workshop with a listing all the features  down the left side of a spreadsheet. Then add possible test conditions across the top.  Sometimes I suggest starting with a testing mind map to generate test ideas (see http://lisacrispin.com/wordpress/2011/02/28/using-mind-maps-for-test-planning ). 

Leave open columns for adding extra test ideas, as well as rows for new features, and be prepared to cross off features that may be lowered in priority and moved to a later release.  Once the spreadsheet has been created, gray out the cells that are non-applicable. It gives an easy reference for what we want to think about when testing.  Here is an example with 3 features and some possible test ideas.

  

I find that this collaborative process is helpful in getting everyone involved and getting different ideas for testing.  The value for me is the planning effort. At this point, the team could put it on the wall and use it as reference, reviewing it with programmers or other team members.  However, I have found that there is another use for this test matrix.

Project managers find it a very useful tool to see progress at a high level if we color code the cells as the testing is completed. It is more of a “gut feel” or approximation than an absolute indicator.  The colors I have used in the past are:

 
If we look at the example matrix again, it might look something like the following once development has begun.

You can see at a glance that most of the testing for “Save customer information” has been completed, but we may want to visit security a bit more. There is also a major issue in currency for “Update shipping charges”.

I have used this tool in many of the projects I have worked in and had success with all. I suggest to all the teams I work with to find something simple to show visibility of testing at the project release level.  This is only one alternative.