It’s almost a parallel universe. Although part of a global organization with vast reach and huge responsibilities, Access Worldpay remains a small, autonomous unit with the freedom to choose its own working principles and methods. Not only can it adopt best practices, but it can also hack these as necessary to meet its needs. Co-lead Build Chapter, Pat Bateman explains how his team’s approach to QA demonstrates its independent, entrepreneurial spirit.

The starting point, he says, are the objectives. Access Worldpay is expected to turn work around fast and to a consistently high standard. “Predictability is one of the big things here. We want to get stuff out of the door really quickly and if there’s no predictability, then the business has a difficult time working with a customer.”

Goodbye Waterfall

Such imperatives immediately made the team determined to streamline its working processes. Quality assurance (QA) was a prime candidate for reform. Standard practice separated the QA function from software development. “They were almost two different organizations,” says Pat. “Software developers would write the code; when it was finished, they’d give the application to the test department for validation.”

This approach made the interplay between QA and development slow and inflexible. The long feedback cycles in the Waterfall approach to software development also made it expensive. “You’d have these massive cycles to find out something was wrong and the expense of going back and fixing the issue was immense,” Pat says. “And often what you thought you were building, in terms of set requirements, had changed.”

Improving Agile

The shorter cycles within the Agile approach helped a little, but not enough, so the team explored further refinements. “Even in Agile, the QA function remained similar to the old methodology of ‘test after’,” says Pat. “What we’ve discovered is that you can make more change the earlier in the product’s life-cycle you go.”

This is ‘shift-left’: moving the quality assurance to the left – to the start of the cycle. It means that QAs can work alongside the product owner and the developer to help ensure that the requirement is correct and agree on the acceptance criteria. “This makes our whole life-cycle more efficient because you’ve done much more detection of fault or quality at the beginning of the requirement description,” says Pat. “So by the time the developer starts coding, they’re going to find fewer problems with the requirement.”

Expanding the role

The QA function also extends to exploratory testing. “QAs come up with extra hypotheses, also at the beginning, thinking about the other scenarios we haven’t documented,” says Pat. “They’ll ask ‘does it work in this situation?’ and they may find some edge cases we hadn’t thought about, so they’re coming up with some requirements we’d missed.”

And, name aside, shift-left does not confine QAs to the start of the cycle. They still perform their traditional role at the other end, confirming that the software engineers have met the requirement and fulfilled the acceptance criteria. In practice, therefore, QAs are now available throughout the cycle, helping software engineers as needed to ensure that they are interpreting requirements and acceptance criteria correctly. “The QA becomes a more important person in the delivery squad,” says Pat: “They’re constantly being used.”

Widening the search

Although shift-left has improved the team’s productivity, the shake-up it involves can make recruitment somewhat tricky. For example, software developers are now expected to automate all their tests, whereas beforehand they shared that responsibility. And Pat recognizes that traditional QAs find shift-left to be “a difficult transition.” He continues: “We are essentially asking them to change their job – to move much more to a product view of the world. It’s very difficult to find people who understand it thoroughly.”

To mitigate this challenge, new recruits receive “lots of support on the job,” he says. Access Worldpay bring in QAs with shift-left experience to help new colleagues at the initial, refinement stage – “they help them go through exemplar requirements and acceptance criteria, and we iterate this to keep helping them improve.” QAs and product owners also have a two-day workshop, where external experts go through the whole process and teach them how to find out whether what requirements are viable.

“A bigger impact”

Pat is convinced that this extra effort is very worthwhile, not least for QAs themselves. “Traditionally, the QA function has been at the wrong end of the process,” he says. “You can feel like you’re an afterthought, pushed into very tight timelines because earlier parts of the process have run over, so you’re just sat there, checking stuff and filing bugs without any feel of the process.” By contrast, he says, shift-left “places you at the front, with a bigger impact on the product definition; it makes you one of the most crucial people within the product you’re trying to deliver. For QAs right now, this is an exciting time.”