Here’s an interesting question for you … if you’re a tester for a banking IT project, do you need to have banking domain knowledge?
Or would your know-how of testing techniques, and how to construct test scenarios will suffice?
I’ll be honest with you … when we deliver IT projects, one of the toughest phases is the testing phase.
In particular, that is the point when most system and software bugs appear and users go Hey, I didn’t ask for that feature or requirements.
It’s where the rubber meets the road for a software.
So any knowledge that helps the testing process will be valuable.
To me, I see BOTH domain knowledge and testing techniques as critical.
In this article, I’d like to talk specifically about banking domain knowledge for testers.
The content here will be particularly useful for you if you’re involved in testing a banking software system in any way.
However, even if you are testing an IT system in another industry (e.g. insurance or healthcare), the know-how here will also be useful.
Read on and find out more!
Testing a banking system, especially a core banking system is tough.
I mean, REALLY tough.
You need to specify thousands of test cases, covering client account opening, Know-Your-Client (KYC), deposits, loans, investments, bancassurance, payments, settlements, cards, loans and so forth.
If you don’t have banking domain knowledge, it will be VERY hard to draw up test scenarios for the banking system.
Only if you’ve done enough banking projects will you be familiar with some of the core test cases that must always be tested.
In the following sections, I’ll try to:
- Explain why banking domain knowledge for testers is important.
- Help you understand some key banking domain concepts, and
- Explore some ways banking test cases can be structured
Case Study. I remember when I first started out on my first core banking project.
I was really lost! I was just a Business Analyst (and later a Tester) in what was a team of 50 project resources.
I think I was handling the payments module, specifically for electronic fund transfers.
There was a lot of coordination between the core banking system and the Real-Time Gross Settlement (RTGS) system here in Singapore, run by the Monetary Authority of Singapore (MAS).
Those years were a struggle, because I didn’t understand how payments worked.
But working through hundreds of test cases (e.g. initiate payment, checking payment limits, reconciling fund transfers against bank accounts) helped me understand – very solidly – how banking payments worked.
So if you’re a tester, be glad you have a chance to learn all this stuff! The banking domain knowledge you get will be VERY useful indeed in future project.
Imagine that you are told to write a set of test cases for a core banking system. Specifically the client account opening module of the banking IT platform.
How would you go about doing it?
The process cannot just be: “Hmm, let’s try this and that”.
You’d need to start from a base know-how of bank accounts and how they are opened.
Now, typically, the way we get at test scenarios and test cases is to speak to the users.
The bank users (in this case the Customer Support Officers) would tell you that the client has many channels through which they enter the bank to open an account.
For example, they may come to the Branch Teller and try to open an account.
Or they may try to open an account via a mobile phone (yes, that’s possible in Singapore today).
Some others may call their Relationship Manager to open an account for them.
In coming up with test scenarios and test cases for a banking system, you REALLY need to come from a business perspective.
An understanding of all the channels, plus what checks (online and offline) need to be made before an account is opened – will be very helpful.
For example, is the client opening a Joint Account? A Single Account?
Who can sign off on the account for fund transfers? Is the person opening the account a Politically Exposed Person (PEP)?
Does he or she have a good credit record? Is he or she a bankrupt? If so, you may need to block account opening or raise red flags.
You see, banking domain knowledge for testers is so important.
It lends credibility to your work and your business users CAN TELL.
You will also be seen as an authority in the project because you know how business works.
And here’s the thing … it’s very simple, really.
Think about it from the bank’s CEO point of view.
I expect my technologists or IT guys who are implementing my core banking system to know what the banking operational processes are.
I expect them to thoroughly test the scenarios so that operations continue smooth, without being interrupted. Banking domain knowledge will help with that and more.
I also present simple frameworks to give you a broad perspective into banks' business models, customers, distribution channels and operations. Check it out here.
Banking has many variants – Retail Banking, Corporate Banking, Investment Banking, Private Banking, etc.
It is very easy to get overwhelmed by the sheer amount of knowledge you have to assimilate.
As a tester, it is useful for you to understand some key banking domain concepts, which I will introduce below.
First, the concept of banking products. What products does a bank sell?
It is important to understand this because every banking operation is set up for product fulfillment.
For example, if a Bank sells the very basic CASA or Current Account or Savings Account to clients.
Client deposit money in these accounts for a (very low) interest return.
The bank lends out the cash at higher interest to clients who want to take loans.
Banks may sell investment products like equities, bonds, funds, structured products, amongst others.
Thinking in terms of products helps you understand how a bank is structured, from the point the banking product is sold through to the point it is fulfilled.
In my consulting line of work, we call this framework an Operating Model, which is really a way to describe how a bank works and operates to fulfill its business strategy and revenue targets.
Second, we need to understand banking services. Banks offer services such as payments and remittance.
It also provides stuff like cheque books, investment advice, portfolio management – all of these tend to attract a management fee.
These service operations also form a large part of the bank’s middle and back offices and is something you, as a tester, should seek to understand too.
And if you understand how a bank fulfill’s products and services, you’ll be able to say you understand banking domain knowledge.
There are many ways to pick up banking domain knowledge – these vary from interviewing experts, to reading or taking up courses, to actually getting hands on experience in a project.
One of the best ways to pick up banking domain knowledge is to ask an expert. If you have a user you’r close to, or even a friend who works in banking – ask that person.
How a banking product or service is done, front-to-back. Within a short interview of e.g. 30 minutes, you’ll be able to glean a lot of knowledge.
I used to do this when I was starting out – I’d shadow an Operations person just to watch what he or she does every day – checking accounts, doing reconciliation – it’s amazing what you can learn from just observation alone.
The other way to pick up banking knowledge is by attending courses.
There are some good courses out there and one of the tricks I tend to use is look up accreditation from the regulators.
For example, the Monetary Authority in Singapore runs the Capital Markets and Financial Advisory Services (CMFAS) Examinations which I think is excellent for picking up some base banking or financial advisory knowledge.
If you’re trying to write test cases for a banking system (let’s assume it’s a core banking system) – there are some basic rules to follow.
Basically you don’t just jump right in and write.
First, try to think in terms of products and services. From the moment a customer walks into the bank, how does the product get processed.
Take for example, a loan.
The customer needs to fill in a loan application form, the loan officer will fill in the details into the loan origination system, the system will run some validation checks.
If ok, the system will create a loan account and print some documentation.
From there the loan will be monitored for drawdowns and principal / interest payments, etc.
In my opinion, when drawing test cases here – your know-how of testing methodology is also important.
So try to also think of user-system interactions. If the user clicks a button, what does the system do – maybe it processes something and makes a validation check.
How does the system behave if the validation is ok and not ok?
These are actually standard use case methodologies and system interactions which, as a junior Business Analyst and Tester in the past, I did day in and day out.
In conclusion, I’d say that banking domain knowledge for testers is quite critical.
Knowing how banks fulfill products and services will give you credibility and allow you to specify the correct test scenarios and test cases your end users want.
It is useful to think about how you can acquire banking domain knowledge, perhaps through expert interviews, courses or books.
Remember, however, that the best way to learn is through hard experience, so if you have any chance to join a banking project – jump at it!
Also, don’t forget about testing methodologies either.
Use and apply those skills as well, to round out the banking system testing approach.
Until next time, have a great time learning about banking and testing!
Get Your FREE Banking Domain Knowledge Cheat SheetI hope you can see the potential of accumulating Banking Domain Knowledge in your job as a Test Manager or Test Lead.
Yes, it takes hard work to gain that knowledge.
But if you take the first steps according to what I've listed above, you know ahead of time that your hard work is going to pay off.
Ready to get started? Click the link below and enter your email to get access to your free PDF Banking Domain Knowledge Cheat Sheet.