Posted on 4th Oct 2018 4450 views
A test suit is composed of different scenarios which follow in a functional (or another) way in order to cover the full, or as much as possible, of the ISO8583 Interface implementation.
You should go through your Functional specification document and assess all functionality that you want to use.
Design test cases for all the functionality that you want to use, like below. Also, design test cases for the functionality you do not want to use, to make sure you are blocking it. For example, if you are not going to accept magnetic stripe transactions, make sure to have a scenario that checks that magnetic stripes transaction are failing. This is not very straight forward, because you need to distinguish between transactions that just have track2 data together with other fields, and transactions that have only track2 data. Also, you may want to allow fallback, for example if the ATM is damaged. Many options are avaialbe and a lot of work. We can offer support, consulting advice or even implementation of a complete regression pack.
Let us focus on testing valid scenarios and let us consider a generic interface. What test cases should be present in each scenario.
-- Article writing in progress
Scenario 001 - Network management
Scenario 002 - POS Purchase
Scenario 003 - POS other
Scenario 004 - ATM withdrawal
Scenario 005 - ATM other
Scenario 006 - File update
ISO8583 Message Types for Transaction Processing
Run the neaPay ISO8583 simulator
Log Files in BASE24 classic
Cards and Banks Training
BASE24 documentation to read
BASE24 classic interview questions
BASE24 classic vs BASE24-eps
EMV explained for programmers
BASE24 classic screens examples explained
Enabling traces in the payments simulator
BASE24-eps interview questions
PCI compliant with neapay switch
First steps with BASE24 Classic
Java version for neapay products
Ready to start your next project with us? Give us a call or send us an email and we will get back to you as soon as possible!