better tester, worse code

I’ve recently been observing a couple of very similar development teams who had one major difference: The tester in Team 1 was very good at his job, whereas the tester in Team 2 wasn’t. And as a result, the developers in Team 1 produced significantly poorer code than those in Team 2! It turns out that the very good tester was highly trusted by the rest of his team – so much so that they were happy to delegate complete responsibility for product quality to him. In turn, this freed them to churn out code at an alarming rate, without regard to whether it worked particularly well.

Team 2 ended up hardly using their tester, preferring to rely on TDD to catch most defects before they made them. But they were able to release product at the drop of a hat, because they knew and trusted the quality of their code at all times. On the other hand, Team 1 required over a week of full-team manual testing and defect fixing before they were prepared to believe they were ready to release.

Team 1 were applauded for their speed of coding, and for the obviously great work of their tester. Defects? Rework? Manual tests? They’re a fact of life in software development aren’t they? Just an overhead we have to live with. But look how fast we go!

By comparison, Team 2 were castigated for their slowness. They did very little fire-fighting. Releases were a non-event, an anti-climax almost. Unnoticed, unheralded, they produced working product on a weekly basis.

I’m sure none of this is a revelation to you, but to see it in action is quite impressive.

4 thoughts on “better tester, worse code

  1. Hi Kevin,

    One question about what you say in the end of the post about releases for Team 2. You say releases were a “non-event, an anti-climax almost. Unnoticed, unheralded”. I´m guessing you mean in terms of fire-fighting, debugging, but even so, do they not celebrate their victories? Not like a big party or anything, but like in XP Installed´s chapter “Sense of Completion”. There Ron et al speak of punctuating the work by celebrating when finishing stories(high-fives, bell whack, …), iterations(pizza & beer) and releases(champagne).

  2. Hi Dadi,
    I did mean ‘unheralded’ in the sense of debugging etc, as you say. But sadly it is also true in the second sense, and that’s another story entirely.

  3. Pingback: downstream testers: better is worse « silk and spinach

  4. Pingback: My response to A Testers Commitments from James Bach | Duncan Nisbet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s