A lot is written about test automation. Applications should be componentised, mockable, have feature switches, be unit testable, and so forth. In short, applications should be architected with testing in mind.
But what about legacy applications, that are still being developed and supported? Maybe it was some code that was bought, or developed by people who have left. We thought we would share some experiences which those of you who have to deal with real world legacy apps may appreciate, and some strategies for dealing with them.
Legacy applications and development velocity
"Velocity" and "legacy application" are not phrases that are usually heard in the same sentence. More likely, "monolithic", "fragile", "resistant to change", "house of cards" may spring to mind.
Development becomes very expensive, and a chicken and egg situation can occur, whereby you never gain the time and resources to redevelop that application, because the legacy sucks up all your resources:
- Any new feature may required code archeology, depending on how tightly coupled the application is
- Any new release requires through testing, as it is very easy to break things
Ultimately, for anything that is going to live on for a long time, redevelopment with good practices, using the old application as a specification, along with customer feedback is ideal. However, this is a big bang approach, and may not be practical, especially if your old application is consuming all your resources.
An alternative strategy can be a mix of the following, which is depending on how tightly coupled the application is, the skills you have available, and the predicted lifetime of the application. The goal is to give more confidence to the developers, and reduce your costs, so that you can invest in componentising/replacing the legacy app.
- Automate integration testing. I.e. does the release candidate function as it should?
- Identify parts of the application that can be decoupled, and componentise them, defining contracts and interfaces where possible. This starts to make it possible to automate testing in smaller, more manageable chunks.
- Depending on the situation, start to rewrite these components for use in a replacement, or just to expunge very unreliable code.
Tame your legacy application with automated testing
If left unchecked, a difficult legacy application can suck up resources and make planning not much more scientific than tossing a coin.
A quick win is to automate testing of the release candidate. This helps with both integration, and regression testing – major bugbears when living with legacy code.
It will free up test resources, which you can redeploy. Your developers will be able to develop more freely, rather than feel that they are carrying a delicate Ming vase across a slippery floor. Instead of having to wait for manual regression tests, to see the results of their work, changes can be made, and automated tests can be run immediately against builds generated from source control. Problems can be found much more quickly. Managers will have more confidence that bugs will not get shipped, with the support costs that result. If you are using outsourced testing, you can start to reduce your reliance, and your bills.
The question then is, how to automate the testing of legacy applications which are tightly coupled, and have no (or suspect) APIs?
If you lack APIs - use a robot to drive it
A sure fire way of doing this is to replace what your testers are doing, and use a product which drives the UI.
Not all products do this reliably, and some are difficult and expensive to set up. We are a reseller for a great product call Servicetrace. Servicetrace can be used for Application Performance Monitoring, Robotic Process Automation, and Test Automation.
It is possible to create test workflows with no scripting, including error condition handling from message boxes and the like, and we particularly like the patented image technology which means that really reliable UI driven test scripts can be created, even if things move around a little on the screen. Multiple test robots can be deployed, and called automatically – it can also be used to drive load tests. In essence, it can simply mimic a user.
We ourselves once had our own legacy application, and had some of the experiences that I’ve mentioned. I wish this product had been available to us when dealing with it – it would have saved an enormous amount of time and money, and we would have been able to redevelop it much faster.
If you have legacy applications and you want to automate testing, please get in touch to see how we can help.
Training Home →
Resources | Home →
