Content Copyright © 2023 Bloor. All Rights Reserved.
Also posted on: Bloor blogs
Robust testing is essential for creating software that reliably does what it’s intended to do. This is important across every industry, but particularly so in finance: the highly sensitive and tightly regulated nature of the data and processes involved mean that the standards for dependability and trustworthiness are sky-high. This makes efficient and consistent testing incredibly important for updating your financial software in a timely, trustworthy manner.
Unfortunately, this is something the finance world struggles with. The justified need to ensure that your systems do what they are supposed to do with a certainty that other fields rarely concern themselves with often leads financial organisations to be slow to adopt new software and to update the software they already have. Similarly, software providers for financial institutions have to be very careful and methodical with new releases and products in order to ensure they do not breach the trust placed in them by their customers.
As a result, banks and other financial organisations are often tied to aging legacy systems and applications because they do not feel confident moving away from them. They may find it difficult to release critical updates in a timely manner, and they have little hope of keeping up with technology trends in a broader, cross-industry context. On the latter point, it’s worth noting that most, if not all, bank customers are familiar with non-banking apps and other technology, and their expectations for things like performance and ease of use will be shaped accordingly. We are all used to speedy, responsive apps, and the fact that banking apps need to be that much more secure doesn’t exempt them from this expectation. The fact is that if your applications are slow or clunky, they just won’t get used (or, at best, they’ll be used grudgingly – hardly a win for user satisfaction, whether that user is a customer or an employee).
This is all compounded by the unfortunate prevalence of manual testing, which is infamously slow, prone to errors, and some combination of poorly covering and hideously expensive (usually both). This is bad enough in most industries, but for finance in particular these inadequacies make the problems discussed above even more acute. For instance, before deploying any given software update you’ll want to thoroughly test it to make sure it works as intended and that it complies with all the relevant requirements. But this requires a lot of tests, and every manual test you run is a non-negligible expenditure of time and money. Plus, due to the human element, manual tests are highly fallible, so you may also need to run your battery of tests multiple times just in case one of your testers made a mistake. This all adds up to a long and expensive testing process – and you have to go through it every time you want to release a software update, let alone an entirely new piece of software.
Automated testing, by comparison, is much faster, more consistent, and ultimately less expensive (though its upfront costs can be greater). Writing a suite of automated tests can admittedly be a bit of a hurdle – although we’ll discuss one way of avoiding that hurdle later – but after that there is, frankly, no contest. Moreover, having an automated test suite ready to go can be utterly transformative when it comes to deploying new software, because it can provide relatively immediate assurance that your system will still work correctly after the update (or, alternatively, similarly speedy warnings that it won’t – either way, you save a lot of time). This, in turn, bolsters trust in software updates and can allow you to apply them far more frequently. In addition, automation can be leveraged after test execution to make it easier to update your system in the wake of failing tests. For example, by automatically clustering together tests that failed at the same point, or assigning failing tests to established system defects.
There is also another side to this. We have been speaking a lot about the speed at which you can test, and thus the speed you can meaningfully develop and update your applications. What we haven’t covered, at least until now, is the equally (if not more) important need to get your tests right in the first place. This is something that many organisations struggle with, and is true whether you’re using automated or manual tests. It is relevant across all industries, but once again it is particularly pertinent in finance because of the heightened standards we’ve already mentioned. Basically, if you don’t get your tests right – if you’re not testing for the right things – it doesn’t matter how many you write or how fast you can run them, because you still won’t know whether your applications actually do what they’re supposed to. This problem is most readily addressed by effective requirements management, enabling you to accurately capture and define what the requirements for each of your applications are and thus what you should be testing for.
Therefore, a good test automation tool will either provide this requirements management functionality itself or at the least integrate with something which does. In either case, what you are looking for is the ability to link test cases to your requirements, in order to ensure each requirement is being tested, each test case has a defined purpose, and each test case is testing for its assigned requirement as it has been defined. Advancing on this capability, some tools will also let you generate test cases (and possibly related assets) directly from your requirements, often in an optimised fashion that maximises coverage while minimising the number of test cases. This obviously speeds things up in terms of creating and executing your test suite, and it ensures that your tests and requirements match on a 1-to-1 basis. It also makes test maintenance much easier, as you can simply update your requirements then regenerate your tests (or, even better, just the tests that were impacted by the update).
To sum up, manual tests are too slow if you want to test at anywhere near the speed of modern development, on top of being generally unreliable and cost-inefficient. Replacing them with automated tests is practically always a good idea. On top of that, capturing your requirements and using them as part of your tests is essential for creating tests that reliably do their job of ensuring your systems work the way they’re supposed to. These assessments apply to practically every industry, and that certainly includes finance.