2019 is a landmark year for the mobile industry: the introduction of foldable smartphones by firms including Huawei, LG and Samsung is one of the most significant developments that market sector has seen for years. As well as presenting design challenges
for device manufacturers, it also means that any app running on foldable phones will need to support many more permutations than ever before: at least two different screen resolutions (folded and unloaded, and many more if factoring in multi-window and multi-resume
Foldables add to the existing challenge of supporting apps on large numbers of different devices, across models, operating systems and manufacturers. According to Mercator’s Customer Monitor Survey in 2018, half of all consumers with financial accounts had
used a mobile banking app within the previous year, and this number is likely to grow. Plus, the imminent split of iOS 13 and iPad OS 13 operating systems will make the situation even more complicated.
So, making sure that app performance across all those end points is up-to-date and secure is an essential to the customer experience. Part of that is ensuring thorough and relevant testing of apps when software is being developed or updated. While it is
impossible to pinpoint an accurate figure, it is well known within the software development community that most future vulnerabilities stem from the creation of software.
This is why some of the best brains in the software business are increasingly focused on the need for ensuring better code quality from the get-go, across tools and processes. One of the areas they have put under the spotlight is testing, which in the financial
services world, can include: authentication transactions, location (for instance to find the nearest ATM), cheque deposit and dozens more. Across the world, software development teams are taking a new look at how they are testing financial apps, to make sure
tests are relevant and accurate, but do not slow down time-to-market.
This has led to a trend known as continuous testing, which involves executing automated tests throughout the software delivery pipeline, to get intelligent feedback on the associated business risks fast. Continuous testing it is about what to test, rather
than how much to test: the aim is not to test everything, but to test priority scenarios. Test coverage is essential, but 100 per cent is not viable (at least, not right now).
More important than coverage is automation. Even in relatively mature organisations, only around 50-60 per cent of tests are automated, meaning that a large percentage are still being carried out manually, which is not only time-consuming, but introduces
the risk of human error. Again, 100 per cent is not yet achievable, but at least 85 per cent of tests can be automated, using existing tools and techniques.
While automating as much as possible is the goal, it is best to start small and then scale the automated test foundation when it is proven to work well, with consistent results. Setting measurable objectives is important, not just to ensure quality testing
now, but also for future improvements. Metrics might include: the time a test takes (more than three minutes is not good); the most bug-ridden platforms; when in the development lifecycle are bugs typically being found; when best to carry out regression testing
(this is testing to see whether a recent change has affected existing features).
Another aspect of testing that is changing fast is who is responsible for carrying out tests, far beyond traditional QA managers or dedicated test engineers. First, there are software developers, who traditionally have only been involved in unit tests.
Often referred to ‘Shift Left’, the idea is that if they can take on more testing tasks, this uncovers problems and delivers valuable feedback earlier, reducing the load on testing later. However, while highly technical, software developers are not trained
to carry out complex tests, plus they are busy people under a lot of pressure: asking them to take on yet another task is not going to be popular.
The answer is to give them the tools and techniques so that testing happens background mode. For instance, static code analysis tools constantly and thoroughly inspect every single line of code in background mode and deliver thousands of diagnostics right
at the point of development. Any issues – whether deviation from a coding standard, excess complexity, or a hard-to-spot dataflow bug – are detected early, rather than at the more traditional stages of testing carried out by QA engineers at a later stage.
Static code analyzers also help ensure adherence to industry standards and compliance requirements, as well as helping prevent malicious code, which can lead to security problems down the line.
At the other end of the scale are business testers, who bring value because they are closest to the customer. Like developers, they typically have limited or no experience in app testing. This has led to the recent introduction of what is known as ‘codeless
testing’, which introduces AI and machine learning and introduces testing to a wider community.
Beyond these approaches, there is a general consensus in the software industry that there needs to be greater overall transparency and traceability of all the changes and digital assets involved in any project involvement software. This is partly driven
by market drivers such as compliance, but also to support an overall move to a more collaborative approach to software development (in order to support faster time-to-market of products that meet actual user requirements), well as to help overcome the roadblocks
that the sheer scale and complexity of modern software development projects can bring.
Finding ways to keep software development projects on track and at pace, against the need for software quality, security and compliance, is going to be the challenge for years to come. Smarter testing of financial apps and inspection of the software development
process at every stage is an important and growing part of addressing that challenge.