Have you tested that…

I see an emmerging field, Test Driven Bug Resolution (TDBR).

I’m kidding of course, I don’t expect to see this on the agenda in Denver next year. I do see need for mention. I see developer’s riguoursly write test code prior to their build, running the test, smiling all the way. Everyone is happy. Then it happens. The business call in with a potential bug. They outline they steps they took to cause the problem, the developer feverishly taking notes.

What happens?
Our developer jumps into the application code, into the suspected class and starts dreaming up the changes. A change in the sequence of events, a change to the process or maybe just checking to see if an object is null before proceeding, what can that hurt?

This means two things to me:
1) The initial tests were light in at least one case
2) Developers consider TDD something that is done for the build, not for support.
I’m guilty. When a bug is discovered, I fall into that state of shame. I want to do whatever I can to prove my technical worth to the client and that usually means trying to tell them what it was, how I can fix it, why it happened….we’ve all been there.

The next time this happens, go into your test suite first. Try isolating the test that failed to expose this bug and change that first. Two things will happen:
1) The next time you write a similar test case, you’ll nail this exposure
2) Your test suite is that much stronger, a better story to give your client — your technical worth proven 🙂

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s