When it comes to banking and financial services functionality, “almost” doesn’t count. From your end users’ perspective, they’re either able to complete their desired action—whether that’s checking their balance, transferring funds, or setting up automatic payments—or they’re not. They’re not going to spend a lot of time looking for workarounds, they’re simply going to register their displeasure by choosing a new app or a new service provider.
This has obvious business implications when it comes to developing applications for end users, of course, but it also has implications for testers in this field. Why? Because it’s up to them to ensure that the user’s experience meets their expectations by finding and rooting bugs and malfunctions before your software is rolled out. As more and more smartphone users install BFSI apps for easy use on the go, we’ll see more and more frequent examples of what not to do if your goal is to retain customers—and many of those instances will come down to how carefully, and how effectively, the relevant systems were verified.
This state of affairs leaves testers with an important choice: what testing method will best meet the needs of your business and its customers?
What Is End-to-end testing?
To paint with an extremely broad brush, your choice of testing methodology comes down to system testing (aka black box testing) vs. end-to-end testing. System testing is essentially means checking the functionality or non-functionality of individual elements of a software system, while end-to-end testing focuses on the flow of a given application from one endpoint (say, a user on her smartphone) to another (a bank’s internal system, for instance). Crucially, end-to-end testing ensures that your software plays nicely with the systems with which it interconnects, e.g. specific Android and iOS phones that end users will use to access services. While system testing might help you to understand the inner working of your application in theory, end-to-end tests help test functionality in practice by simulating entire end user actions.
For BFSI in particular, an end-to-end test case might look something like this:
- The user inserts her credentials to log in to the app.
- Next, the user checks her balance.
- The user transfers money from her checking account to her savings account.
- That transfer is correctly reflected on the backend database.
- The user logs out.
For each of these actions, test engineers need to scope out the possible scenarios and assign each one a desired outcome in order to flesh out the test case. For the log-in step, for instance, you’d need to verify that both that the correct credentials result in a successful log-in and that incorrect credentials lead to the correct error message, that the account is blocked after a certain number of attempts, etc. For the money transfer, you would make sure that a valid transfer request resulted in the correct amount of money being deducted from the account, and that an invalid request was, again, met with the correct error message. Once these are mapped out for every possible use case, you can begin validation with an eye towards ensuring that every user action has the correct reaction within the software. In this way, you’re able to uncover the kinds of bugs that arise when your software interacts with the software, hardware, and firmware at play in end user devices—to say nothing of actual user behavior.
Challenges in End-to-end BFSI Testing
By taking an end-to-end approach to verification for BFSI applications, you can more accurately simulate end user experience, which means that you can subsequently fix the bugs that most negatively impact those users. In a perfect world, the end result of this kind of test is reduced user attrition, which has a direct impact on your company’s bottom line. That said, there are challenges that testers will have to overcome in order to roll out this kind of test flow effectively. For instance, the sheer number of interconnected layers at play (including UX, applications, the various FW specifications of the end user devices, etc.) means that test cases can proliferate quickly—easily reaching levels that would be difficult or impossible to perform by hand in a timely and resource-efficient way.
In cases where test volume is too high for manual testers, automation typically presents itself as a potential path forward. Here, the complexity of these tests might give testers the impression that automation would be difficult to orchestrate or ineffective when deployed—but given the right conditions automation can actually be a valuable tool for grappling with that very same complexity. The trick is to make sure you’re keeping your focus on the end user and making use of real, out-of-the-box devices that an end user would utilize.
Putting Theory into Practice
If you can create a test environment in which you can automatically and remotely control the actions of non-rooted, non-jailbreaked Android and iOS phones, then you can finally begin to perform your end-to-end tests at scale. From there, it’s just a matter of breaking down each use case into a set of actions that can be performed automatically by those devices, centered on keyword-based commands that pertain to the specific uses. Again, we might see someone log in to a BFSI application, check their balance, and log back out—but without the need for any testers to manually perform the actions. As a result, the use case inflation that we were considering above is greatly mitigated by the speed at which tests can suddenly be performed.
The more people rely on their smartphones to carry out the kinds of tasks that used to require a trip to the bank, the more they’ll demand impeccable quality of service (QoS) from BFSI software and applications. If you’re able to orchestrate automated end-to-end tests on these applications, you’ll position yourself to gain a clear competitive advantage in this area.