How to sell testing to a resistant organization?

[Greg Charles]

The project I'm working on has no automated testing of any kind, and the team seems resistant to creating any. The usual arguments apply:

We don't have time or resources to write unit tests or any other automated testing

Our framework (Oracle Portal in this case) makes automated testing, especially unit tests, impossible and/or ineffective

Automated tests break when code changes complicating maintenance

We're lazy or don't want to think too hard. (Implied)

We'll look into automated testing in the future (which never comes)

I've run into these attitudes on various projects I've worked on, but never quite so entrenched as on this one. I know the counterarguments to these points, but I don't seem to be able to make them effectively to this team. I'd appreciate any advice of strategies that worked for you.

[Jeanne Boyarsky]

There is another implied reason which is "we don't know how." It is funny how organizations think they don't have time to write tests but do have time to chase down endless bugs.


Approach 1:
Just start writing them to show the benefit.

Approach 2:
Pair or offer a workshop so others learn how to write tests.

Approach 3:
Try to sell it to management.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I started with approach 1 & 3. Ongoing I use approach 2.

[Junilu Lacar]

Not wanting / able to write unit tests is a multi-faceted problem that needs to be attacked from multiple directions.

Selling to management is tough - if you want to do that, I would start by gathering statistics (which can be a whole 'nother problem of its own) that show how much it's costing the organization to deal with bugs, the cost of reduced responsiveness to change, amount of time developers spend fixing things vs delivering new functionality, etc. Anything that you can tie a cost to that more testing can help reduce tends to make it more interesting to managers. It's still a tough sell if the managers don't get it though. The last thing you want to do is make it about making the lives of developers better. Call me a cynic but most managers don't really care too much about that.

Setting the example or "build it and they will come." This works best for me, although it takes a great deal of perseverance on your part. If you can consistently show that your habit of writing unit tests makes your life better as a developer, then other developers will start to want what you have. Again, there are many things that also need to be overcome such as poorly designed, unrefactored code with high coupling, low cohesion, a huge blocker to writing tests in a brownfield application (symptom: "automated tests break with changes to code"). Statements like "our framework makes it hard" are symptoms that your architecture is too rigid and tightly coupled. There's also schedule pressure that always gives undisciplined developers an "out" on writing tests (symptom: "We'll do it later"). And others, like a lack of ownership by other developers, results in barely-adequate quality of work. Introduce books like Uncle Bob's "Clean Code" and "Clean Coder", maybe someone will be inspired to be more of a craftsman. Introduce them to Christopher Avery and his "Leadership Gift." That is one workshop/talk that will change the viewpoint of anyone even half-serious about doing a good job.