Tag Archives: extreme programming

Test Infected Developer

TwoBearsDeveloping

Lisa Crispin and Janet Gregory’s seminal book, Agile Testing, refers to fellow agile author and coach Jonathan Rasmussen as a Test Infected Developer.

The story as presented in the book describes the first encounter between Jonathan Rasmusson and Janet Gregory.  Jonathan’s first reaction was to think there was no role for a tester in an XP (extreme programming) team. Janet’s inital response is long forgotten, however the value she introduced was displayed in the next six months. Automation of the low level test cases allowed her to focus on more value add areas like Exploratory Testing.  Jonathan was thus converted and saw the valuable role of a tester on a team.

They also go on to say a happy result of Agile Development is that many programmers are ‘test infected’. An agile team is happily test infected.

This essentially means that everyone is pulling for the team. Testing becomes a task rather than a role. What’s good for goose is good for the gander.

The aim is to deliver more value for the customers. Testing and the Testers mindset from the beginning of the project is an important part of the process as it can effect everything from requirements gathering through to installation and all points in between.  In requirements gathering we are questioning to ensure we build the right thing and during the build we are building it right!

If you are a developer who unfortunately does not have access to a (agile) tester you will need to take these skills on if your haven’t already.  I’ve personally been in the place a few times in the past and adopting the testers mindset and directing yourself to the most value adding tests results in a much better result.  This is not necessarily to be confused with the very specific role of Software Developer In Test which some teams employ – although the swarming, t-shaped skills mindset still kicks in to ensure the value (value trumps output) is delivered for the customer.

Key Takeaway

We can all learn from each other and develop those T-Shaped skills that help deliver solutions faster.  When we have testers available we can accelerate even more, when we don’t we need to fill the role ourselves.  Either way we should and need to be Test Infected.

With this important part of our toolkit, we can delight our customers and get onto the next great thing. A win-win.

Advertisements

A quote on Test Driven Development from 2003 – Sometimes you need to fail

Wow – I was searching my email for something else and in passing re-discovered this except from an email I wrote in 2003.  I still struggle with this in 2014. Here it is as is with small grammatical errors included:

“I did this last week with someone on my team at InfoHealth.  This person had not unit tested the code (properly) and there were loads of errors.  I fixed them by first writing the tests to catch the bugs and then methodically fixing them.  I finally got to a green light. Yay.

A couple of days later this person changed something and whammo the website we were working on was giving the wrong results.  This person was really having a rough time of it trying to find out what the problem was.  I offered to setup the test harness on his machine but it didn’t eventuate (he had tried himself and was unsuccessful getting it to compile).  The next two days he was away.  I logged on to his machine and got the test harnesses to run and show the first error.  I didn’t proceed to fix them though.

He then came back in.  None of the bugs had been fixed yet after a day of some fruitless bug fixing previously. I suggested him to fix the bugs through the test harness.  He ran the harness and discovered the first error and fixed it, and then the next and then the next.  After about 90 minutes and fixing 9 or 10 bugs he was done.  He comment afterwards was ‘Testing was never so much fun’

Hopefully I gained a convert to Test-Driven development.  Only after demonstrating a regression test suite it made all the difference.  This person was not on the project where we had previously done Test Driven development and I felt he was a somewhat cynical person as well who gently needed to be shown the light.

And so ends my anecdote.”

Testing is so important but we are still refining the practice.  Lately James Coplien and David Heinemeier Hansson (DHH) have been wanting to scale back unit testing (both from different angles), removing some of the pedantic nature (my words).  DHH wants to take it out a level to the integration.  They both have valid arguments.  See DHH’s article for more and this will have links to James Coplien’s ideas as well.  On May 9 2014 Kent Beck, Martin Fowler and DHH will be discussing TDD in a google hangout entitled Is TDD Dead.  It should be interesting and I’ll be tuning in.

Testing exists somewhere and we are trying to get to the sweet spot, balancing the risk mitigating advantages and the ROI on creating and maintaining them.

Edit: The second episode of the TDD occurred last Friday 16 May 2014.  DHH struggled a little with his argument the TDD creates bad design. Perhaps more like inexperienced programmers create poor designs. James Shore weighs in here.

The HeartBleed bug and GOTO Fail bug in Apple products could have been prevented by a unit testing culture and saved a lot of time and money as a result.  This article from Mike Bland explains.  I’m of the same mindset that we should not resign ourselves to an acceptance of complexity and that these things ‘just happen’.  Simple design and unit testing would have greatly mitigated these issues.

The non-unit testing culture means there are probably many other bugs waiting to be discovered.  The relatively small impost on time to do unit testing and do it well is paid back many times over.

The twitter hashtag #IsTDDDead is covering the debate, although now seems to be simmering down.

Uncle Bob Martin puts TDD in the context of Teams, paraphrasing – Good personal hygiene is good for the team.