Let’s say you work in an internal IT department, largely doing maintenance work on software solutions.  Solutions that are by and large built by external vendors through an outsourcing arrangement and then brought in house once they’ve gone live and the initial warranty period has elapsed.

Let’s say every time you look at one of these solutions that you now have to maintain you find the grand sum of zero unit tests.  Without exception. Every single application has nary a unit test to be seen. Not even a hint that one might have existed and been removed at a later date.

“Why?!” you cry to yourself.  In frustration you cry “Why!!?” to management as well.  Their answer: The vendors tell us “it will cost more and take longer to do unit testing” and of course, they reason with you, if that’s the case then why would we pay for it? You know this is a bad argument and the logic is built on sand, so what’s your comeback? How do you get it across to management that a vendor that ignores unit testing is a bad vendor and is actually more expensive overall?

 

So my initial response to their claims would be along the lines of “So do I assume they’re not actually testing the software they write for us then.” and then explain how manual testing takes (much) longer than developing automated tests, assuming of course that the code being written is in any way testable.  If they develop poorly and have a lot of tight coupling between concrete classes or make a lot of static calls to HttpContext or develop in SharePoint for instance then the application might not be easily testable, but hey! That’s their problem not ours. The good news is that anyone with a business brain can understand the benefits of automation for tedious repetitive time consuming processes – heck, we worked that out during the industrial revolution.

Let’s try a different angle in case the first, most obvious one doesn’t work.  If you consider a lack of automated testing to be merely another form of technical debt then it’s just like poor design and architecture, horribly complex methods, N+1 ORM queries, poor UI’s, high bug counts, etc. It’s something that will cost you. So, if a vendor delivers you software with a high level of technical debt and you’ll be maintaining it, then you’re going to have a lower long term ROI and higher TCO from those vendors versus what you might have from a vendor who keeps their debt levels low.  So while the cheap guys may argue that it will cost more and takes longer to write code with unit tests then what they’re really saying is this

“It costs US more and takes US longer to do unit testing because the developers we hire are the cheapest and suckiest we could find. They don’t understand good development practices and we’re not about to teach them because they’ll leave in the next 3 to 6 months. Also manual testers here are cheap-as-chips and lose staff too quickly, so it’s easier for US if we just get the software to ‘it kind of works’ and then give it to you so we can get our money and hope you won’t notice”.

Also, don’t forget that post delivery, all those bugs and problems that snuck through from the vendor will end up becoming your bugs and problems to fix as part of your maintenance work.  So the company is either paying for it with internal staff costs (often seen as a hidden/sunk cost) or, if the vendor is also charging for maintenance, paying for it once a development project is concluded.  Development takes longer, it’s harder to find and fix bugs, it takes longer and longer to test the application manually, etc.  These all add up to time, and in software development time is money!

With that, good luck convincing management to change their vendors, and if you’ve got a better reason to present yours case I’d love to hear it.

Note: I’m not implying manual testing is bad.  In fact I think you should be doing manual testing; but only manual exploratory testing where testers are trying to break your code.  It’s rote, repetitive manual testing that is neither cost efficient or effective.