This is going to be a slightly different format from my previous posts. No technology here, just my opinion! In this blog post I will try to explain, with arguments that hopefully your manager will appreciate, how fundamentally important testing is.
Introduction
During my career I have had discussions about testing countless times. Most of those discussions were with fellow developers. I have also seen quite a big shift in maturity over the last 15 years: unit tests are often the norm in projects as opposed to years ago when they were more of an exception.
One thing however that worries me is that although developers themselves often see the value of tests, it’s often their managers who override them on this matter (which to be fair in itself is a red flag) to get them to 'hurry up'.
Who has not been in this position as a developer: It’s crunch time, you’re talking with a fellow dev about your work and someone 'higher up' overhears you mentioning that you got most of the basic functionality done and are working on unit test coverage. This person then urges you to 'skip the tests' and get stuff to production, pronto!
What might start out as a one time thing becomes a pattern, technical debt rises, your job starts to get harder and harder, the project loses steam and that vacancy you got from that recruiter on LinkedIn suddenly start to sound appealing.
Testing
So lets take a step back here. What is testing? One definition I like is this one:
Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not.
I like this short definition because it shows one of the most important components of the concept of software testing: evaluation of the software being correct. Software isn’t correct or incorrect before it’s tested. It’s basically in limbo. When code isn’t tested it’s not complete. You only know you’re done when you have tested the software.
One of the most basic tests is just running and using the software. But this becomes completely impractical with anything but the most trivial software: whenever you make a change to your software it’s back in that nasty unknown state. To know if it still fits the requirements it needs to be tested again. All of it. Not just the bit that was changed - no human brain can keep a complete mental model of anything but the most simple pieces of software.
This is why software is not complete without automated tests. Not having thorough automatic test sets and then relying on the software to be correct is just as silly as ingesting an untested drug because some chemist has a pretty good hunch it’s going to cure your cold.
Technical debt
So for managers it is important to understand what happens when you tell a developer to not write tests. You create technical debt. It is not a random term; its effects are strikingly similar to a real financial debt. It accumulates, it doesn’t go away all by itself and you keep paying interest in the form of lost time.
A small technical debt by itself, a single release where you didn’t test thoroughly, is not that big a deal. Sure some issue popped up in production but that particular customer had a rather weird OS / browser combination so that was to be expected right? At least this can still be fixed by investing some time afterwards.
But when you keep building debt the situation gets more dire. Your developers start to struggle with bigger changes that touch a large part of the codebase because unexpected issues pop up left and right. They manage but they often start to look worried when the business requires certain new functionality. When they are starting to push back with language like "the application doesn’t support that" they are not being difficult on purpose: they know that the application is in fact of the verge of breaking apart. You’ve lost all agility in your development process.
The Event Horizon
A while ago I saw someone coin the term "Technical Debt Event Horizon" which in my opinion rather poetically shows the end of the line for such an application. The technical debt at this point is so high that the interest of the debt itself creates more work than your development team can manage. The black hole has started to suck your company in and there’s no way to escape it’s pull.
So how to avoid this? It’s really simple and ties in well with one of the core principles behind agile software development (and we’re all very agile right?):
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
A piece of software and its tests are one deliverable. Everyone in your organization, management and developers, should understand that you can’t have software without tests. You don’t launch an astronaut on an untested rocket, you don’t drive around in an untested car and you don’t expose your customers to untested software.
Conclusion
There are development methodologies (such as Test Driven Development) and tools that help developers improve efficiency here. Keep in mind to still let your developers make the decisions here: they’re the experts after all and not every approach fits every type of application. But it is important for a business to take this step in development maturity. So instead of letting technical debt accumulate you should invest in time development best practices. It’s a sound long term investment.