It is even interesting to see several banks extending solutions on wearables such as smart watches and also providing a LITE version to enable access in low bandwidth areas. Smart phones are omnipresent in the country today – with people across all walks of life leveraging them for their day to day activities, it is of complete business and user relevance to have mobile banking applications that offer instant solutions at the touch of a screen.
While the opportunities are huge, the challenges are equally a large set too. Banking applications are next only to health care applications where tolerance for errors is almost zero. Imagine your funds being transferred to an incorrect account, someone gaining access to your account – any error for that matter, both on functional and non-functional sides, is a huge cause for concern, making quality a very stringent activity. That said, banking sector is also facing a lot of competition from other players, has a lot of expectations from end users, making Agility in delivery a no brainer. So, what really is different in testing banking applications to enable superlative quality and yet be able to churn fast releases? Is there a secret recipe that dishes it all, with ease?
As developed US may be as a nation, especially on the technology front, studies show that even banking apps there have a lot of issues, especially around security. Secure banking apps is becoming a rare phenomenon. Right from insecure data storage to communications to cryptography to sharing data with advertisers, the list goes on both across iOS and Android. This is just one side of the story from an important element of mobile banking app security/privacy; other areas such as functionality, performance, usability and accessibility have their own woes too.
In our experience, the one key to solid quality engineering especially in a domain such as banking, is to have a very tight knit quality team that works extremely hand in glove with the rest of the team including business from the start. Non-functional test areas cannot work horizontally – they will have to be built into the teams. Also, quality has to be reverse engineered; in the sense most of the quality heavy lifting needs to be done by the testers, while core execution / implementation should be done even at the design and development stages. Upfront quality is the only way forward, for this large and significant domain, failing which, teams will get caught with several issues later in the development cycle, regressions that continue to build and add to the test debt, teams that will get burnt out handling random issues – all of which will lend to poor quality, missed deadlines, burgeoning costs, fall out in customers, legal implications amongst others. In most cases, existing banking systems themselves would be large and legacy systems would be many to work with. While that is one side of the story, the recommendation here is any new development effort, should tightly embrace quality from the start, across all attributes to ensure the right approach from that point on. This when done, quality will truly become a collective responsibility led by the testing team from the forefront.