McKesson harnesses HP's SOA for quality assurance

Medical software developer uses Web services to answer the call to do more with less

"Our philosophy is that we are the best at what we do," says Jordan Gottlieb, senior quality control automation engineer and project lead at health care software giant McKesson Corp. "We have spent the last two and a half years moving from a manual to an automated environment. Over that time, we refined our processes and have a process document for everything we do with the software product life cycle and testing."

One major goal of this effort is to work as closely as possible with product development to start testing as early as possible to do a thorough job of testing on tight schedules. Because McKesson operates exclusively in the medical industry, where software quality can literally be a matter of life or death in extreme cases, McKesson can't afford to send out buggy code. Version 1.0 of its products has to work.

A year ago, in the midst of this testing process, Gottlieb was at Mercury World, the HP Software Universe conference. "There was a big [service-oriented architecture] announcement there, and I picked up on it," he says. "I came back and started thinking about how we could make Web services a more integral part of our software development life cycle."

Integrated with development

McKesson had Hewlett-Packard Co. come in to provide mentoring and training, "which went very well." The group did its own research and realized that it could use the HP tools for both functional and service testing, and it developed a methodology for early intervention in the software development process. The huge advantage this gives McKesson is the ability to fully integrate quality assurance (QA) with development instead of waiting for a finished version to do rounds of regression testing, bug fixes and retesting.

McKesson can test modules of new application versions before other pieces are finished. "We can start building our service tests long before code freeze and use the emulator in the HP SOA service test to get far into the process," Gottlieb says. "We can accommodate changes and send issues back for resolution long before code freeze."

This has turned QA and development into an iterative process, something impossible without SOA-based testing. The earlier problems are discovered, the easier it is to fix them. This makes the development process faster and less expensive while making the old adage about building quality in from the beginning rather than trying to add it on at the end into a reality built into the development cycle.

For instance, "we can test a business process using an input screen even if the results screen isn't there yet," Gottlieb says. "We can test an application before the user interface is written." Because they have the full development documentation to work from, they can fill in missing pieces using the emulator in the HP tool set to test complete processes even when parts of the code are missing. "So by the time we get to feature complete, we have fewer defects, and the final testing goes much faster."

Not only does this allow QA to identify problems much earlier in the process, decreasing the time and cost of fixing them, it also supports more thorough testing than was available previously. For instance, he says, "some of our customers want to use their own browser-based user interfaces rather than ours. It also makes interoperability testing very easy."

Homegrown interfaces

Some users want to develop their own enterprise-standard interfaces to McKesson's products rather than using the user interface the vendor provides. "The HP SOA tools let us test the applications without the user interface, so we know that will work." But because some users may develop their Web services in Java and others in .Net, QA must ensure that all the modules in the applications are compatible with both environments.

Fortunately, Gottlieb says, adding compatibility testing using the HP SOA tool set is a matter of writing a few lines of code. "So the effort is slight, and the benefit huge. We can test for interoperability early in the development process and send any modules that are not interoperable back for corrections before the interfaces that would be affected by the changes are developed, saving a lot of work." And the result is software that can integrate easily with the customer's SOA environment.

Also, the SOA-based tests can be easily modified to meet different needs. "We can replicate a functional service test, change its data, take out the check points and verify response times, and create performance service tests. So we have effectively doubled our test assets with much less work than building the tests from scratch," Gottlieb says.

This iterative testing process requires close communications with the development teams. They need to know what QA is testing and what tests it plans to run, and QA, of course, needs to know when modules are ready to be tested. Therefore, the QA group has developed its lines of communication with other groups, particularly product development, to the point that Gottlieb says when he talks to colleagues in other companies he realizes how much stronger his groups lines of communications are compared to industry norms.

The result, says Gottlieb, is a higher quality, more adaptable product set and a more aggressive update schedule. This equates to better, more dependable code delivered on time, at lower cost and at less effort -- the ideal response to the call to do more with less.

Bert Latamore is a journalist with 10 years' experience in daily newspapers and 25 in the computer industry. He has written for several computer industry and consumer publications. He lives in Linden, Va., with his wife, two parrots and a cat.

Copyright © 2007 IDG Communications, Inc.

  
Shop Tech Products at Amazon