A recent project I was on meant testing a lot of legacy code, in fact I think it was all legacy code! So I thought I'd write some bits about what the challenges are or what you should look for.
Firstly, let me start by defining what I mean by legacy code. I have seen
definitions of legacy code which state any code without unit tests can be
defined as legacy, whilst this is true, I also like to think of legacy code as
something that isn't being refactoring, isn't being improved upon, it is what
it is, to quote Ronseal "it does exactly what it says on the tin".
The problem with the Ronseal analogy, is that what happens if you can't find
the tin? Or you can't make sense of the tin? This brings me onto the first
challenge... In that if it is legacy code, and there's no supporting
documentation around how it works or what certain features are for, then it
makes our lives as testers (and developers) difficult. We have to ask questions
over what certain things do, and more often than not the person we ask won't know
either. This tripped me up in the projects first release, and I'm not too
ashamed to admit, but we had to rollback the release due to a bug about us not
truly understanding some legacy feature. This was a good lesson, we learnt from
it, and we were far more cautious and inquisitive about future releases. We
made sure we understood everything.
Which brings me onto the next challenge/tip. Make sure you understand
everything around the legacy code that you are testing, if there's
documentation, read it, if there's questions that need answering then ask them.
There is no such thing as a stupid question! This will all help drive your
testing and helping you decide what and how to test.
Another challenge around how to test legacy code, is that you are often limited
by what has been developed in the past, for instance we wanted to perform
performance testing on an internal application, but we had no scripts for this,
performance testing of this application wasn't ever considered necessary, until
now. The problem is that we needed performance testing, as we were increasing
the amount of data for certain calls. We didn't have time for anyone to develop
performance tests, so we had to decide to perform the testing at a lower level,
by testing the sprocs that retrieved and set the data, this gave us enough
confidence, and was relatively quick and easy to do.
Finally, with there being no unit tests on the code, and no automated tests
that worked, we were forced to do more manual testing than I perhaps would have
Despite the above challenges, we successfully released the project on time.
A lot of this was down to how we managed the releases and released small pieces
in quick succession, for instance had we released big bang and found the bug
that caused the first release to be rolled back, we would have had to rollback
everything which would not have been fun!
So there you have it, a few challenges that I came across when testing on a
legacy system. What challenges can you think of? This post started with the title
"Testing on legacy code", but I think if you replace the word testing
with developing for this post, a lot of the points will still hold true,
it's not just about testing but engineering on legacy code. I know you can make the case that the above is everything you should be trying to achieve when testing any code, but I think when testing on the legacy code, the above points are even more important.