World Class On-Call & Alerting - Free 14 Day Trial: Start Here.
Testing is an integral part of application development. As DevOps practices have migrated operations en masse to Agile development methodologies, there has been a corresponding rise in the popularity of unit testing. Unit testing refers to the testing of the smallest possible testable chunks of code. It has proven benefits when it comes to the reduction of technical debt. Bugs uncovered by unit tests are easy to locate and repair. Unit testing allows developers to work on eliminating tests from the very beginning – reducing expensive bug fixes when code goes into production.
Unit testing is a cause of friction between various camps of QA professionals. While some find the idea of writing unit tests appealing and efficient, other reputable developers think that unit tests are unimportant. Many of these testers argue for more manual QA, arguing that writing and implementing unit tests will be costly and might affect velocity and delivery. They may also say that some applications are simply not set up for unit testing. On the other hand, some QA engineers argue that unit tests are important and ultimately reduce risk in the later stages of the software development cycle.
Convincing management and executives who might not be able to understand the importance of unit testing is a hard job. From management’s perspective, going with the status quo is a safe choice. Depending on which camp they fall into and the tide of opinions within the team, IT managers may be swayed one way or another. If you find yourself having to justify the importance of unit testing to your boss, know this isn’t uncommon, and there are ways to convince a skeptical boss.
Management may not respond well to a more technical explanation of why unit tests are important. However, IT management will be easily convinced by experienced developers when they talk about the benefits of unit testing. This makes it crucial for developers in favor of unit testing to make their point in a language that executives understand and respond to.
Let’s look at some of these points and the ways in which management can be convinced to adopt unit testing without any hesitation.
Unit testing can be tricky to explain to executives. However, when you tell them that a lack of unit testing can ultimately lead to budget overrun, unexpected failures, and inefficient releases, it is bound to get their attention. You can also provide management with data of backlogs from current or previous deliverables depicting how the traditional development process is slower.
Developing a piece of code takes time, and as time passes, the code gets more and more complex. With this complexity comes the fear of breaking something. However, with the implementation of unit testing, this code can be split into several manageable smaller parts that can be easily tested and fixed if a bug is found. This gives developers confidence that they won’t end up causing irreversible damage to their code. Developers can make changes to the code and keep adding newer features to their application without any hesitation.
Unit testing allows developers to catch most, if not all, of the bugs in the very early stages of development. The overall code turns out to be relatively bug-free and refined. The best part about finding bugs early on is that developers can avoid letting hidden bugs enter production and cause serious issues. These bugs could then be found by the user or the quality assurance team, and at that point, fixing these bugs can be really expensive and challenging – especially if developers take on-call responsibilities and spend time fixing these problems, not delivering new features. Therefore, you can raise the point that unit testing helps cut costs by helping find and fix bugs earlier in the development lifecycle.
An application developed without unit testing is inevitably riddled with bugs. When developers develop an application in a traditional manner, they inevitably leave space for fatal errors. Then, they consider rewriting the entire code from scratch. Organizations assume this is all part of the development and maintenance of software, which is not true. Rewrites are extremely expensive and can end up exponentially increasing the time to delivery. However, if an application is developed using unit testing practices, rewriting the entire application can be avoided. It can also help developers change the framework in the future without having to worry about breaking the code or responding to major incidents.
Instead of implying that the organization jumps directly on the unit test bandwagon, developers for unit testing should first propose a smaller use case. Developers should assure engineering and IT managers that they’d like to experiment without any investment. This can be the nudge they need to allow for trying unit tests. Once they get the desired result, developers can demonstrate how unit testing can considerably cut both operational and downtime costs. Then, you can show the many benefits of unit testing to management and dissenting developers, which is bound to get them on board.
Unit testing brings more agility to the application development process. Unit tests allow developers to be more experimental with their application as compared to a more traditional approach while simultaneously helping them to meet deadlines and cut costs.
By understanding an IT manager’s perspectives and fears, as well as the ways to nudge them, you can turn them from pessimists to preachers of the benefits of unit testing. Using all the ideas mentioned here, in true unit testing style, just make sure to break your attempts into small chunks to persuade engineering and IT managers over time to the efficacy of unit testing.
See how QA engineers, developers, and sysadmins are sharing accountability for service reliability and taking on-call responsibilities in a centralized incident response tool. Sign up for a 14-day free trial or request a personalized demo to learn how VictorOps’ alert automation and collaborative user interface leads to on-call incident management that sucks less.
Twain is a Fixate IO contributor and began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces and resolving issues affecting both customers and the support team, as well as handling escalations. Later, he built branded social media applications and automation scripts to help startups better manage their marketing operations. Today, as a technology journalist he helps IT magazines and startups change the way teams build and ship applications.