Testing Multi Currency Applications

Want to be a player on the world stage, doing business globally? Then you need to be able to handle money worldwide.

 

Multi currency testing is complicated

Testing multi currency applications is difficult because it permeates the entire application. Once multi-currency settings are applied, it will penetrate all of the data and how it is processed.

It is like adding salt while cooking, it is impossible to get the salt out. Even worse, you can’t just add more food or water to dilute the salty flavor. As such, for most applications supporting multi-currency, the multi-currency setting switch usually cannot be turned off once it is activated.

When testing multi currency software, you’ll also understand when and what currency should be used in order to thoroughly understand the business viewpoint when designing your tests.

This impacts how to prepare test data and how to do data validation testing. With this knowledge, we can test the most likely scenarios that the users will encounter, instead of hitting the corner cases too hard.

 

Much more than translating between currencies

This includes exchange rate along with FX  (Foreign Exchange Rates). With multi currency, testing variance analysis should take FX variance into account.

For instance, the account balance remains the same for both 2016 December and November. But the exchange rates, say EUR to USD changed from 1.1538 to 1.0637. The rate fluctuation will cause variance. So we should have this test scenario covered as well.

Technically, the rate can be stored in any number type, float, double, decimal, integer or others. From a computing calculation perspective, data preparation should take this into account. The different data types will make a difference in the resulting amounts. This could make things off by a few cents here and there, but  or account reconciliation and certification processes, this can stop the certification.

The exchange rate, whether imported or manually input, should use ISO 4217 currency codes, a standard used in finance-related software. Using ISO 4217, it will only allow user to input 3 characters such as USD or EUR, instead of the full currency name. If the full currency name gets typed in but it cannot be saved, the user — and hence those in QA — need to recognize that this is not a bug.

When implementing thresholds as part of your system configuration, you’ll need to set the difference less than the threshold and above the threshold to test each currency. Then you’ll need to make sure what currency the threshold applies to.

Ten cents in Euros is much (used to be over 1.5 times!) more than 10 cents in USD, so you must ensure that you use different threshold settings for different currencies. This is just one example of the boundary test and equivalence class type tests that you’ll need to understand and prepare appropriate test data.

Testing multi currency applications involves more than just simple division and multiplication to go from one currency to another. Although it may seem simple (yes it’s just arithmetic), you can’t go backwards once you implement this feature in most software.

Be aware of business rules, because overlooking or forgetting one could end up costing you a lot of money.

Save