Mobile banking is not just a fad. By 2020, the U.S. is expected to have more than 160 million mobile banking users, and in the UK mobile banking is already overtaking internet banking in popularity. This could be attributed to a number of factors, from simple convenience to the increasing primacy of mobile phones in general—but whatever the cause, the implication for banking and financial services businesses is pretty clear: you really need a robust mobile application that your subscribers can access on the go.
Of course, building an application that meets customer needs is a little bit trickier when users’ financial assets come into play. While most apps have a little bit of wiggle room in terms of functionality (i.e. the occasional bug won’t be a big deal), any sort of issue involving private financial information could have a big impact on public perception and revenue streams. While this puts a lot of pressure on developers, it puts even more pressure on the testers whose job it is to ensure correct functioning. Of course, successful tests can be time consuming and cumbersome even under the best of conditions, and once you throw something like regression testing into the mix that problem becomes exacerbated severely. So, do testers in fintech and BFSI fields really have to run labor- and time-intensive regression tests?
Yes. Yes they do.
What Is Regression Testing?
Right off the bat, let’s clear up any confusion about what we mean by regression testing. Essentially, a regression test is performed on your entire application, network, or what-have-you following any small change to a specific part of that application or network, in order to ensure that the change hasn’t had unintended consequences elsewhere in the system. Because a lot of BFSI developers are using agile or continuous integration models, changes to a given piece of software tend to come rapidly over the course of its lifecycle—in part because the initial release usually requires at least some bug fixes. Your goal as a tester is to ensure that these bug fixes don’t interfere with the functioning of the rest of the system.
Critically, regression testing is distinct from retesting. While a developer might perform a handful of unit tests to verify that a particular bug fix seems to work, these retests need to be thought of as a distinct entity from regression tests. The crucial difference here is that regression tests need to be performed on the entire system, which essentially means a full end-to-end test every time your application is updated. Like we said above, this can and does present a hurdle for testers in terms of time management—but if a user is unable to check her balance when she wants to, or if she finds that some of her financial information has been compromised, the lost revenue from customer attrition is likely to outweigh the additional testing costs.
Incorporating Regression Tests into Your Development Flow
At this point you might be thinking: “Okay, regression tests are important, but how do I actually make them happen in a complex testing and development environment?” It’s a good question, and to some extent, the answer is going to vary company to company. For comparatively agile development cycles, you might want to stagger your regression tests so that you don’t find yourself with engineers sitting on their hands waiting for results. By the same token, if your updates are extremely regular you might be able to decouple them from your update cycle altogether and simply incorporate them into your standard testing schedule.
In any event, the important thing is to find ways to make the process more time-efficient. To that end, you might consider creating standardized workflows for regression testing that make use of reusable test cases. This might require an initial outlay of resources, but in the long run it could decrease the time it takes to get regression tests up and running. Once you have your test cases defined in a readable, repeatable way, you might also look into test automation. Because most of your test cases will be mobile-based, you may need to go beyond the typical parameters of test automation for development to incorporate technology that can actually control out-of-the-box mobile phones like the ones your users will be utilizing. This will become increasingly crucial as telecom networks get faster and acceptable latency times continue to shrink. Why? Because a simulated mobile phone might be just different enough from the real thing that it obscures a noticeable difference in latency—and thus a noticeable difference in user experience.
The Power of Automation
Above, we suggested that automation might be a potential path forward for BFSI testers. But what would test automation for this domain look like in practice? Well, let’s say you’re adding a new piece of functionality to your mobile banking suite—say, the ability to place an investment order from one’s phone. Leading up to the initial rollout, you fix a few bugs, and those fixes pass their respective unit tests and don't seem to break anything. Instead of sitting down to laboriously retest the entire system, you find the relevant test cases that have already been scripted up to verify end-to-end service, and you bundle them together into a standard regression test library.
Then, rather than powering through each test by hand, you find a test framework that can perform 24/7 regression tests on nights and weekends. These test work in the background and periodically send you reports based on their results. It’s not quite “set it and forget it,” but it’s something that can run behind the scenes while test engineers and developers focus on more obviously pressing tasks. Since these tests don’t require manual time and effort to run, your worries about time efficiency become moot. In this way, you increase the odds that your final product will continue to delight your customers over time, while keeping their financial information safe and secure.