Blogs
Welcome to EMC Consulting Blogs Sign in | Join | Help

Welcome to EMC Consulting Blogs

Mit creme

Musings on Agile development, Java and other, unrelated aspects of life

Testing in Agile - Part One

Musings on the meaning of "potentially shippable"

One of the mandates of Scrum, and a mainstay of Agile processes in general is the concept that every sprint or development iteration should produce potentially shippable code. In essence this is taken to mean that the day after any sprint is completed the fruits of the teams labour can be released immediately. Release could be to a UAT environment for final fit-for-purpose testing, or directly to a production environment but this is an extraneous detail. The key point is that there’s an expectation that the developed product will have no significant bugs and require no further development before being moved on to the next stage of project implementation.

The question that has been occupying my thoughts for some time now having been through a number of Agile development project is whether this premise is actually achievable in the real world. Having failed to reach a definitive answer on my own I raised this as a discussion point at the recent Scrum Gathering in Minneapolis which provided some useful experiences and opinions on which to draw. This helped lead me towards a conclusion which is not so much an answer as a redefinition of the premise.

Potentially shippable code is code that is never more than a single iteration away from release.

In taking this approach it is possible to maintain agile development practices without significantly impacting the release as soon as it’s complete enough mantra. As a sprint backlog is worked through, code is developed to a high quality, tested at a unit level, functionally tested and bugs uncovered. In my experience, these bugs are generally rated by criticality and then handled in one of two ways. Regardless of the number of criticality levels, there is a dividing line with bugs sitting above that line being fixed immediately, within the current sprint, and bugs falling below that line being queued up for later attention. It is these queued bugs or “bug debt” that this final, “snagging” sprint provides the time to resolve.

In subsequent posts I will post some thoughts on how to both minimise and manage the inevitable bug debt.
Published 19 December 2006 10:23 by Gavyn.Dowst
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

john.rayner said:

I'd be interested to know if you have any thoughts on the approach that the testers should adopt in an agile project.  A lot is made of how agile development is different to development in other methodologies, but I think that agile testers also need a considerable shift in approach and working practices.

I've also found that the additional requirements around testability tend to affect the structure of the system.  A unit-testable class is often structured differently to a non-unit-testable class (have I just invented a new word here?), i.e. it tends to use dependancy injection to allow for mock objects and often exposes more fine-grained functionality.  In a similar way, an application built for the agile tester tends to have lots of places where test data can be processed, and more functionality exposed to a testing UI,

December 19, 2006 23:17
 

Gavyn.Dowst said:

I'm probably not the man to speak to about the approach that testers should take in Agile. Although I've given some thought to the mechanism of testing in a process context, I would hesitate to advise on an approach as I wouldn't claim to know anywhere near everything that testers do currently, Agile project or not.

With regards the point about the focus on testing changing the structure of the system you are undoubtedly correct. I would say that it is almost always for the better though. Writing code in a way that makes unit testing easier does tend to force greater abstraction and better use of object orientation. Small, discrete simply tested units.

I'm not sure I understand your comments about an application built for an agile tester having more functionality exposed to a UI though. This sounds like additional unnecessary work to me. Either a functional item is exposed through its intended UI and tested through this, or it's not and is unit tested. Ultimately, at some level all code in an application should be testable by testing the standard application UI or the code is not necessary to the operation of the application and shouldn't be there anyway. This is clearly a simplification but it does suggest a new topic to me for a future post on whether the unit test/functional test balance of focus is incorrect in projects currently.

December 20, 2006 12:09
 

john.rayner said:

An example may help clarify my point.  I worked on a project that generated some reports based on statistical analysis of data, and the reports included some charts.  So the general process flow was:

 data -> statistics -> charts -> reports

We had a backlog item for generating charts and our definition of "done" included testing.  So our tester asked how he was meant to test the charting functionality.  Due to the complexity of the statistical analysis, it wasn't really reasonable to ask him to setup the test data in such a way that he would get his desired inputs into the charting function.  The team's solution was to build a very basic UI onto the charting functionality where the tester could specify his own input values.

I don't think that this situation was unique to the particular reporting project I worked on.  I think that it is more as a result of having a multi-stage process.  And I think that the team's solution of a "testing UI" was a good one.  One of the consequences of this choice was that our charting functionality had to be quite loosely-coupled with the rest of the system (a good thing in any case), e.g. it had to allow any data to be passed into it.

December 22, 2006 00:17
 

Howard van Rooijen's Blog said:

Last November I attended the 2006 Scrum Gathering in Minneapolis along with fellow Conchangoens Colin

February 15, 2007 12:14
 

Howard van Rooijen's Blog said:

Last November I attended the 2006 Scrum Gathering in Minneapolis along with fellow Conchangoens Colin

September 28, 2009 21:31

Leave a Comment

(required) 
(optional)
(required) 
Submit

About Gavyn.Dowst

One time Java developer, some time Java architect, part time geek and full time human.

This Blog

Syndication
EMC2, EMC, and where information lives are registered trademarks of EMC Corporation.
All other trademarks used herein are the property of their respective owners.                  
© Copyright 2009 EMC Corporation. All rights reserved.                                                    
Powered by Community Server (Personal Edition), by Telligent Systems