Left-Hand Column Image: News Section

Industry Insights

View All Articles

Downloads

View as PDF PDF Document

Managing Financial Network Mandate Testing

What do I include in my network mandate test plan?

In a perfect world, every organization could use one "standard" test plan to test mandates. In fact, every organization has different implementation issues, a different collection of products and transactions supported, varied roles (issuer, acquirer, or processor), and so forth. Similarly, each mandate has specific requirements that affect different system processes.

Fortunately, although every tester has a favorite approach to test plan development, there are some commonalities. Developing any test plan means first deciding what testing is required (what processes to include and exclude) and then deciding how to test the included processes (writing the test scenarios and scripts). After the test plan is developed, it should be reviewed by peers (other testers or developers), and possibly by other system users.

Baseline testing

Before you can begin testing changes required by the mandate, you need to run baseline tests. Baseline tests serve to document how the system performed before any mandated changes were applied. If you test only the updated code, you are unable to ensure that a "fix" related to compliance with a mandated item did not inadvertently break something else. Comparing the output and test results from the baseline testing with the output and test results from the updated code enables you to verify that the existing code functions as it did previously, and becomes the first step in ensuring that the updated code successfully adds the function for which it was designed.

Testing requirements

The test cycle involves running and documenting tests on the updated code, reporting bugs during testing, and reporting any other anomalies between the results (or output) from your baseline tests and the results (or output) from testing of the updated code.

Though test plans are different, generally testing requires:

  • Viewing the log files (including input and output log files) to make sure that transactions are logged correctly and the appropriate data is stored
    Are transactions logged completely? Are there unexpected errors indicated by the journal or log that need to be investigated? Does journal file data and reconciliation file data correspond? Are "suspect" transactions noted (but assets unaffected)? Are message responses generated correctly? Do downstream processes reflect online testing?


  • Verifying that all endpoints are affected as desired
    Does the posting and reconciliation system correctly reflect testing? Do batch files and reports correctly reflect the expected test results?

  • Verifying cardholder accounts are updated correctly
    Are accounts debited or credited appropriately? Is the transaction data recorded as expected in the logging applications?
Page 4 of 6 < Previous   Page 1 2 3 4 5 6     Next >

Copyright © 1996-2012, Paragon Application Systems