Testing a Legacy Application with Zero Documentation

Legacy Applications – Definition and Significance

70% of corporate business systems today are legacy applications. Recent statistics prove that over 60% of IT budget is spent on maintaining these Legacy systems, showing the rigidity and the fragile nature of these systems.

What is a Legacy system? Any system independent of internet, an old method, technology or application program, a system that has been inherited from earlier versions, or an application built by an organization that is currently inactive may be termed as a Legacy System.

Legacy Application are built over years and hold most of the business logic. In this business model very few employees carry requisite knowledge of the business process. Most of the legacies do not have proper documentation which makes it even more challenging to understand them. These systems are maintained with earlier versions to avoid risk and cost. Companies deny on upgrades as these systems would be stable for quite a long time.

Replacing the legacy systems may not be the solution given the risks and concerns involved. With strong migration methodologies and reengineering techniques, migration may still be possible but it involves time, and maintaining and testing them during these situations is tricky. If there are multiple users involved, the application is fairly stable, and if the business users do not request for large number of system changes, companies continue with using the Legacy Systems.

Testing Legacy with Zero Documentation

Many of the Legacy applications may not be well documented because these systems have been delivered based on the specific business needs that may no longer be relevant. This adds to the inefficiency and high maintenance costs of many legacy systems. Even the documentation available is out of date and inadequate, and in some cases source code is the only documentation.

Challenges

Testing such applications involves many intricacies whenever they are undergoing enhancements or upgrades. Testing with no documentation only adds complexities such as:

• Reduced capability of testing end-to-end functionality
• No information about:
  • improvements in business process in the due course of time
  • upgrades/customizations/enhancements in Legacy Systems that impact the other associated systems and existing functionalities
• More time spent on Impact Analysis

Solution

Having a very well designed Regression Suite ensures that all the functionalities in the application are intact during any release. Following are some of the best practices to ensure that the Regression Suite gets maximum coverage:

• Prepare business process flow documents for the existing business functions
• Check for the existing defects, and derive the complexities and risk areas in the existing system
• Prepare presentations with business flow charts to help others understand the system
• Understand the impact of new enhancements and derive the best fit within existing functionalities
• Maintain a library of Knowledge Transfer sessions and functional queries to reduce the iterative work
• Identify the go-to person for each module within the application and make sure that all your scenarios are thoroughly reviewed
• Verify if there are any unit tests. If yes, they should help as a starting point for documenting your tests.
• There is every possibility that some functionality in your application could interact with multiple applications. List all dependencies and make sure every dependency is covered in the Regression Testing.

Dependency Driven Testing Approach

Legacy System is a mixture of multiple modules and integration points. A simple change can impact multiple modules or integration systems. Dependency Driven testing ensures that the Regression Suite extracted for each release gets maximum coverage with minimum effort, and helps

• Understanding how the different modules in the application interact with one another
• Finalizing for any given release what may serve a challenge due to the undocumented dependencies to regress in the application

Our ‘Dependency Driven Testing Tool’ aims to cover all areas that would be impacted if one area of the application undergoes change. For example, if an application has X, Y, Z, and W modules, and the Module X undergoes change, deciding what we need to Regress would be a challenge. Also, instead of performing Testing for all the modules, taking decision on what needs to be tested is one of the best solutions. This is the point where the tool would come as a great help. Input for this Tool would be a thoroughly reviewed Matrix highlighting all the modules/integrations and their inter-dependencies.

Following are the advantages of using the tool*:

• Ensured Test Coverage for an application including not just the direct requirements/functionalities but also every functionality that indirectly effects the feature under test
• Reduced pain of executing the whole regression test suite which could be in a huge number for every small enhancement
• Reduced effort, time, and increased savings

*The only way this works most effectively is when the user has a complete understanding of the application and the enhancements for which Regression Suite is built.