DevOps Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Why Automated Testing is a Must for DevOps

04.26.2011
| 4962 views |
  • submit to reddit

You’ve heard a lot about test automation. But why is it so important? It’s a lot of additional effort and adds lots of code which needs to be maintained later, right?

DevOps Favors Continuous Releases

One of the important parts of any devops process is the regular release of working software. In Scrum, iterations tend to be only one or two weeks long. When you use Kanban you release whenever a reasonable package is ready – often multiple times a week. When you do that, you will inevitably see that manual testing becomes a bottleneck. Always.

The Fairy Tale Of The Test Cycle

If your team is not able to test everything as soon as it is ready, they soon will ask you to introduce one or two week long test cycles. They tell you that in that time they can do all the testing and that you’ll have a stable release afterwards.

Unfortunately, nothing could be further from the truth. The later you test, the more effort you’ve got to spend fixing bugs introduced weeks ago. And as the code is changing during the testing weeks, every test cycle you do has to be repeated. In the end, your software is no more stable then it was before the test cycle.

Test Automation To The Rescue

The only way to support a rapid cadence of releases is to automate testing. Only if you use unit testing during implementation you can be sure that a bug fix or refactoring does not break anything later. And only if you use webrat or any other tool to do integration testing can you afford to skip the manual regression tests.

Fast releases drive manual testing efforts through the roof. Automate the critical parts step by step and you’ll be ready for continuous deployment.

Getting started with automated testing is not easy. What are the biggest stumbling blocks you see? Let us know in the comments!

References
Published at DZone with permission of Daniel Ackerson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Muhammad Faiz replied on Fri, 2012/04/13 - 8:54am

Testing is awesome. If you’re writing new code there’s no excuse not to write tests.

The biggest problem I see with testing is that it stops as soon as it gets into production. The monitoring checks we run in production can be thought of as extremely lightweight unit test that don’t get you a lot of code coverage.

That said, running unit or integration tests in production can be quite tricky as they generally require setting up some sort of state before the test can run. When running these tests in development, most of these tests insert test data directly into the database, but in a production environment you generally don’t have (or want) that luxury.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.