Introduction: Legacy Software System
Many of the corporate business software are legacy software which may not be well documented. Before going into details of how to deal with such systems, first let us try to understand what a legacy software is.
A legacy software is the one that has been around a long time and still used to performing a useful task for a user/community, even though newer and more efficient options are available. “legacy” means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. Legacy software systems are programs that are still fulfills a business need or have some potential inherent value but that were developed years ago using early versions of FORTRAN or other languages. Overtime, an unlimited number of modifications may be made to a software based on customer demand, causing the originally well-developed application to evolve on to a complex one.
Why legacy systems still exist?
Legacy systems can be hard to replace, especially when they power important business processes in an organization. They may also be bringing active revenue. So the stability and reliability of the application has real business value. The risk can to too high to upgrade it to a new technology, if you take into account the possibility of key data loss or corruption. Furthermore, legacy application often lack detailed technical specification that is required to create a new system with identical features, making it more difficult. Not to mention the “fear of the unknown” that is present in many organizations.
From banking to lending to insurance, many financial services companies are relying on legacy software to power their day-to-day business. Legacy systems are usually a core system that actually was built to run your financial services company and it can be end-to-end for the business or it can be just a core section of the business.
For example, In insurance sector it is policy admin and billing system. A policy administration system is used to execute a number of core policy processes including rating, quoting, binding, issuing, endorsements, and renewals. It is the system of record for all policies that an insurance company has written. Since there is a high risk of data loss involved in migrating such systems, organizations continue to use the legacy software. Huge cost is involved in such migrations. Also, sometimes there is no reliable replacement in the market that can do the job with the same or increased efficiency.
Testing of legacy systems with no documentation
Legacy software is built over the years and these programs have been maintained and developed for many years by hundreds of programmers. These legacy applications are often delivered based on the specific business needs that may not be properly documented and may no longer relevant in the future. Even the supporting documentation available is out of date or they are just in the form of source code in programming style from the old ages. These factors contribute to the staggering cost of maintaining these legacy programs or continuing their development.
Challenges of testing legacy software
There involves a lot of complexities while testing legacy applications, when they undergo an upgrade or enhancement. Having zero documentation of the software adds to this complexity, increasing the challenge of testing these software. Some such challenges are:
- More time has to be spent on understanding the application behavior.
- Reduced end-to-end testing capabilities
- No documentation of incremental changes/enhancements done on the system
- No information available about the business process followed or improvements done to the process in the course of time.
- Impact analysis takes more time as not a lot will be known about the existing set up.
Testing approaches for legacy software without documentation
We can try to overcome the above specified challenges of testing a legacy application by following some of the approaches,
-
Read the code
When there is no documentation of any sort for a software, the first thing one can do is analyze the code. By going over the code, we can try to understand the logical behavior and workflow patterns involved, which will in turn help in better understanding of the application. Involve software developers and architects who can give an insight into the code and how it works. Reading and analyzing is the first and most important step that will help gather more information on the software, which can be later used for testing the application.
-
Go through the change history
Going through the history of changes done on a legacy software will give an idea of how the software evolved. This gives an indication of changes in the functionality and help understand the change pattern. Analyzing the change history will also help identify volatile and risk areas for failure, which can then be used as inputs to create tests.
-
Application logs
Application logs can give a great insight into the application itself. It will help us understand the pattern of usage of the application, errors or exceptions that occurred in the application and much more. All this can also be used as inputs when we create tests. So analyzing application logs becomes important.
-
Identify possible risks
Identifying possible risks can help create test cases for that area. Risks can be identified by going through the code and identifying vulnerable areas, by checking in what circumstances the application fail or give an exception with the help of logs and so on.
-
Exploratory testing
Exploratory testing is the first step of testing when there is no documentation available for a legacy software. Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. This is process of creating tests as we explore the application. When there is no documentation and it is difficult to identify problem areas, exploratory testing helps in testing the application in an organized manner and also allows us to create test scenarios across different functionalities, increasing the test coverage of the application.
-
Writing tests from top down
We may be tempted to start testing from the bottom of the pyramid and write unit tests first. But it is always good if we start testing a legacy application with critical UI tests. The application may be developed using an outdated technology and directly diving into unit tests will only increase the testing complexity. The goal here is to test the key things of the application that must work.
-
Methodically analyzing existing tests
When working with a legacy application, it is important to check if there are any existing tests. Run the tests if available and try to get reports by integrating with your tool. Existing tests should be used to gather as much information as possible about the application.
-
Regression test
The best way to ensure all the functionalities of the legacy application is to have a well designed and robust regression test suite. Creating regression test suite will help in maintaining the legacy applications and also detect problems when there is some new changes in it. The following best practices can help regression tests get maximum coverage for a legacy application,
-
- Check if there are any existing test suits for the application, which can act as the starting point for the tests and documentation.
- Prepare a business process flow document for existing functionalities of the application.
- Spend some time in understanding the system with business flowcharts.
- Create and maintain documentation of all the findings of functional queries for future reference.
- Identify existing defects and risk areas in the system.
- Analyze and understand the impact of new enhancements and their compatibility with the existing system.
- Identify the go-to person for each module within the application.
- Verify if any component of the application is interacting with other applications and make note of all the dependencies.
-
Dependency driven testing
Legacy System is a mixture of multiple modules and integration points. A slightest of change is enough for impacting the multiple modules or integration systems due to the blend of multiple modules and integration points. Dependency driven testing ensures that the Regression Suite extracted for each release gets maximum coverage with minimum effort. It helps in the following ways:
-
- Understanding how the different modules interact with each
- Finalizing a given release what may serve a challenge due to the undocumented dependencies to regress in the application.
For example, if an application has A, B, C, and D modules, and the module A undergoes change, deciding what we need to Regress would be a challenge. Taking decision on what needs to be tested is one of the best solutions instead of performing testing for all the modules.
Advantages of using dependency driven testing:
-
- It covers tests with direct functionalities/requirements and every functionality that indirectly affects the features being tested.
- Avoids the need of executing whole regression test suite for every small enhancement.
- Reduced effort, time, and money.
Conclusion
Although technological pace is pushing us towards new applications and systems, legacy software is still very much a part of many business organizations. There will be a need for these software to integrate with newer ones and hence testing of legacy software becomes important. Especially when there is zero documentation, following a systematic approach and understanding the legacy software can help us in building a test suite.
Contact us at sales@brainbox.consulting for more information and we would be happy to assist you with testing related services.
