Emu conversion - The testing perspectives

The scale of the problem

The task of readying an application for the EMU is a similar one to the year 2000 conversion projects. It involves an impact analysis focusing on the identification of currency fields, the conversion of a large number of applications in a limited amount of time, and of course, making sure the new application functions properly.

An added complication is that the transfer to the new currency is a two-stage process where initially companies should provide the calculations in both the national and the new currency, while at the second stage only the Euro will be used for the calculations.

Special problems impacting IT systems

At the back-office, the issues that have to be dealt with include conversion and rounding, decimalization, and threshold values:

Conversion and rounding

It is easy to show that the process of converting national currencies to Euro (or vice versa) will create numerous rounding differences. Some of these differences are avoidable by complying with the strict triangulation rules defined by the EC and some inherently unavoidable.

While these rounding differences have almost no significant financial impact, they create a huge difficulty for today’s financial systems. Without modification, most such systems will find it impossible to cope with even minute differences.

For example, many systems have the built-in capability to match transactions on the basis of their amounts. These systems will not match amounts that are not precisely equal because of rounding differences. Similarly, many systems implement a system of cross checks, for ensuring correct calculations, and these invariably assume identical results.

Decimalisation

In countries with low-value currency units (like Italy, Spain and Belgium), financial systems in use today simply have no provision for a decimal point in monetary units.

Such systems will often have to undergo substantial changes, such as the modification of data types used to hold integer values to data types capable of holding floating point amounts. Corresponding changes will of course have to be done in the layout of screen displays and reports.

Thresholds

Very often financial information systems use threshold values that define the actions of the system. These thresholds must be converted to Euro to avoid unexpected actions by the information system. Take for example, authorisation level. In many enterprises, junior employees may only authorise transactions up to a certain threshold value.

Failing to test properly will in this case have the undesirable result of junior employees that are suddenly empowered to authorise transactions up to EUR 10,000 where the threshold was previously set at BEF 10,000.

The threshold value is sometimes kept in a separate file, making it easy to modify. But more often than not, these values are "hard-coded" and scattered throughout the system, requiring an extensive search, and thorough testing, to make sure all values were properly replaced.

Triangulation

The triangulation issue has received a lot of attention. Clearly, there are a number of views on this matter, questioning the applicability of triangulation rules to EC countries outside the EMU, suggesting alternative but acceptable routes to achieve the same result as triangulation and even how the rules could be enforced.

From the testing viewpoint, all this is academic. No matter which algorithm you choose to implement, you will have to verify, at one point, that the result achieved is indeed equivalent to the result as derived by using the triangulation method.

As described below, using a simple find-and-replace mechanism, each currency field can easily be verified, using a proper implementation of the triangulation algorithm, to make sure the desired result was reached.

Time scale

From the point of view of the testing effort, testing applications converted for the Euro is similar to testing for Y2K compliance. The best course of action is to start testing as soon as possible. Some aspects of the testing process can be started immediately.

For example, integrating a source code scanning tool which will highlight problematic areas with a test management tool allows organisations to get a head start - and be prepared with an automatically created detailed test plan even before the application has been converted.

Regression testing methodology for the EMU

It is essential to check that the new programs work at least as well as their predecessors. The new programs should be subjected to all the tests that the old version satisfied, with test data updated to include the new currency formats.

A recommended testing methodology, using automated software testing tools, would be based on a simple record & capture paradigm to create test cases, so that even a non-skilled person, in a data entry capacity, could be employed to create all the basic test cases. This phase can be done on the system existing today, using the local currencies.

Then, a mechanism that enables find-and-replace of currency fields during replay & verification could be used to automatically run the same test cases, with updated input data and expected results, in the new Euro amounts. In this manner, test suites that are created today are re-used for testing the system after the conversion, saving valuable time.

Conclusion

As can be seen, preparing information systems for the Euro is more complicated than it appears to be at first sight and should not be underestimated. If the effort required for the year-2000 conversion is any indicator, when modifying IT systems for the Euro testing will once more make up the bulk of activity.

Thus, one of the main challenges is cost-effectively testing your new system, after making the required modifications. Manually testing any new system is time-consuming and error-prone. Using automated testing tools; you can start testing sooner, test more effectively, and fix production data problems earlier.

Mercury Interactive