I work on manual/functional testing of a Banking/Payment web application. This application allows cash transfers from many different savings/checking accounts to a central account which corporation use to improve cash flow and liquidity. I can test simple scenario's like ACID principle of Database transactions must be followed. Front end is built in Asp.NET MVC and SQL Server 2012 is used in back-end.

I am having problem with generating out of the box test ideas/scenarios. I am good at testing positive use cases but dont think from different angles.My focus is not on test automation/api testing but on core functional testing. A customer can create/delete/update profiles(accounts) and can do a lot of other things. Please help in devising a test strategy for testing a Payment gateway, so that i can do more negative testing?

closed as too broad by bish, Helping Hands, Kate Paulk, ECiurleo, Niels van Reijmersdal Dec 28 '15 at 18:09

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Are you looking for a testing strategy for a whole banking application or just the payment gateway? – demouser123 Dec 25 '15 at 16:24

For Banking Applications :

Banking applications are one of the most complex websites, from a testers point of view. They :

  • Have loads of functionality (Money Transfers, Credit cards, Reports, Billing, Payments)
  • Large Scale Integration- of the various functional modules listed above
  • Complex Business Workflows
  • Real time processing
  • High rate of transactions
  • Transactions that should be ultra-secure
  • Tons of reporting
  • Need a massive storage system
  • Should be prone to disaster

So, when you say, that you want to devise a testing strategy, for a banking application, you need to keep the above points in mind and then design your tests and testing strategy accordingly.

When talking about a banking application, a testing strategy should, include end-to-end testing methodology, involving multiple software testing techniques. Your testing strategy should ensure that

  • Total coverage of all banking workflows and business requirements is achieved.
  • Key aspects like Security and Functional testing should assigned top most priority.
  • Data integrity is maintained.
  • User Acceptance/Experience should be good.

Keeping in mind, all the above core points, I would, hypothetically device testing scenarios that would include and cover the following testing :

  • Integration Testing
  • Functional Testing
  • Security
  • Database Processing/Storage
  • Load
  • User Acceptance and User Experience

Now, you have to go further down in the listed types (and these are not limited to this in any way), and design your test cases, to ensure the points mentioned above are covered.

This link by Guru99 website has a good number of scenarios listed for login in a banking application. You can take a reference from this.

Another good read is this.

For Payment Gateways :

Our very own and beloved Kate Paulk, has written a well explained post here : Payment gateways checklist

This should be enough to answer your queries.


Based on:
This application allows cash transfers from many different savings/checking accounts to a central account which corporation use to improve cash flow and liquidity
A customer can create/delete/update profiles(accounts) and can do a lot of other things

I would make sure you have test cases that check:

  • Account identifiers are for valid accounts
  • From and two accounts/users are not suspended
  • There is enough funds in the from account
  • Transfer amount is numeric with up to 2 decimals for cents
  • Transfer amount is positive
  • Transfer amount is reasonable, e.g. < $1 million
  • Differences based on which account the transfer is from are correct
  • Sum of the two transactions (debit and credit) is zero
  • Multiple 'from' accounts can be specified if this is a requirement
  • Date used for the transaction is valid and correct
  • Any relevant user or job ids are recorded for the transfer correctly
  • Any transfer code used can be seen in the audit trail
  • A customer can create a profile
  • A customer can't create an admin
  • A customer can update a profile
  • A customer can't update another customers profile
  • A customer can delete a profile
  • A customer can't delete another customers profile
  • A customer can't view another customers profile
  • A customer can do a lot of other things
  • An admin can create an admin
  • An admin can view any profile
  • An admin can view transfers between any accounts
  • An admin can suspend any account
  • There is a sufficiently detailed audit trail
  • Transfer is allowable under federal law limiting the number of such transactions per month

Not the answer you're looking for? Browse other questions tagged or ask your own question.