This will probably not come as a shock to all of you, but one of the hardest transitions to make when going to an agile process is in the area of testing.  Most current testing processes are based on the "test late/test everything" methodology.  This is obviously the way a traditional waterfall project is run.  As a result, most QA organizations are separate from the development organization, and use the typical "throw it over the wall and we'll test it" mentality.  Unfortunately, there is an additional caveat which is "don't send it to us until you are finished so we can test everything at once."  Two other things most organizations accept are a) extensive use of manual testing, and b) giving the QA team much less than adequate time to complete testing.

 

This style can easily cause a death spiral for agile teams.  In order to get a user story to "done" in an iteration (done means it is potentially shippable/marketable) implies the development, testing and acceptance from the product owner has occurred.  If we continue our old behavior it means for 85% of the iteration QA will be idle, then they will be working like crazy for the last 15% of the iteration.  How will they ever finish in time?  If they do manage it, how long can they keep doing it given a good agile practice is to test everything from all previous iterations in every new iteration.  The magnitude of the manual testing effort will simply overwhelm the testers and they will not be able to keep up.

 

In an agile process it is absolutely necessary to have a test automation strategy in order to achieve a sustainable pace of development.  In order to do this the framework needs to be lightweight enough that it doesn't cause too much extra overhead for developers, while also being easy to use so testers don't need to develop new skills.  This is where use of a tool like Fit and/or FitNesse can really shine.  These tools can be used very easily with .NET or Java, and using some newer add-ons can even be used with other types of systems.  Both tools are very powerful.  There is an excellent book titled "Fit for Software Development" which is an excellent resource.

 

But there is an even better way to improve your team.  Join us in Denver, CO on March 23-24 for our Real World Agile Testing with Fit and FitNesse course.  This course will teach you all you need to know to be effective with Fit and FitNesse.  We encourage developer/tester pairs to sign up together to learn how to collaborate effectively with each tool.  If you sign up and use discount code FEBNL you will get 20% off the price of admission.  Early bird registration ends February 25, which means if you sign up soon you will be able to get into the course for only $795!  In addition, if you will have additional attendees from the same organization, email info@agileforall.com and well will give you instructions for getting an even more reduced price on the 2nd attendee!

 

At Agile For All we are committed to Making Agile a Reality™ and during 2009 part of that commitment will involve hosting public courses.  We know the economy is tough right now, which is why we are offering the 20% discount and further discounts for more people.  It is important to note for an investment of well under $2000 including travel expenses attendees will have the opportunity to dramatically change the success of their agile process!

We're on a testing kick this month at Agile For All, and part of it came from a recent awesome blog entry from Elisabeth Hendrickson that really resonated with me.  The basic premise is we can look at automated testing and the information provided in the same way we look at money.  More money sooner is worth more in the same way that more automated tests which generate information sooner is worth more.  Basically lower the cost of automation (did you read the article above???) to the point that it isn't even a question about whether it is worth it or not!  I like that a lot.

 

Another article written by Lisa Crispin and Janet Gregory also caught my testing-tuned attention this past month. This article is important because it points out something I have said in many courses - testers are at the center of aglie!  The interpret requirements for developers, work with product owners to refine acceptance criteria and perform a host of other collaborative and communicative functions.

 

As I thought about testing and its potential for huge problems within agile organizations I posted an entry on my blog about the "magic question" I tell people to use for collaboration and acceptance criteria.  Read the blog and you'll never again ask for specifics about user stories, instead you'll ask "How will I know I've done that?" and be astounded by how much difference it will make.

 

I could go on and on about testing, but I'll leave that for future issues of the newsletter.  Right now I want to digress to the other end of the process - requirements gathering, user story creation, release planning and other similar activities.  Who does a lot of that?  Well a product manager or someone like that (product owner, business analyst, etc.) is a good bet.  Another huge problem for agile organizations is sufficient knowledge of how this particular role should perform in an agile environment.  Richard Lawrence of Humanizing Work and I will be co-teaching an Agile Product Management Boot Camp in Denver, CO on March 9 and 10.  We are offering very special pricing on this course - use discount code AFAFNL2FOR1 and you will receive an email giving you a discount code to get a 2nd person into the course for free!  Oh, and before I forget, what does product management have to do with testing?  The answer is very simple - it isn't done until the product manager says it is, so in a very real way they are the final tester!