Legacy Testing

Legacy Testing: The Roadblock To The Future

Many articles or blogs are written on the daily on platforms such as Linkedin with titles along the lines of:

Agile testing for the future!

DevOps encouraging the next wave of exploratory testing!

Automation the future of testing!

…And so on. They are all looking at new technologies: mobile, AI, Cloud and VR. That’s all well and good, however in the real world we have to deal with Legacy integration and that’s usually where things get really tricky. Allow me to explain…

Firstly, no one ever estimates for Legacy work.

How many times do projects just want an estimate for the new functionality or new application or product? We try to build into our test estimations enough regression testing or legacy integration testing, but this is always, always the first to be reduced or, in some cases, cut out altogether. “I’m only paying for testing the new code/functionality” is usually the comment you get back from the PM, as if the money is coming directly out of their pocket!

Secondly, no one ever takes responsibility for Legacy work.

Projects only ever believe their responsibility finishes with the delivery of the new shiny application or product. No, it does not. The impact and all the subsequent changes to the existing code is the responsibility of the project and therefore the testing of it is vital.

Thirdly, if the application was not automated at the time, retrospective test automation is very, very hard.
Legacy Testing

Usually any or even all documentation relating to a legacy application is very much out of date and has not been maintained. Therefore understanding what a legacy application is meant to do is tricky, especially if you are new to the organisation This usually involves lengthy discussions with BAU support staff, who are under pressure anyway due to production issues and incidents that need reviewing, assigning and resolving. All this, before we even get to the point of who pays for this automation effort. BAU usually has a limited bucket of resource money. Projects have a significant amount of money, but they only want to spend it on the new shiny stuff, so if no one wants to pay for the automation effort it doesn’t get done.

But it’s just the legacy application…..”

I hear these people cry. The problem is that the integration between new and old is the favourite living space for all those bugs: it’s a perfect environment for them to grow and become major incidents.

Managers always say “Testing is always too expensive…” Well, it is! This is because, unlike anyone else, we have to play in the past, the present and the future.

The problem is that so much of the present and the future of applications is built on the foundations of the past and, if you don’t look after your foundations, any new building on top will come falling down at some point…