| By Salman Akhtar | Article Rating: |
|
| October 19, 2006 12:00 PM EDT | Reads: |
12,196 |
ChoicePay has embarked on a strategic Web Services-based SOA initiative as part of its ongoing effort to improve customer and partner service. To meet its service improvement objectives, ChoicePay builds reliable and robust Web Services. It continues to enhance its service objectives without compromising overall quality through short, iterative, and demanding Web Services testing cycles.
Background
ChoicePay handles electronic bill payments for some of America's largest companies. Starting operations in 1996, it was a pioneer in the Electronic Bill Presentment and Payment (EBPP) industry and is recognized today as providing one of the most comprehensive suites of payment channels and options in its class.
ChoicePay's adoption of Service Oriented Architecture (SOA) stems from its continuous effort to improve service for its clients. One of the many SOA-based Web Services launched by ChoicePay enables centralized account number validation across all of its bill payment clients, encapsulating hundreds of masks, algorithms, and rules intelligently. As with other systems it has developed, this Web Service went through a meticulous design and implementation process. The intended goal was to provide a service that would cause minimal friction when integrated into a client's IT infrastructure. To reach this goal, the developers had to design a flexible service that would be readily consumed by multiple companies with diverse hardware and software platforms, operating systems, and programming languages. The SOA developers also had to ensure that the services were robust and reliable, which meant that the QA team had to ensure that all operations exposed by the service were thoroughly tested with a large set of data permutations. And for ChoicePay's Web Service, these rigorous and broad testing requirements had to be addressed in a span of only a month.
How ChoicePay Did It
"Testing a new function based on Web Services with global business visibility and produced on a tight schedule,posed a twin challenge for us," ChoicePay CTO Keith Fulton explains. "Throwing more bodies at the problem wasn't a viable solution. Our implementation required intelligent tools and techniques."
When Fulton initiated the SOA testing plan with ChoicePay's software QA team, he first identified the key objectives in order to roll out the service:
- Verify correctness and an exact one-for-one match with the functionality the service was replacing and centralizing, which involved testing several thousand business cases and validating the results
- Boundary conditions were tested to ensure the robustness of the Web Service
- Each operation exposed by the service had to meet specific performance metrics
- Ensure that the service met interoperability criteria since it was to be consumed by multiple companies
The recognition of these objectives introduced several issues:
- All of the objectives had to be met with limited human resources
- Creating repeatable baseline tests was required so iterative regression testing could be done
- The bug reports that were generated had to be precise and easily understood to ensure that developers could create quick fixes to make the project timeline as short as possible
The initial task was to select the right testing technology to quickly meet the objectives set by Fulton and overcome any hindrances. This included rapid deployment and a limited time for testers to come up to speed with the new product. The criteria to select the right testing technology was based on it meeting current testing objectives, being easy to use, cost-effective, and extensible for future testing scenarios. From an extensibility perspective, ChoicePay wanted to select a testing tool that would fulfill the following core functional requirements: (see Table 1
The goal behind these requirements was to find a unified SOA testing technology that would be reusable across multiple IT groups during pre-deployment and post-deployment. Also, given the tight testing schedule, it was important for ChoicePay to have an easy-to-use technology that didn't require a significant time investment for training. The testing team didn't have time for boot camp-type training.
After evaluating SOA testing technologies from several companies, ChoicePay selected Crosscheck Networks SOAPSonar Enterprise. ChoicePay was most impressed by the ease-of-use and rich functionality that not only addressed ChoicePay's stringent testing criteria, but also gave the team immediate productivity improvements . It took less than an hour for the ChoicePay testing team to become effective using the product.
Besides the ease of use of SOAPSonar, the support team at Crosscheck Networks was responsive. Each issue raised by testers was immediately discussed and alternatives given without impacting the project timeline. This allowed full and complete testing during a short time frame for the implementation. "We rely on agile competitive partners in technology and Crosscheck Networks proved to be exceptional," Fulton said.
As the testing plan was taking shape, ChoicePay continued developing effective techniques to maximize their utilization of SOAPSonar. The first technique focused on test-case usability. Borrowing from SOA's emphasis on reuse, ChoicePay's QA team created a set of test cases that could be reused across multiple SOA testing functions such as functional regression, performance, and interoperability.
The second technique adopted by ChoicePay was to leverage external data sources to dynamically parameterize SOAP requests as well as expected SOAP-response success criteria. This technique enabled the QA team to conduct full regression tests across thousands of test cases. Figure 1 illustrates the basic setup and highlights different components that played a role during rollout.
In Figure 1, SOAPSonar enabled the testing team to create coarse-grained and fine-grained filters to verify the integrity of SOAP responses from the target Web Service. The team was able to create filters based on both HTTP response codes and specific XML elements within SOAP responses. The ability to create fine-grained filters enabled the testing team to quickly identify successful and erroneous responses. Sorting data issues from application issues was simplified by using these filters. Rich reporting also played a key role in facilitating rapid bug fixes by development. Without accurate reporting, the team wouldn't have been able to convey the bugs to the development team and identify whether the issue was code-related or database-specific.
Next Steps
After its initial success, ChoicePay will continue performing real-time integration with clients where critical business processes will be interdependent. "We will use SOAPSonar not only internally, but also to certify our clients' Web Services on a daily basis to ensure there aren't changes or upgrades on their side that impact our ability to do business," explains Sandee Wagner, QA lead at ChoicePay. The plan here is to consume multiple Web Service Definition Language (WSDL) files into SOAPSonar and schedule a test on a daily basis where multiple test cases would be run against remote client Web Services, and reports would be compared from a previous day's run. Figure 2 illustrates the technique to test the customer's Web Services.
Summary
After successfully implementing the test plan, ChoicePay's QA team was able to achieve the project's goals and provide confidence that the Web Services were adhering to functional, performance, interoperability, and security requirements.
Fulton is confident they have gained considerable experience in the last few weeks with timely Web Services-based rollouts, saying, "Our experience with SOAPSonar has given us the ability to provide best-in-class reliability in highly complex, real-time distributed systems across multiple enterprises." Some of the valuable lessons learned during ChoicePay's development and release exercise include:
- Minimizing the impact of Web Service complexities through the effective use of good testing tools
- Developing test cases that are readily extensible through the use of parameters and external data sources
- Reusing key validation criteria iteratively through a project's lifecycle
- Create ongoing controls to monitor live Web Services where dependencies exist
Published October 19, 2006 Reads 12,196
Copyright © 2006 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Salman Akhtar
Salman Akhtar is the CEO and Co-Founder of Techlogix and has over 15 years of industry experience. Salman holds two degrees in Electrical Engineering from MIT.
- Big Data in Telecom: The Need for Analytics
- Patterns for Building High Performance Applications
- Microsoft Tries Hadoop on Azure
- Amazon to Fix Some Kindle Fire Problems
- What Motivates Open Standards in the Cloud?
- What to Expect in 2012: Cloud Computing and Open Source Software
- Will PaaS Finally Bring Open Source Love to the Enterprise?
- Ten Hot Trends in Cloud Data for 2012
- Oracle Disaster Recovery Site Hosted by Amazon Cloud
- Cross-Platform Mobile Website Development – a Tool Comparison
- Three Buzzwords That Every CIO Hears but One They Should Listen To
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- The Future of Cloud Computing: Industry Predictions for 2012
- Make Customer On-Boarding Easy as Paint-by-Numbers for Cloud Services
- Gartner Hype Cycle for Emerging Technologies 2011
- Book Excerpt: Introducing HTML5
- Adobe Sends Flex to the Apache Foundation
- Big Data in Telecom: The Need for Analytics
- Book Excerpt: Java Application Profiling Tips and Tricks
- i-Technology in 2012: Five Industry Predictions
- Patterns for Building High Performance Applications
- Microsoft Tries Hadoop on Azure
- The Next Web Architecture
- Cloud Computing: A Comparison of Computing Models
- The i-Technology Right Stuff
- The Top 150 Players in Cloud Computing
- Who Are The All-Time Heroes of i-Technology?
- Where Are RIA Technologies Headed in 2008?
- Get the Message
- ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked
- i-Technology Viewpoint: Is Web 2.0 the Global SOA?
- i-Technology Viewpoint: Thinking Outside the VC Box
- i-Technology Viewpoint: When to Leave Your First IT Job
- SOA Web Services Edge Conference Coverage on SYS-CON.TV
- SYS-CON.TV's "SOA Web Services" and "Enterprise Open Source" Programs To Air in December
- Five Reasons Why Web 2.0 Matters

















