Dealing With Legacy Products And Code
Any company that's been around for more than a few years will have accumulated legacy code. Sometimes a lot of legacy code. It's not uncommon in smaller organizations for the legacy code to be the entire codebase, including one or more legacy products. It's often easier and cheaper, for the short term, to keep patching or only changing what’s necessary rather than rewrite the application from the bottom up.
In younger organizations like startups, you could come in after a few years. In these cases, the legacy challenges will be different than the challenges facing testers who join a long-established company as the first tester. Either way, you will need to explore the application and the code as much as you are able so you can understand the business rules as well as the challenges that are unique to the software you are testing.
Sometimes legacy code can be a good thing for testers: it can be stable, well-understood, and give very few problems. Or it can have all manner of unexpected pitfalls concealed within what appears on the surface to be a stable, well-mannered (if sometimes elderly) piece of software. Or you could find yourself looking at bizarre, over-complicated workflows, or arcane modes of data storage and wonder what - or if - they were thinking.
Haunted By Someone Else's Past
Depending on how long your employer managed without testers before you rode in on a metaphorical white horse to help slay the demons of buggy code, you could find yourself dealing with the aftermath of interesting decisions made long before your arrival. It is, after all, extremely rare for a solo tester to join a completely new project with no code at all.
Because of those decisions and the structures they impose, it will impact the testing choices you can make now. Sometimes it can take a lot of research and investigation to find the reasons behind decisions. Those same decisions, which may seem to you to make no sense until you learn more about the history of the original decisions, which were probably sensible for circa 2001, can look looney in a 2017 context. Â
Yes Virginia, Mainframes Still Exist
My current position includes supporting applications that act as a thinnish client to a mainframe. The mainframe is the data Oracle and performs all the complex calculations required by the applications. One of the challenges this structure imposes is that real-time processing doesn't happen: the applications I work with do their relatively limited processing work then format the results into something the mainframe will accept. The mainframe does its calculations and drops the output file into a pickup directory, which my applications pick up and process. On quiet days, this can be completed within a few minutes. On busy days, it can be hours before the full sequence completes.
We have to build the impact of the mainframe's processing model into every enhancement to our applications because there is no alternative.
As a solo tester and/or the company's first tester, you don't have other testers who are familiar with the organization culture to explain to you why these decisions were made. This is where you need to remind yourself that whatever the situation looks like now, the decisions that led to it were all made for valid reasons.
Tact is really important when you're investigating legacy code and older design decisions. Keep in mind that computing is a fairly new industry which has evolved fairly quickly. Knowing about the progress of technology and its impact on a specific domain might be a good way to help understand why a company might still be using mainframes or working with an older version of Windows, or Java. In a great many cases, companies adopted computers and technology to survive, not to innovate.
The Genesis Of An Idea
Once you know you've got some interesting legacy issues to deal with, the next step is to understand why they're there. In my experience, there is always a valid reason that legacy issues hang around like last year's cold.
You want to investigate and learn about the history of that legacy. Learn the domain. Sometimes decisions seem really strange until you understand that there's some kind of factor dealing with the domain that helped inform the decision. Learning the root causes for decisions means when people ask why something is a certain way, you have the answers to those things and could possibly influence the direction of them in the future.
My preferred way of finding out why things seem less than ideal works a bit like this:
I start by asking my team members who would be the best person to ask about the history of the application, because "I'm trying to understand how the application fits together and I'm finding X a bit confusing." Usually, someone who works with me has been with the organization long enough to know who in the company might be able to help.
The best people are often those who have been with the company the longest - this is a good second step if I don't have a specific person to ask.
I'll also check some of the other departments. Long-time customer service folks can have a lot of information about why something came about. Training, marketing, or sales can also be helpful.
If it's possible to ask a long-time customer about how X works for them, I'll do that, too. It all helps to understand why the application works the way it does.
Remember, you're searching for the assumptions which are behind X, but unless you're extremely fortunate you're not going to be able to ask directly. The history of X should give you an insight into those assumptions, which in turn will tell you why people made a particular decision.
Testing The Legacy
No matter why legacy code decisions were made, you still need to test the software. Michael Feathers has written a wonderful book about working with legacy code. It's mostly from a developer perspective, but it has a lot of useful information for testers, too.
Testing legacy software can challenge you in unexpected ways. Some older software is extremely unfriendly towards automation. The software could be impossible to unit test effectively because the user interface and business logic are intertwined, or the UI components used could be opaque to test automation tools. You could be limited to black box testing with little if any logging. Or the tools which used to work with the software are obsolete and/or next to impossible to find.
Some techniques I've found useful include:
Explore the software - I'll play with the application, taking note of what happens when I use Setting A compared to Setting B. If I have access to the data storage, I'll examine that once I've made a change to see if there's some kind of data transformation going on.
Read any documents available - Any documentation of the application is valid here: I'll read training documents, release notes, specification and user story documents, even old test cases. What I'm looking for with my reading is to learn what the application is intended to do under which circumstances. As a rule, application behavior isn't changed, it gets added to or has behaviors removed, so even out-of-date documentation can be useful.
For example, software that accepts payments might add payment types over the years, or remove payment types that are no longer used. It usually won't change the behavior to accept a specific payment type unless the rules of that particular form of payment change.
Read and explore the code and data storage - If you're not that technical this may seem intimidating, and with some legacy code it can be intimidating even if you have a very strong technical background (I speak from experience here), but it can also help to understand what the application does behind the scenes. This is particularly important when you're learning which parts of the software interact with other modules. In legacy code, it's not rare to find a lot of tight coupling and interrelationships you wouldn't expect.
Ask for help - My personal rule is that if I spend more than a couple of hours trying to understand something with no result, I ask someone for help. Don't be afraid to ask for assistance with something. You may be the only tester in the team or the organization, but there are people around you who are intimately familiar with the software you're working with. They won't mind a polite request for help, and the worst they can do is tell you they're not able to help.
Resource Scarcity
Another common technical challenge is a scarcity of resources. As the first tester, you might be working in a smaller organization, which usually means a more limited budget than you might find in larger companies with full testing teams. In addition, it may not have occurred to anyone in the organization that there would be a need for a separate testing budget.
There are ways to work around scarce resources. You will need to be flexible and creative, but you can gradually build up a set of resources to use. Regardless, make sure you keep things simple and try to avoid adding things unless they add value to your work.
Invest In Your Own Equipment - If your organization allows you to bring in devices, invest in a USB hard drive. You can buy 1TB hard drives for relatively little cost, and the extra storage - while slower than a built-in drive - means you're less likely to run out of space on your main drive. That means you can keep a lot more reference material.
Use Free Software - You can use a free virtual machine manager to keep dedicated environments on your work machines (especially if you are able to add extra drive space). You may need to close everything else down while you test that IE 8 on Vista issue, but you can still do that testing.
Reuse Old Equipment - Ask your organization for retired machines. Dedicated systems to run a specific browser/operating system combination for testing don't need much in the way of fancy hardware. You might have to rehab them yourself, but once you've done that, you will have them available.
Test Environments Don’t Need The Latest & Greatest - You can also use retired machines to set up test environments with specific configurations. I've done this many times.
I kept a set of dedicated test environments mimicking customer configurations. These were all setups that took me at least an hour to build because of the complexity of the configuration. Having them as a dedicated, permanent environment didn't just save me time - it meant I could point developers to that environment when there were issues with those customers that couldn't be replicated in any other environment.
Open Source Is Your Friend - You can often use free or open source applications instead of their paid equivalents. If you have the permissions to manage your machine, you can install freeware or open source software yourself. Some of the free/open source software I've used includes:
Notepad++ - my favorite open source advanced text editor.
Jing - handy screen capture and short video tool
Guerilla Mail - Perfect for throwaway email addresses when you need to test a registration process that requires responding to an email and expects a unique email address for each registration
Slack (especially the Ministry of Testing channel) - Wonderful collaboration tool and the Ministry of Testing channel is invaluable.
Don't forget that your time is also a resource and will be scarce. You're going to need to try to maximize the amount of time you spend in productive testing.
Challenge Accepted
Part of the process of solving the challenges you'll face as your company's first tester is setting expectations for your manager or supervisor and for your developers. It’s a process I refer to as "training" your manager and developers. The final installment of Blazing New Trails will give some advice and information about level setting and teaching your manager and developers what they can expect from you and what you expect from them.
Where Can I Get Support?
Ministry of Testing - I use the Ministry site as a portal to The Dojo and The Club. The Ministry's Slack channel is also awesome. Â
SQA Stack Exchange is a great place for specific questions
Jing is my favorite free tool for quickly getting screenshots and creating short screen-capture videos.
Notepad++ - my favorite open source advanced text editor.
Guerilla Mail - Perfect for throwaway email addresses.
Working Effectively With Legacy Code by Michael Feathers is an excellent book about legacy code.
