IT Application Evolution Software Renovation? Testing Reduces Costs and Risks
Software renovations involve extra costs and risks. As a result, they are generally postponed until this is no longer possible, for example, because base components have been decommissioned or new technologies can no longer be integrated. Read our article to learn how automated testing can help you reduce costs and risks when embarking on a software renovation.
Companies' application landscapes have usually grown over years. To meet new business requirements, existing applications are constantly extended or adapted. This leads to higher efforts for further development and maintenance, making a renovation of the application landscape finally inevitable. Applications are replaced by several new components or licensed services. At the same time, it may be necessary to move databases to individual devices, group business functions in services and distribute user interfaces to specialized components. In many cases, the new application increasingly interacts with external applications, services and components.
Major renovations imply extra costs and extra risks. As a result, companies avoid them for as long as possible, especially if business-critical systems are involved. Of course, putting renovation off does not reduce the risks. And this is where automated testing comes to the rescue. It helps you to identify risks at an early stage and to continuously ensure that the measures you take are helpful and the system as a whole still works as designed.
A multi-dimensional approach
In today's business environments, a business process usually involves several components, the output of one component serving as input for the next one. Every test, regardless of level or area, must show that a certain input generates a certain output and that it triggers the desired actions (e.g. storage of data). To this purpose, in a first step, input/output mappings need to be defined from a business perspective. Testing then proves that the business requirements are met. When a component is replaced, continuous testing proves that the application produces the same results after the renovation as before.
To achieve a comprehensive test coverage, tests have to be set up on several levels:
- In a first step, component tests are performed to test processing of data by individual components. An application in a distributed system, for example, may be treated as a component. Isolating a component may be a challenge, e.g. if the business logic is defined as one component while the data is kept in a different component together with the storage mechanisms.Component tests only provide partial answers. They do not give any information on how components communicate with each other. Their purpose is to check the logic within an individual component. Also, they test the generation of requests and the mapping of responses from other components. Test doubles are generally used to test the request-response cycle in a reliable and reproducible way and avoid dependency from the availability of external components.
- Integration tests focus on communication. They test how components relate to each other. This is particularly important when external components and services come into play. These may be located outside of the application system to be tested and, thus, outside of the application team's responsibility. External services that provide input for business processes are often simulated by using test doubles. This also allows testing of the configuration of various components. It can be tested, for example, whether the business logic in one component works smoothly with the database of another component. The tests need to prove that the components are well integrated, regardless of storage mechanisms or more complex integration patterns.
- End-to-end tests make sure that the application system as a whole runs smoothly. On the one hand, the system needs to meet the business requirements, i.e. it needs to support the defined workflow and process business information correctly. On the other hand, it has to ensure that firewalls, load balancers, proxies and registries are properly configured. End-to-end testing is the last step in a sequence of multiple tests.
To ensure that testing returns meaningful results already in the development phase, the tests must be carefully graded. End-to-end tests should only be used where absolutely necessary, as too many end-to-end tests make testing time-consuming, expensive, and thus inefficient. For proper end-to-end testing, all applications, staff, and infrastructure components must be available and the test data must be synchronized across all applications. Also, in some cases, end-to-end tests may last several days, and they may involve manual interaction such as scanning of forms. When external parties are involved, end-to-end testing becomes even more challenging.
Therefore, especially for highly complex distributed applications and application systems, to arrive at an effective testing strategy, an important first step is to analyze the IT architecture. The analysis illustrates from different perspectives which components are involved, how they interact and what additional factors need to be considered. In a next step, based on the results of the analysis, components, test methods, test processes and test cases are defined that are capable of effectively supporting a renovation. Throughout the renovation process, automated testing shows whether the measures have the desired effect and how they affect the system as a whole. This helps you identify risks at an early stage and supports targeted decisions.