Wednesday, April 29, 2009

More About Performance Centers of Excellence

Earlier I wrote about the benefits of creating a performance CoE. I explained by making a move to a CoE you can increase your quality, increase your testing throughput, and decrease your overall spend. I know that this sounds too good to be true. But I'm telling you it's not. Don't just take my word on it. Theresa Lanowitz of voke, ran her own Market Snapshot on performance CoEs. Listen to her on May 19, 2009. She will go over all of her findings on CoEs. And since I'm telling you about it, the findings are good. :).


After you listen to this presentation, come back here and I'll talk about the steps you can take to begin building a CoE.



HP

voke Shares Research Findings

» ROI and performance goals with a performance testing shared service

Dear HP Valued Customer,

In today’s economic climate organizations are seeking ways to optimize resources and results. Part of the move towards optimization is the evolution and transformation of the application lifecycle, particularly the components that drive efficiency and quality.

To achieve business optimization through the application lifecycle, organizations are building centers of excellence (COE). A COE focused on performance is a strategic way to deliver customer satisfaction, high quality and resource savings.

Join Theresa Lanowitz, founder of voke Inc., as she presents the findings of a recent Market Snapshot on Performance Centers of Excellence. In this presentation, we will discuss:

Building a performance COE

Achieving performance COE ROI – qualitative and quantitative

Gaining organizational maturity through a performance COE

Realizing the benefits, results, and strategic value of a performance COE

Attendees will receive a copy of the voke Market SnapshotTM Report: Performance Center of Excellence.

Register Now »


Speakers:

Theresa Lanowitz, CEO & Founder – voke, Inc.

Priya Kothari, Product Manager, Performance Testing Solutions – HP Software + Solutions

PS: HP Software Universe 2009 registration is now open! Interested in learning the very latest about IT strategy, applications and operations? Then seize this opportunity to join us June 16-18, 2009 at The Venetian Resort Hotel Casino in Las Vegas, Nevada.

» Find out more.

voke Shares Research Findings

DATE:
Tuesday, May 19, 2009
START TIME:
10:00 am PT / 1:00 pm ET
DURATION:
60 minutes with Q&A

»

Register Now

Learn More

»

Cut costs (not corners) from your application lifecycle

»

Performance Center blog

»

Download a trial version of HP LoadRunner 9.5

Technology for better business outcomes



Sunday, April 5, 2009

Finding a Needle in a Haystack

The job of finding the proverbial needle in a haystack has always been a challenge. Digging through a haystack and struggling to find a needle is hard, if not near impossible. Plus you don't even know if there is a needle in there! After searching for while, I know (or at least I hope) that you'll be asking for some tools to help you out.



The first tool that I can think of is a metal detector. This makes sense. Use the metal detector to discover if there is a needle in the stack at all. If there isn't, then you don't have to waste your time looking for it. Yay!!! At least, now I know that I can quickly check stacks and only search through stacks that actually have a needle.

Is that the best or only tool that you can use? If you can cut the search time down more, wouldn't that good? Sure, unless you really like digging through that hay. What if you had a strong magnet? That would rock!!! First, use the metal detector to make sure that there is a needle; then bring in the strong magnet and voila! Out comes the needle, and you're done! No more searching required, and your job just got a whole lot easier.

As you may have already guessed, I'm not here to discuss haystacks. They are fun and all but not really the point. Let's tie this back to performance testing. That's more fun than haystacks anyway.

In the beginning, people tried to performance test manually with lots of people attacking an application at the same time. This was found to be time consuming, not repeatable, and not that beneficial, like digging through that hackstack by hand.

Then came automated load testing with monitoring. Now, there's a repeatable process and monitors to help discover if there were problems. This is a tremendous time saver and helps to ensure the quality of apps going to production--the metal detector, if you will.

Most of you know and love the metal detector, as well you should. But it is about time to be introduced to the strong magnet of performance testing. Say hello to Diagnostics (Diag). Some call it deep-dive; others call it code level profiling. I call it the time saver. Diagnostics will pinpoint (or should I say needle point :-) ) problems down to the method or sql statement level. That is huge! Now you have much more information to take back to developers. No longer just transaction level information, now you can now show them the method or sql statement that is having the problem within the transaction. This slashes the time it takes to fix problems. Diagnostics has agents on the application under test (AUT) machines. It then hooks the J2EE and/or .NET code. This is how it can show where there are bottlenecks. Highlighting slow methods and sql statements are good, but being able to tie them back to a transaction is even better.

From personal experience, I can tell you that Diagnostics works extremely well. Back at good old Mercury Interactive, we had a product that was having some performance issues. Our R&D had been spending a few weeks looking for the problem(s). Finally, I approached them and asked if they had tried our Diagnostics on it. They of course said no; otherwise this would be a counterproductive story. After I explained to them in detail, the importance and beauty of Diagnostics, they set it up. Within the first hour of using Diagnostics, they found multiple problems. The next day, all of them were fixed. R&D went from spending weeks looking for the needles that they couldn't find to finding them within an hour with the magnet I gave them. And now they use always use Diagnostics as part of their testing process.

I've heard people complain that it takes too much time to learn and set up. First off, it isn't that complicated to set up. Secondly, yes it is something new to learn but it's not too difficult. Once you learn it, however, it is knowledge that you can use over and over again. It took time to learn how to performance test to begin with. Record, parameterize, correlate, and analyze all took time to learn. This is just one more tool (or magnet) in your tool belt. It will save you and the developers tremendous amounts of time.

Isn't Diagnostics something that IT uses in production? Yes it is! Both sides (testing and production) can gain valuable information from using Diag. And both for the same reason. Find the problem and fix it fast. Testers can always run the test again to see if they can reproduce a problem. But, in production, once the issue occurs, they want to be able grab as much information as possible so that they can prevent it from happening again. After production gets this information, they can pass it back to testing to have testing reproduce the issue. If performance group is using the same Diag as production, then it is easier to compare results. A dream of production and testing working together in harmony, but I digress.

I have said for years that if performance testers are not utilizing diagnostics, then they are doing a disservice to themselves and to the task. Stop digging through the haystack. Pick up that magnet and start pulling out those needles!

Click here to learn more