More

    ANZ follows “shift left” strategy on Software Testing for its Payments Transformation Program

     

    ANZ Banking Group is changing its direction on a ‘shift left’ strategy for testing software produced under its payments transformation program. Within Agile, testing can be altered in any way, shift-left means testing ahead in the development cycle, while shift-right means testing code after it is in production, detecting real-world issues that initially would have been overlooked.

    The company has driven very heavily on an automation-first principle to enable them to be able to integrate into a CI/CD pipeline, and they want to reach fully automated CI/CD/CD which means having a continuous test (CT) environment and testing activities that feed into the DevOps pipeline. Their objective behind this is to make it possible to push a button and automatically deploy code and have it prepared to go; spin up a virtual environment; comprehend what’s altered from a feature, function, or line of code; extract the test cases that are aligned to that, and automatically execute them, and then determine whether they have passed or failed.

    “We’ve got Tosca which holds all our test cases, and now we’re currently deploying qTest as our conduit between the two [Tosca and Jira], 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,” he said.

    Presently the emphasis of the company is on utilizing data insights to comprehend how code defects might be enabled to pass into later stages of the development cycle before being picked up. To move to a completely automated process, banks cannot continue to rely on authorities or some other central control point to intervene, they need to be competent to move quickly to compete with a rapidly changing financial market and the emergence of new players and products from non-traditional entrants.

    “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 daily, 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,” said Kyriazis.

    Recent Articles

    spot_img

    Related Stories

    Stay on op - Ge the daily news in your inbox