Tag Archives: Teams

Test Infected Developer


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.


acQuire Technology Solutions releases the 2014 version of their fantastic Q Book

Earlier this year I interviewed Tadhg McCarthy about a company he helps manage called ADAPT By Design.  ADAPT By Design is a child of acQuire Technology Solutions and today they released the new version of there fantastic Q Book.

This is a great example of allowing success to occur to everyone.  It must be a great place to work, and work should be fun as well as productive – the two are intimately linked.

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.

Poll: What’s wrong with this picture?

Caught this picture on the web this week.  It’s intended to be a bit of humour and yes we can laugh.  There’s more to it, obscuring the real causes for dysfunctional behaviour.  I’ve created a poll.  Results will be part of a subsequent blog post. Please have a vote.


Response to Tripwire Removal – be humane is the essence I think

This is a response to an Stephen Smith’s article called Tripwire Removal.  I may flesh this out further over time as there are other ideas present as well (e.g. from Kanban).  The original post should appear in the comments section of the web article once it’s been moderated.

Rule 1 resonates with me. On a job in 2012 I was not happy with the performance of one of the team members.

I was searching for a way to improve the situation. I think the biggest problem is that we didn’t swarm to help the guy out more and provide the knowledge transfer and the work was too big as well, i.e. could have been broken up further.

At the time, I approached management for assistance. I was quite disappointed with the response. I was expecting maybe to work with HR to work out a solution – I suggested this. The response was thanks for bringing it do our attention but no solution.

Later on the solution was to allow the guy to move to another team. I saw the mental anguish this caused to the guy (a nice guy) but at the time I felt relieved and then productivity could improve.

Looking back I could have convinced the mgmt and team to allow even more self organisation (we had it already) and allow more swarming behavior. Being in a place where this could be frowned upon we had swarm by permission. I think empowerment as Scrum/Agile suggests would have eased the problem, however this still would have created a feeling of some not pulling their weight – but hey you get that orders of magnitude more productivity between team members.

I sense a blog article coming on as there is probably more to say on this topic. For now I leave it somewhat superficial.

Apologies to all involved in this situation – we should try and do better. This means managers being leaders and seeking collaborative solutions and not being the problem solver – that’s part of it.