Getting past square one: How to apply DevOps to ATM testing

Source – atmmarketplace.com

DevOps is one of those au courant  business terms that everyone knows, but almost no one can actually define.

At the most basic level, it’s a process that brings testing into the software development process, rather than leaving it until the end of the cycle when the operations team takes over.

As with most business processes, the precise definition varies, depending on the people and products involved.

But in almost all applications, the end goal of DevOps is the creation of a culture and environment where software can be built, tested and released with greater speed, frequency and reliability than in a standard setup.

And that’s what makes a DevOps-style approach potentially very useful to ATM integration projects, where testing is crucial, complex and time-consuming — and where go-to-market timelines are often  unforgiving.

A June 8 webinar hosted by ATM Marketplace and sponsored by FIS showed how a collaborative approach by development and implementation teams can enable greater agility and differentiation for ATM networks.

In the one-hour session, FIS technical solutions consultant Christopher Milne discussed how continuous testing can help a financial institution (or large IAD) to reduce costs, save time and deliver an effective ATM software implementation.

As Milne explained, most ATM deployers won’t be developing a lot of the ATM stack, but rather, will be integrating new software with existing systems.

In this scenario, where software testing is often out of scope, the focus is shifted to integration testing and real-world user acceptance testing — i.e., ensuring that the software can perform required tasks in real-world scenarios and according to a particular set of specifications.

In this testing scenario, Milne said, the discovery of QA issues typically signals the need to return to square one with an implementation, which can result in delayed deployments and significant added cost.

“One of the problems in [a] traditional waterfall-type model is that the later on that we identify an issue, the longer it will take to fix that issue,” Milne said. “So let’s say we get to the UAT stage, we identify a critical problem — something very significant — we have to go all the way back to the coding phase and that might result in a nine-week delay, whereas if that issue had been found at an earlier stage it might have only been a one-week delay.”

At this point, problems begin to cascade: Delays affect other project plans; business teams get annoyed with technology teams; and the deployer’s brand image suffers if the organization ends up being left behind by the competition.

When DevOps meets ATM software integration, several benefits can be realized, Milne said. Deployers can:

• apply an agile approach to nondevelopment teams, borrowing proven ideas from software engineering and extending them to all teams involved in the chain, from code change through production deployment;
• minimize (or eliminate) manual processes by introducing automation to ensure a smooth pipeline from change through release;
• enable quicker feedback from the production teams to the develoment teams; and
• avoid “waterfall” planning.

“We want to ensure that the testing is not left until the end,” Milne said. “So it’s not treated just as a roadblock to release, but it becomes an integral part of our development process. One of the nice things that DevOps can also bring us is that development teams can receive much quicker feedback from the testing teams.

“[Currently] it might take two months or more for feedback to go back to the development teams. But in the agile world, the development teams build it, the testing teams test it super-fast and send that feedback to the development team. So ultimately, what we’re aiming for is that every time we make a change in the system we will be able to test that immediately.”

Milne also outlined steps to help ATM teams begin the process of implementing a best-of-breed environment. In the second half of the webinar, he discussed:

• how to identify pain points to be addressed by a DevOps model;
• how to introduce changes associated with adopting this model; and
• how to achieve executive buy-in.