Anyone who has experienced working with legacy applications knows that there are many challenges in testing systems with old codebases. Outdated (or non-existent) documentation, old no-longer supported technologies, and lots of multi-system integrations causing all sorts of “fun” issues are just some of the most typical issues.
A lot of my testing experience has been working as a tester on legacy systems. In this post, I will share some advices that will make your life easier if you are also working as a software tester on a legacy project 🤗
Identify Potential Sources of Information
Documentation can be scarce and/or out of date, so it’s important to identify places (or people) that can provide you with information about the system under test. It will also aid you in identifying the test oracles. It is unlikely that one person will have all the answers, so you will have to be proactive in your search for information. But a lot of people will be at least able to point you in the right direction.
Typically, even the people who are there for a long time might only know a small part of the system (the part they’ve been working on the most). Try to get a general sense of all the components in the system, like things that link architectural diagrams and mind-maps.
Talk to the Domain and Technical Experts
On these legacy types of projects, a lot of knowledge is passed down without it being written down 📝 Talking to business analysts, testers who’ve been working on the project for a while, or really anyone who’s been there for a long time period can be very informative and useful.
Talking to the developer will help you understand the system from a technical perspective and answer questions that can help you with test automation. What are the most common environmental issues in the project? What are the biggest integration pain points related to system-to-system communication? Which aspects of the business logic are causing the most conduction, etc.
People from different roles can give you different views on the system, so you as a tester can create a wider image of the system in your mind.
Pair Testing With a Tester From the Project
Watching a more experienced tester from the project navigate through the rusty old legacy systems can be an invaluable experience, even if the project is well documented. Seeing and taking part in practical testing is the most realistic way of getting to know the product. When pairing, be sure to actively participate, ask many questions, think about different scenarios, and be curious and open 🧐
Do Regular Focused Exploratory Testing Sessions
The importance of exploratory testing is often neglected and sometimes confused with ad hoc testing or monkey testing. To get the most benefit out of it you should narrow down your focus on a certain part of the system.
Gradually, over time, you will become the domain experts after exploring the app, and you will also most likely discover edge case issues that will go unnoticed when performing more predictable (scripted) types of testing.
Keep your exploratory charters short and concise. As legacy systems are generally complex and have a lot of widths, you need to explore them bit by bit.
Decide What is Worth Automating and What’s Not
Test automation can help make our lives easier in any project, especially when dealing with vast legacy systems. On the other hand, automation is not a silver bullet that magically fixes all problems. It can actually make things harder for us if we go about it the wrong way ❌
Trying to automate everything, automating without properly analyzing the system under test, investing too much in UI automation, not taking into account complex system integrations, having unreliable test data, and working with unstable test environments are all examples of it.
I’ve seen test automation frameworks that were perfectly architectured and built using all of the coding and automation best practices, but most of the tests were coming as either false positives, or more often as false negatives.
There are many reasons behind this, for example improper use of mocking, unstable environments, lack of valid test data, too many tests on the UI level, and lack of communication between different teams.
source: https://www.commitstrip.com/en/2019/03/13/like-a-good-wine/
Conclusion
Testing legacy systems is demanding, and getting to a point where you feel comfortable testing such a system takes time and effort. To summarize: take your time to get to know the system and the people working on it, explore continually in regular increments, don’t avoid asking for help, don’t blindly automate features you don’t understand well, and use automation as a way of making testing easier ✨