Unit testing is a set of skills, that rarely appears on a resume. When I saw a resume with unit testing on it, it rose up to the top of the interview queue. I understood the person who put it there understands what it means to the business.
If the organization already took the red pill, it sees unit testing like this:
Unit testing shortens the current and future release cycles at the expense of initial extra development work.
It’s not about quality, or maintenance, or other things we’ll dive into more in a minute – it’s about money: Shortening the release cycles means earlier income. For the next releases it also means less maintenance money, and more money from new features.
The extra development time on unit testing is not really just in the beginning. It is definitely a bump in the beginning, because the team needs to learn new skills and tools. Once they do learn it, and make it a work process, development time even drops. Industry numbers talk about ~20% more work, but this is really subjective.
Let’s take an example a project which takes D time to develop. If the project manager is smart, she’ll plan an integration period I and testing time T. (T is what we call manual testing, not automated integration testing).
With additional unit testing effort, D increases, while I and T reduce. This is because bugs get caught earlier, and are also easier to debug, since we now have unit tests.
So the additional developlemnt is compensated by having the unit tests in place. We’ll have roughly the same time until the release.
But this is only for the first release. Let’s see what happens in the next release. Without unit testing, development time is now longer, because we need to fix bugs we didn’t fix in the first release. Also, integration and testing become longer, because we’re breaking functionality that worked before and needs fixing again. No unit tests to give us early warning, plus more code to maintain.
So zooming out a bit, two cycles look like this:
That means that with each subsequent release, for basically the same additional scope, we’re delaying the release, making the project late.
With unit testing effort, in the second release there’s no additional effort on the Development side. Learning is over, unit testing is now just part of the development process. In addition, there are less bugs carried over from the early release, and integration and testing for this release are also shorter, because there are less bugs from this implementation.
The initial investment in training the team for unit testing (and TDD if you’re up to it) may seem that it delays releases. In fact, it does the complete opposite.
The numbers may change, the knowledge and experience may change. The process I illustrated, however, remains the same.
If you thought about how to sell unit testing to business people, this is how you do it.
Image source: http://marketingbones.com/understanding-economics/
0 Comments