Case study: Developing Software Faster and Better with HP ALM 11

Updated: January 06, 2011

Here are some excerpts:

Eaton: In our business at McKesson, we have various groups that develop software, not only for internal use, but also external use by our customers and software that we sell. We have various groups within McKesson that use the centralized tools, and the ALM tools are pretty much their lifeblood. As they go through the process to develop the software, they rely heavily on our centralized tools to help them make better software faster.

The ALM suite that HP came out with is definitely giving us a bigger view. We've got QA managers that are in the development groups for multiple products, and as they test their software and go through that whole process, they're able to see holistically across their product lines with this.

We've set up projects with the same templates. With that, they have some cohesion and they can see how their different applications are going in an apples-to-apples comparison, instead of like the old days, when they had to manually adjust the data to try to figure out what their world was all about.

Better status

When HP came up with ALM 11, they took Quality Center and Performance Center and brought them together. That's the very first thing, because it was difficult for us and for the QA managers to see all of the testing activities. With ALM, they're able to see all of it and better gauge where they are in the process. So, they can give their management or their teams a better status of where we are in the testing process and where we are in the delivery process.

The other really cool thing that we found was the Sprinter function. We haven't used it as much within McKesson, because we have very specific testing procedures and processes. Sprinter is used more as you're doing ad hoc testing. It will record that so you can go back and repeat those.

How we see that being used is by extending that to our customers. When our customers are installing our products and are doing their exploratory testing, which is what they normally do, we can give them a mechanism to record what they are doing. Then, we can go back and repeat that. Those are a couple of pretty powerful things in the new release that we plan to leverage.

When we're meeting at various conferences and such, there's a common theme that we hear. One is workflow. That's a big piece. ALM goes a long way to be able to conquer the various workflows. Within an organization, there will be various workflows being done, but you're still able to bring up those measurements, like another point that you are bringing up, and have a fairly decent comparison.

They can find those defects earlier, verify that those are defects, and there is less of that communication disconnect between the groups.



With the various workflows in the past, there used to be a real disparate way of looking at how software is being developed. But with ALM 11, they're starting to bring that together more.

The other piece of it is the communication, and having the testers communicate directly to those development groups. There is a bit of "defect ping-pong," if you will, where QA will find a defect and development will say that it's not a defect. It will go back and forth, until they get an agreement on it.

ALM is starting to close that gap. We're able to push out the use of ALM to the development groups, and so they can see that. They use a lot of the functions within ALM 11 in their development process. So, they can find those defects earlier, verify that those are defects, and there is less of that communication disconnect between the groups.

We have several groups within our organization that use agile development practices. What we're finding is that the way they're doing work can integrate with ALM 11. The testing groups still want to have an area where they can put their test cases, do their test labs, run through their automation, and see that holistic approach, but they need it within the other agile tools that are out there.

It's integrating well with it so far, and we're finding that it lends itself to that story of how those things are being done, even in the agile development process.

Company profile

McKesson is a Fortune 15 company. It is the largest health-care services company in the U.S. We have quite a few R&D organizations and it spans across our two major divisions, McKesson Distribution and McKesson Technology solutions.

In our quality center, we have about 200 projects with a couple of thousand registered users. We're averaging probably about 500 concurrent users every minute of the day, following-the-sun, as we develop. We have development teams, not only in the U.S, but nearshore and offshore as well.

We're a fairly large organization, very mature in our development processes. In some groups, we have new development, legacy, maintenance, and the such. So, we span the gamut on all the different types of development that you could find.

That's what we strive for. In my group, we provide the centralized R&D tools. ALM 11 is just one of the various tools that we use, and we always look for tools that will fit multiple development processes.

They have to adapt to all that, and we needed to have tools that do that, and ALM 11 fits that bill.



We also make sure that it covers the various technology stacks. You could have Microsoft, Java, Flex, Google Web Toolkit, that type of thing, and they have to fit that. You also talked about maturity and the various maturity models, be it CMMI, ITIL, or when you start getting into our world, we have to take into consideration FDA.

When we look at tools, we look at those three and at deployment. Is this going to be internally used, is this going to be hosted and used through an external customer, or are we going to package this up and send it out for sale?

We need tools that span across those four different types, four different levels, that they can adapt into each one of them. If I'm a Microsoft shop that's doing Agile for an internal developed software, and I am CMMI, that's one. But, I may have a group right next door that's waterfall developing on Java and is more an ITIL based, and it gets deployed to a hosted environment.

They have to adapt to all that, and we needed to have tools that do that, and ALM 11 fits that bill.

ALM 11 had a good foundation. The test cases, the test set, the automated testing, whether functional or performance, the source of truth for that is in the ALM 11 product suite. And, it's fairly well-known and recognized throughout the company. So, that is a good point. You have to have a source of truth for certain aspects of your development cycle.

Partner tools

There are partner tools that go along with ALM 11 that help us meet various regulations. Something that we're always mindful of, as we develop software, is not only watching out for the benefit of our customers and for our shareholders, but also we understand the regulations. New ones are coming out practically every day, it seems. We try to keep that in mind, and the ALM 11 tool is able to adapt to that fairly easily.
Related Categories
Featured Research