Although ROI is dead it is still useful to talk about value and cost of testing.
When we write automated tests, regardless of it being unit, integration, end-2-end, load test, or whatever kind, the cost we have in mind is the cost “writing the test”. In fact, when people ask “how much time will it add me to start unit testing” this is the image they conjure up.
Everybody understands that introducing a new practice will slow them down, and they want to know how much. I usually give the answer as 20% rise in the beginning of the process, because it sounds plausible, and because people believe that if you don’t give them a number, you don’t know what you’re talking about.
The fact is, writing tests doesn’t slow you down, because, get ready for a surprise:
You Are Already Slow!
You see, most of developer time is not spent on writing code, unless it is managed wisely. And usually it isn’t. Developers spend their time on meetings, debugging, bug fixing, thinking how to get that new feature into that legacy design and more meeting. All kinds of non-productive stuff.
So the real question being asked is “From that little time I’m spending writing code, how much time do I now need to devote to something my managers don’t need as a deliverable”.
While things don’t look dandy, there are good news and even better news.
First, 20% (a made up number, I remind you, but you’re welcome to use it) out of not-a-lot-coding-time is not really a big deal. In fact, this small investment will probably free a lot of your time so you can write more code.
But the better news is that you have a potential to become a better developer just by managing your time better!
If you manage your time wisely: Don’t go to unneeded meetings, become effective at the meetings you need to go to, and exercise the right to say “NO!”, you will get more coding time in spades. And I hope you’ll devote that time to learning and practicing some testing skills.
Which unsurprisingly, will get you more coding time.
Strange but true.