ROI is a hard matter when it comes to software development.
A huge number of managers simply don't get the case for Automated Unit Testing; no matter how many times they've heard about its benefits;
no matter how many times they have dared to say (liar...) that their teams are doing unit testing.
Even worse... there are still a huge number of software developers that still don't get it.
And a lot of technical managers; not only your usual "pointy haired boss" but those technically fluent that have won your respect over the years... not even they seem to fully understand that automated unit testing is a direct money saver.
So I'll write about a small event in a project I'm involved right now (and I mean... now...).
The core of the system has got a coverage of 100% of the lines.
Even though that's not as good as it can get, it makes me feel confident, and makes it harder for anyone to justify *why* is his code missing full coverage.
(Don't get scared. It's not hard to get coverage if you stablish the policy from the beggining, and it's easy to get the team involved if you bring them the tools to do it)
Well, back to the story, this morning, I've started myself coding a small change for that project:
Some contents are stored in two languages, and our client have now asked for the languages to be four. "No problem", I thought. "I'll scan that code" (not even 500 lines counting code and tests) "and extend the proper parts to hold the new fields. I'll do it myself so I don't disturb the development team."
It took me about 30 minutes to get the fix done and the tests still were running OK.
So I thought... "Should I write some specific testcase to test this new fields?"
My first answer to myself was "Naaaah... the code is right, I've done it carefully. The existing tests on the matter still pass. Don't be test-obssesed, Jorge!"
But... just for... obssesion, right... I did change some values in the test data to hold some values in the new languages, added some assertions on that new data, and run the tests again.
Some tests (not directly related) started failing miserably when trying to consolidate the contents stored in the new languages.
It took me another 10 minutes to fix and test it.
Now, let's think about Return on Investment...
- Let's say that I don't write that last test.
- Let's say thas this code would have passed the integration test (it would indeed, because nobody will care about thoroughly testing french contents beyond "yes, they appear in the proper place").
- Let's say that, once the code is in production, somebody discover that french contents don't seem to be taken into account when reporting to the management.
How long would it take to fix that bug?
How many man/hours would the whole organization spend to
- ...isolate the failure so they understand what's happening,
- ...record the bug,
- ...send it to the first level support,
- ...forward it to the appropiate technical team
- ...assign someone to solve it,
- ...get it deployed and tested by the concerned agents
- ...ask for the code to be released
- ...release
Now, compare this number to the fifteen minutes it has taken to fix it.
That's the Return on Investment you'll get if automated testing is correctly used in your teams.
Daily.
Now go, tell your friends.
_
Posts
