Legacy systems do not have to be the anchor which holds a company back from aggressively competing in today’s high speed markets. Moving to an automated testing strategy can make the difference in maintaining competitive advantage.
The emphasis of Agile, as demonstrated in the Agile Manifesto, is on a set of values pertaining to how we treat each other as human beings within the context of delivering software, which has value to other our clients. Respect, integrity, collaboration, and communication are virtues that result in superior outcomes for all concerned. DevOps capitalizes on those values and focuses on continuous delivery of value to production environments. It moves the ball forward from “potentially shippable” to “shipped” software.
In a recent article in DZone entitled DZONE’S Guide to Continuous Delivery, I was encouraged to see the importance of quality emphasized to be as important as speed of delivery. In the article by Andrew Phillips three points are elaborated. They are:
- Continuous Delivery is about shipping software better, not just more quickly.
- As the scope/size of changes in the pipelines get smaller (and pipeline runs more frequent), validating existing behavior becomes at least as important as verifying the new features.
- We need to go beyond automated functional testing and add stress and performance testing into our pipeline to validate the behavior of an application at scale.
Phillips is clear that, “… pretty much every Continuous Delivery initiative that gets off the ground quickly realizes that automated testing—and, above and beyond that, early automated testing—is essential to building trust and confidence in the delivery pipeline.” Why is that?
There are several reasons why automated testing is essential to continuously delivering value to the customer. The first is that automated tests provide an executable specification of the requirements of the application feature being developed. We know we have written the right code, not just because it compiles, but because it does what the test specifies it will do. This early feedback can be at the unit/module level, the integration level, the end-to-end functional level which is often used as acceptance tests from the user standpoint, as well as the load and performance level.
If the desired direction for the delivery team is putting new features into production quickly and with high quality, then testing must be automated and a complete set of tests must be created from the very beginning of the development/delivery cycle. What about legacy systems?
With legacy systems, new features can be fully tested at the unit/module level, but there are often challenges with testing legacy code, which is impacted by these new features. Retrofitting legacy systems is addressed in a white paper by Jenny Stuart entitled, “Retrofitting Legacy Systems with Unit Tests”. In it she discusses such topics as:
- Reasons to Retrofit
- How to Decide the Approach to Building Out Unit Testing
- Selecting strategies for incrementally building out coverage
- Creating the Necessary Infrastructure
- Investing in resources
- Select unit-testing tools
- Integrate unit tests with the build system
- Train staff how to perform automated unit testing
- Incrementally Improve System Testability
- Incrementally refactor the system
These are all important factors in improving legacy system testability and in moving to a Continuous Delivery model. The practical benefits of improving legacy systems through automated testing as part of a DevOps/Agile initiative reduces risk and improves the speed of feature delivery.