Let’s imagine that you’re a trendy new startup. You’ve got a new widget that lots of people are downloading that helps that track their runs, or manage their time more effectively, or connect with other members of their community. Sure, there are the usual set of information security concerns, and you have plenty of functionality to build out over time, but the occasional bug or service outage isn’t going to be the end of the world. While high quality testing is still mission critical, it might not feel like a life and death situation.
For those of you dealing with BFSI software testing, the situation we described above is basically the equivalent of sitting on the beach reading a trashy paperback. In these industries in general—and financial services in particular—your software needs to integrate with incredibly complex business flows with a minuscule rate of failure. Sure, a data breach would be catastrophic, but even a few smaller bugs could have a huge impact on quality of service—which is why testing in this field often feels particularly high stakes.
If you’re feeling some of the pressure to improve test quality and coverage in financial services, you’re not alone. That’s why, today, we’re outlining the top 5 challenges testers face in this sector.
Let’s start with the most obvious one: if your software is designed to process secure transactions, security is going to be one of your biggest concerns. You’ll have to ensure that there’s no way for malicious users to gain access to data they shouldn’t have and that your transactions really are being conducted in compliance with the latest security and encryption standards for the industry. By the same token, you need to ensure that every element of your system architecture complies with both internal and external standards. This can seem daunting, and rightly so—while some security matters can be boiled down to developers adhering to certain best practices in their code, a truly thorough security verification flow for a new release might require a full-blown penetration test.
2. Database Functionality
Related to the question of who can access what data at what time (a crucial access control concern for security testers), is the question where that data resides and how it gets there, i.e. your database structure. This is another huge concern for financial services applications in particular—in part because of security concerns, and in part for obvious reasons of functionality. If a piece of information, after being recorded, doesn’t show up in the place you expect in the format you expect, it’s going to be difficult to understand it down the road, and as a result you won’t be able to successfully audit past transactions or gain any sort of understanding what’s happening within your application. Luckily, this is the type of hurdle that lends itself more easily to an end-to-end mindset. If you think of any area where a piece of data is produced as one node, and the space where that data should be retrieved as another, then you can verify from endpoint to endpoint whether or not your data is being stored and moved correctly.
Financial applications are typically integrated with a series of complex business functions. For example, personal banking activity might need to interact fairly directly with brokerage and trading applications, just as enterprise banking functionality might depend on interrelations with insurance software. Beyond that, you’ll need to ensure that each process flow meets all of the requirements set by your business for how those flows ought to be conducted. These things aren’t necessarily difficult to verify on their own, but they are difficult to verify if you don’t understand the processes with which your software is integrating. In order to avoid this fate, you need to make sure that your organization is providing accurate, thorough, and up-to-date documentation on all of its business processes. Without this, there’s essentially no way to verify that your app is following protocol.
4. Load Testing
Okay, now let’s take all of the potential use cases and concerns we’ve already outlined above, and multiply them by thousands of transactions all being performed at once. This, in a nutshell, represents the conditions that most financial services software will have to grapple with out in the world. Not only do you need to handle a huge volume of concurrent sessions, you also need to ensure that the results of those sessions are reflected in real time to prevent contradictory actions from being carried out. For instance, if a user with a joint checking account opens up a session while her partner is simultaneously withdrawing money, that withdrawal needs to be noted immediately on both the end user side and within your own database, so that the first user doesn’t accidentally overdraft because the dollar amount in her balance is wrong. For testers, this means that your use cases should include this kind of simultaneity, just as they should include, to whatever extent possible, load testing that accounts for the large number of users who will be conducting sessions at any given time.
5. Test Volume
If it sounds like these challenges are going to require testers to verify a huge number of use cases—that’s because they are. Especially as users look to access financial services for a widening number of purposes on an increasing number of devices, testers are going to have their hands full trying to achieve high levels of test coverage. When you consider that test coverage is correlated strongly with service quality, it becomes imperative that you begin to ask yourself how you’re going to meet all of the challenges we outlined above while maintaining high coverage. One potential path forward for this challenge is to transition from manual to automated testing for your service verification. Obviously, automation isn’t a panacea, but if you can move away from manual testing, you stand to position yourself to power through more test cases per day by a huge margin, all within a scalable, repeatable framework.