February 06, 2005 - The Developer Testing Burden

I started at Agitar (Engineering Management) in August - but have been associated with the team at Agitar for the last several years. In my past life at SunTest (Sun Labs), I was responsible for creating several Java testing technologies (primarily focused towards load testing) - and being a geek at heart - the "toughness" of the testing problem has always kept me charged up about solving it.

Now, Agitar is a developer testing tools company. The engineers and generally the team here are fully in-tune with the developer testing "mantra" - XP, TDD and all. Not me (not yet anyways). See, after my experience at SunTest, I moved on in Sun to run their Application Server engineering group - so got more into platform technologies. Sure, we tested our platform - had a bunch of unit, system, acceptance and smoke tests. I had a fairly large team of developers and qa engineers - but I don't remember anyone being "test-infected".

It is my belief that as of today, for every TDD developer there is a larger number of non-TDD developers, and for every test-infected developer there is a larger number of non-test-infected developers.

But, it is also my belief that all serious developers understand the value of testing their code before pushing it to QA. They would like to test their code, heck, it would even make their life easier - wouldn't it?

Yet, they don't get test-infected. To them testing is a burden - an overhead - a task that these developers need to accomplish to get the checkmark for their annual reviews. For these developers, the effort required to test is significantly larger than the returns perceived.

The Testing Burden is a real problem - there are a lot more developers that are yet to realize the gains of developer testing because they haven't adopted it.

If a developer takes x amount of work to develop their code, then they probably take another x or even larger amount of work to test it "seriously". So total time for developing the code is >2x. If, however, the total time for "developing" the code was 1.2x or 1.1x, then more developers would get test-infected.

Over the next months, I'll be championing the cause to make the job of "developer testing" easier for us non-test-infected developers. I'm hoping to add value to this test-first, test-driven team by providing the perspective of the non-test-first and non-test-infected developers out there.

I will share more through my blogs of our experiments as we get further along - to the extent that I can. [Side Note: I'd love to hear from you about the challenges you may face that prevent you from being test-infected?]

Posted by Ashish Kumar at February 6, 2005 01:26 PM

Trackback Pings

TrackBack URL for this entry:


Hello Ashish, I was talking to Jeff Fredrick (friend) about the question you asked "why aren't people test infected" and after I gave him my opinion on why that is, he suggested I'd post it here. That Jeff, always thinking. So I'm just going to paste what I told him.

"..the answer is simple: it's tough to do. it's not because people don't like it or think it's a waste of time, it's just tough. testing is like exercising, everyone knows it's good, but unless you're starting to see signs of your bad health/code, you're not very motivated...unless it becomes easy, like the 5-minute-abs-miracle-machine or whatever. so if you know of any tool that makes testing easier, hold on to that tool"
"junit is great for testing extremely well designed code or extremely simple code, most [real world] code is neither. you always need some database somewhere, or a webserver maybe, or some complicated state or gui, and then junit is not the right tool. it makes exercising real hard, and people don't get test infected"

btw, I've been dev. testing (and advocating it) for 5-6 years.

Posted by: Julio on February 20, 2005 12:40 PM

Hi Julio - you're right, and well put!

There is no doubt that testing is a tough, tough problem. Most test automation tools work on making some part of the testing problem "easier". JUnit, for instance, provides an easy framework for test development and execution. Other tools similarly provide something or other that make it easier to arrive at tests that the user may need. Ultimately the winners will be tools that can figure out what the user "wants" (see Needs and Wants).

Even if completely solving the testing problem is just not possible - that's still fine by me. If it can be solved to 60% (although I'd shoot for higher ultimately), that's at least 80% higher than what's available today.

It boils down to, in my opinion, "how much work do I need to do to get my testing done" - and tools that can make that answer closer to 10-20% of the work it took to develop the code, will win.

Search was a tough problem - getting the context right and then learning from how users interact with the search results. With time and enough brainpower applied - it can be solved. It's not 100% right now - but it works!

We've got plans to get there ... we may really have the 5-minutes-abs-miracle-machine plan - I'm extremely excited about the possibilities.

Thanks again,


PS: I guess I was wishing for too much in expecting non-test-infected developers to be browsing blogs at "developertesting.com" :)

Posted by: Ashish Kumar on February 22, 2005 06:24 PM

As long as we present testing as something that has to be done for it's own sake, developers will resist.

Someone here used the metaphor that testing is like washing the dishes - we all hate it, but you have to get it done or you don't get to eat next time. If testing were like that, I would not do it either. I would buy a dishwasher or hire someone to do it for me.

Testing is like tasting your food while you are cooking - it's part of the fun of cooking - and if you don't taste it as you go along, it will probably taste like crap at the end.

A lot of developers are short-order cooks. I am taste-infected.


Posted by: Kevin Lawrence on February 23, 2005 10:48 AM

Post a comment

Remember Me?