Monthly Archives: December 2009

Some holiday reading – what happens to testers on agile projects

Hi agile fans

Once again I was talking to a client about the wonders of agile project management when they revealed that their biggest need was improve the effectiveness of testing.

I am not sure if it is because testing is where the symptoms of many different problems are highlighted or if it is because testing is such a crucial part of IT development and support that fixing it is the most natural first step to fixing other areas.

Interestingly, I had a participant in a class recently who said to me “I think IT really began to go wrong when we started having testers”.

This sounded a bit controversial so we asked him what he meant. Apparently, when he first became a developer, he was taught that a core part of his job was to test extremely well to ensure he produced quality work. Now, he claims, there is a view that BA’s come up with requirements, developers cut code and then it is up to the testers to make sure that things work.

I don’t think that we started to go wrong when we brought in people to test – I think the integration issues and complexity of many systems means that developers only understand part of the system well and will struggle to test everything effectively without a specialist helping with this.  So I think we started to go wrong when we started to think complexity was necessary in our systems.

But I do agree that we go wrong when we think that testing is part of someone else’s role.

In fact I really enjoyed this link that Shane sent me on how a tester perceives agile projects, where the tester is having to deal with a change in thinking away from the tester being the finder of defects:

So I now think that the essence of good development is going to come from the synthesis of the following two trends that I am starting to see:

  • Better development will mean we will do less testing: – We will start to see good projects as ones where we are surprised to find bugs rather than ones where fixing bugs is a key part of our work.  Thus testing after the developer is done will become a smaller component of projects since it will cease to provide much value; and
  • Better testing will mean we will do less development: – By defining the problem properly and agreeing how to test our solution, we will eliminate much of the development work we currently see as necessary.  Thus development will become the simple translation of well thought out testing into the code that the system will understand …  and be only a small component of the project.

I might ponder this further while consuming some of the copious leftovers we have in our house after the Christmas feasting season.  Maybe we should add a warranty period to Christmas and dispense with it on our projects.  Instead we should be able to assume that what we have built will work, since we wouldn’t have built it any other way.

Posted by James King


Posted by on December 27, 2009 in Agile, Quality, SDC 2010, Testing


Christmas Greetings

This post is a simple Christmas Greeting from all of us at Software Education.  We wish you peace and happiness over the festive season, and a healthy and prosperous 2010.

Thank you for the interest you’ve shown in this blog, and for the interaction we have enjoyed through 2009.

We look forward  to lots of commenting and great posting here next year.

Posted by Shane Hastie on behalf of all the Software Education blog contributors.

Leave a comment

Posted by on December 20, 2009 in Uncategorized



Thoughts on the Wellington Barcamp

The Agile Barcamp was held in Welligton on Saturday the 14th of December.  This was the first Barcamp I have attended and I was really impressed.

Fronde hosted the event, and are due a vote of thanks for allowing us to use the premises.  The APN organisers kept things running to time and herded the cats well 🙂 

The event was truly self-organising – we started by posting a list of sessions we wanted to present onto a timetable, and participants chosing what they wanted to listen to.  After each session the agenda was revisited and changed as needed.  There ended up being 3 streams, each with four sessions of 45 minutes, so 12 talks in all. 

I delivered a talk on Why Agile Works, which seemed to be well received. 

I then attended Rashina Hoda’s session presenting early results from her PhD research – some very interesting material on roles that emerge in self-organising Agile teams.  I look forward to hearing about the final results.

Pete Tansey led a discussion about challenges and anti-patterns of Agile adoption.  Some really good discussions and Pete gave out a great “Agile Risk Assessment” checklist he uses when discussing Agile projects with PMOs.

The last session I attended was a discussion of the opportunities and challenges of implementing Agile in government departments.

Adrian Kearns audio recorded some of the sessions and posted them as podcasts here: 

Photos taken on the day can be found here: 

It was a pleasure to meet new people and catch up with some old friends in the Wellington Agile community.  I came away with the clear feeling that Agile is alive and well in Wellington. 

Thanks for making it a great day – a very worthwhile investment of my time on a Saturday.

Posted by Shane Hastie

Leave a comment

Posted by on December 15, 2009 in Agile



Don’t let your buglets escape!

I caught up with an Agile team this week and learned a new word: buglet

We were discussing how the move to Agile methods has improved the quality of their products – the test lead pointed out that they have found and fixed a total of 8 defects so far in the project, previously there would have been hundreds by this stage of the project.   During the discussion they mentioned not letting buglets escape, which intrigued me.

It turns out that buglet is the term they’ve adopted for in-iteration test failures, when a test fails the tester notes the circumstances and records a buglet against the story so the developers can address it as soon as possible.  The whole team is focused on making sure buglets are squashed before the end of the iteration, making sure that stories are Done-Done-Done and keeping quality high.

Simple language and simple processes that are resulting in quality products that meet customer needs, faster better, cheaper.

What terms and approaches are your teams using to keep quality high?

Posted by Shane Hastie


Posted by on December 8, 2009 in Agile, Testing


Tags: ,