ANZ shifts direction on software testing in payments transformation

ANZ Banking Group is pushing harder on a ‘shift left’ strategy for testing software produced under its payments transformation program.

The program’s portfolio test director Alex Kyriazis told the recent Tricentis virtual summit that his part of the bank had “pushed very heavily into a ‘shift left’ mentality”. 

Within Agile, testing can be shifted in either direction of where it would normally be run within a more traditional ‘waterfall’ approach (i.e. towards the tail end of the development cycle).

In this context, shift left means testing earlier in the development cycle, while shift right means testing code once it is in production, catching real-world problems that earlier testing may have missed.

“Over the last 12 months we’ve driven very heavily on an automation-first principle to enable us to be able to integrate into a CI/CD [continuous integration and continuous deployment] pipeline, and where we really want to get to over the next six to nine months is fully automated CI/CD/CT,” Kyriazis said.

“That means having a continuous test (CT) environment and testing activities that feed into the DevOps pipeline.

“The aim will be for us to be able to press a button and automatically deploy code, have it ready to go; spin up a virtual environment; understand what’s changed from a feature, function or line of code; extract the test cases that are aligned to that, and automatically execute them; automatically validate, and then determine whether we have a pass or fail. 

“If it’s a ‘fail’ it’ll go back to the developer and we spin everything down so we take away the wastage of the environments. 

“If it passes, we then spin up the next environment that’s more integrated and run the next suite of test cases automatically and continue on as we move towards heading into a production deployment.”

Kyriazis said that ANZ holds its 'user stories' - Agile terminology for the description of a new feature or its requirements from a customer’s point of view - in a Jira instance.

“We’ve [then] got [Tricentis] Tosca which holds all our test cases, and now we’re currently deploying [Tricentis] qTest as our conduit between the two [Tosca and Jira],” he said.

“That’ll give us traceability and enable us to start learning more about ‘if something changes what needs to execute?’ and to start capturing that data to understand it better.”

Kyriazis said there was a current emphasis within the program team on using data insights to understand how code defects might be allowed to pass into later stages of the development cycle before being picked up.

In order to move to a fully automated process, he noted the bank could not continue to rely on experts or some other central control point to intervene.

“The machine should know what needs to run, as opposed to a person,” he said.

“Unfortunately people make mistakes, so we need to get away from having a central point and experts doing this, and having the machine know what needs to run.”

More generally, Kyriazis said that banks needed to be able to move faster to compete with a rapidly changing financial market and the emergence of new players and products from non-traditional entrants.

“To compete with all the new players in the financial industry, and a lot of non-bank organisations, we need to work out how we can disrupt the way we do our work,” Kyriazis said.

“A lot of that is going to be around how fast we can deliver quality solutions into production, and therefore you need to have a shift left and a shift right mentality. 

“Shift left is building quality production solutions as fast as you can; shift right is having the capability to have a continuous testing flow that protects your production solution, so [you can] validate what’s been provided by a squad.

“I’ve got 50 squads in my space. We’re going to get a lot of change coming at different time frames, so I need to have a mechanism that allows me to validate each sprint. 

“If I can validate that on a daily basis, I give my stakeholders - being my boss and all our business internal stakeholders - the capability to then determine to deploy as fast as possible and not in a 12-week, six-month release or 12-month release.”