Before you answer, consider one community bank’s experience
By Lauren Bielski, a freelance writer based in New York City,
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
Lauren was technology editor of ABA Banking Journal for ten years.
Here’s why you might say yes (or no), and what it takes
Tim Lockwood is a CIO, who used to be a CFO, who’s attitude is always CID when it comes to beta testing software. If you’re not a text maven, CID is brief speak for “consider it done.” And it’s that can-do attitude that makes testing software a win-win for Grand Rapids, Mich.-based United Bank of Michigan and Fiserv, its primary vendor.
“I’ve always liked technology,” says the chief information officer. As proof of this, Lockwood points out that he was a very early Mac user, back when the units were tiny, squat, off-white boxes that resembled a child’s toy. Meanwhile, at the office, even as “a numbers guy,” Lockwood kept a steady stream of new software coming into the fold during the rise of client server—and beyond.
“When I was running the accounting department, I would often bring in new software early, so that we could automate some aspect of the account collection process,” he says. At a time when his peers may have been afraid to upset the mainframe apple cart, Lockwood tended to zero in on a new software’s upside potential.
Bring the story to the present tense, and this same inquisitiveness has led the UBM technologist through several Fiserv beta tests (the term used for placing new or revised technology products with actual users in normal operating conditions prior to official release).
Erik Wichita, senior vice-president and chief production officer for Fiserv’s Premier product line, agrees that Lockwood likes software. “He’s a conscientious, detailed-oriented guy.” Wichita says that in his numerous dealings with the CIO and the bank, which runs Fiserv wares in its own data center, beta testing is so organized that it is nearly down to, well, scientific method.
In 2006, the $425 million-assets bank hosted a test (which included NCR) during the phase-in of then emerging, no-envelope ATM devices. In 2007, UBM tested Fiserv’s mobile banking capability, working through the refinement of the interface. In both cases, the bank took early adoption of ATM and mobile banking service throughout its network of 11 branches.
In mid-October, UBM was hosting the test of a new ACH product, known during this phase as “ACH Manager for Premier.” This product is slated to meet new compliance requirements for Inter-national ACH Transactions (IAT), which address, among other things, the latest OFAC (Office of Foreign Assets Control) rules and vetting of inbound international debits.
Wichita, who is involved in the current ACH beta, says his banker beta testers are the kind of technophiles who see new systems and tools as a way to enhance their operations—that is, the software im-proves business process and yields strategic advantage.
In the case of United Bank of Michigan, the drive is always there, as Lockwood puts it, to make sure that “a comparatively little community bank keeps up with the big guys.”
“UBM is representative of about 20% of our clients—the ones who are motivated and who push us to do faster up-grades,” says Wichita.
“Waterfalls” and other details
When it comes to understanding how beta testing works, lifting the veil isn’t easy. Quality assurance and the subset of code testing tend to be low profile—even secretive—sides of the business, where third-parties are often shunned in order to keep R&D secrets untold and quality truly assured, not merely politely promised. Software testing typically occurs throughout the lifecycle of software, as it “grows up” from alpha to beta and throughout the client-facing phase of debugging.
Jeff Rogler, director of Quality Assurance & Documentation at Jack Henry & Associates, pointed out that the “agile” method, used at Jack Henry for enhancements that occur throughout the year apart from major annual upgrades, essentially brings together small groups of coders and product specialists to handle incremental aspects of the code testing under a short, tight timeline—no longer than a month.
“It’s not any less thorough than the traditional ‘waterfalls method’,” Rogler explains. “But the testing process is organized and run differently and tends to work best when you are adding functionality on top of previously tested code.” When it comes to working with clients, Jack Henry chooses a mix of tech-forward banks as well as banks that tend to have “both the core and many peripheral front office capabilities so that we can see how any new capability affects a bank’s entire suite of services.”
How beta tests roll
Wichita explained the ins and outs of the beta test as done by Fiserv. The vendor follows the more formal “waterfalls” method—sequential in nature—for annual product releases. Then, it transitions to testing with the “agile method,” described by Jack Henry’s Rogler.
Fiserv has standardized criteria for customer beta testers, which includes running a data center and having a flexible platform that can support different types of hardware and software. Typically, it prefers that a given company have multiple lines of business. (In the case of UBM, insurance services are offered as well as mortgage origination, and trust services.)
Furthermore, says Wichita, clients need to understand that beta testing, while designed these days to be minimally disruptive (test software runs on a parallel, back-up environment at Lock-wood’s shop), still requires a time commitment. “Setting expectations is very important,” says Wichita. Fiserv typically installs the software remotely, although some projects require onsite installation. Once installed, actual business users work with the application, the way it is meant to be used daily, in production. They keep track of their issues and stay in contact with onsite Fiserv testers.
All of this work on quality assurance, first at the vendor, then at the client facility, is conducted so that the software meets agreed-upon performance standards in addition to the obvious task of removing bugs. Depending on the scope of automation involved, the client phase of the test can last a few weeks, or a month, or longer.
What works—and doesn’t
What makes testing viable for a vendor? Having a good relationship with the client and an understanding of its business objectives is important, because, as Wichita emphasized, design enhancements resulting from beta outcomes are a benefit for vendor, beta user, and, down the road, other users.
What makes testing feasible for the client? Good project management skills can help. Having staff experienced with technology, even if not deep programming experience, is also a plus. Certainly what doesn’t work is a highly risk-averse mindset or working in a company that is so lean in staff and so time squeezed that staffers absolutely cannot clock the hours it takes to supervise installation and usability testing.
“Tim is the ideal beta tester,” says Wichita. “He understands the business objectives of an application, and he understands how to present to management.” BJ
The electronic version of this article available at: http://www.nxtbook.com/nxtbooks/sb/ababj1109/index.php?startid=28
Trackback(0)
|
TrackBack URI for this entry
Subscribe to this comment's feed
