Since a key aspect of DevOps is to ensure that deployments are made continuously, as well as effectively, the need to for having tests in place is pretty obvious – untested and faulty code has the potential to mitigate the benefits of DevOps.
Manual testing uses up resources, which can be seen as a waste by developers, especially when they have other important projects to work on. This is exactly why automating tests is important.
Some of the biggest pluses of using automated tests include:
Less Time Spent Worrying About Time-Consuming Issues
When things such as misconfigurations are automatically being searched for, the time of developers and sysadmins can be spent on other things. If the automated tests also offer quick fixes for these incorrect configs, they lead to even more efficient use of time for devs and ops.
If only manual tests are used, the potential is there for IT workers to be lax about checking everything, as they know how long it will take to do so.
Quickly Verifying that Changes Will Run Properly
Being able to automatically test that changes work properly before they’re introduced gives developers more confidence once it’s time to deploy, and it gives sysadmins more peace of mind that there’s a lower probability that they’ll find something seriously wrong with a deployment. Manually testing as a developer programs is a huge hassle that heavily increases the time it takes for delivery.
Again, this is related to the time saved. Time saved from needing to fix issues that could be easily found through automated testing is time spent doing something beneficial to the company. This article has a nice case study demonstrating some of the saving potential that automated testing can create.
Reduces Human Error
Like the cliché, “we’re all human”. Even the best programmers and sysadmins will mess up (obviously, some more than others). This isn’t to say that creating automated testing is guaranteed to be 100% accurate, but if done well, they can be pretty close to it.
The main complaints against automated testing seem to stem from a perceived lack of necessity for automation and from the fact that time/resources must be taken to set up automation in the first place.
“Automation for the sake of automation” is something I’ve heard a lot. This is to say that just because something can be automated, doesn’t mean it needs to be automated (in a way, like the notion “if it aint broke, don’t fix it!” - counter argument: Knight Capital). Maybe a company doesn’t really need to deploy often enough to have a true need to automatically test everything. However, if a company is employing DevOps, it stands to reason that they plan to deploy enough that the long-term benefits of automated testing outweigh the short-term costs.
Short-term vs long-term cost is also the rationale as to why it can be wise to take the time to set up automation now to save time in the future. By investing a bit of time and effort now, an IT department can avoid spending a lot more time and effort fixing things in the future.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.