Why I’m really going to HP Discover 2012
I’m part of our product marketing team and HP Discover is certainly somewhere in the job description. But, that’s not why I’m really going.
Of course it could be that I love Vegas and the excitement and energy of the whole environment, but that’s not why.
Or, it could be a great agenda with over 50 application focused track sessions focusing on topics such as:
- How people are doing mobile testing
- Testing with Virtualized Services
- LoadRunner, Performance Center and Diagnostics
- Manual and Automated Testing
- What’s new in performance testing
- Project and Portfolio Management best practices
- Agile
- Etc,
but that’s not why.
Perhaps it’s the keynote sessions to hear from customers such as Jeffery Katzenberg and Dreamworks or our CEO, Meg Whitman,
Maybe the closing celebration featuring Sheryl Crow and Don Henley?
Nope…
Those are all great reasons to go to HP Discover, but for me, the real reason is You. I go to HP Discover for the opportunity to connect with you - my peers and learn about your challenges and successes. There are few events in the world, where more dedicated and focused IT professionals gather and connect with each other. I hope to see you at HP Discover – Don’t forget to use the code DSCVRSW to save $300 when you register. -> HP Discover Registration
Additional information about HP Discover Vegas 2012 is available at www.hp.com/go/discover.
Mobile Testing webinar invitation
Don't let your end users experience your defects or be the ones to crash your systems.
On October 26th, we’re holding a webinar to talk about :
|
|
|
Interested? - Here’s the details: |
October 26, 2011 |
10:00am PT / 1:00pm ET / 7:00 CET |
Register and join us...
New registration link : -Register.
If you’re interested in HP LoadRunner or Performance Center you can follow us
- on the HP Performance Validation Blog or even follow us @hploadrunner on Twitter
Testing is Back on the Charts
...and Quality sounds better than ever! The latest release entitled Here Comes Science from the Grammy-winning duo They Might Be Giants (John Linnell and John Flansburgh) includes a track called "Put It to the Test" which celebrates the enthusiasm of testing a hypothesis for the purposes of ratifying our understanding of the truth. In short - testing is actually COOL! This is not a song just for kids - no, no, NO! If you've been a veteran software tester or worked in any capacity for quality assurance, I think you'll find the sincere advocacy for testing very refreshing. I'll admit it had me singing along in the car:
"If there's a question bothering your brain - That you think you know how to explain
You need a test - Yeah, think up a test
If it's possible to prove it wrong - You're going to want to know before too long
You'll need a test
If somebody says they figured it out - And they're leaving any room for doubt
Come up with a test - Yeah, you need a test
Are you sure that that thing is true? Or did someone just tell it to you?
...Find a way to show what would happen - If you were incorrect
...A fact is just a fantasy - Unless it can be checked
...If you want to know if it's the truth - Then, my friend, you are going to need proof
Don't believe it 'cause they say it's so - If it's not true, you have a right to know"
These words are not just literally music to my ears as a die-hard software tester and also as person who respects the processes and disciplines of the scientific community. You should know that in our world of computer science and software there is an active resurgence of quality initiatives - a testing renaissance; integrating QA and testing into agile development, testing in production environments, testing for green carbon footprint and even testing requirements before we build anything. That's right just thinking about your own thinking is a form of testing - that is, if you're willing to question your thoughts honestly!
The new Music CD & Video DVD combo includes also a video for the song which can be seen on YouTube:
At your next SCRUM or Team Meeting - please add an agenda item to listen to the song, watch the video, discuss the lyrics and try to relate the ideas to how you are doing testing in your projects. Testing is back and on the rise - and now we have a cool song to go with it!
But don't just take my word for it...take my recommendation and PUT IT TO THE TEST! 
Update: 15-hours into the Non-stop HP Virtual Conference
*original post was at 11:30pm on 9/29/2009*
Okay - so I've been working the Worldwide HP Virtual Conference: Functional, Performance and Security Testing for about 15 hours now - nearly non-stop and I've had some great chat sessions with customers from all over the world. I've been on since 8:30am PST from Mountain View, California where I live. I've had 3 medium-sized cups of coffee - actually called Depth Charges from the coffee shop by my house. These are 16 ounces of regular coffee with 2 shots of espresso added for and extra charge. I'm posting live updates on Twitter and the feedback has been great. Also, I've been broadcasting live from my home studio on ustream.tv the entire time (almost).
The HP Virtual Conference materials are still available through November 2009
The LoadRunner Non-stop HP Virtual Conference
THE TIME HAS COME!! I really don't want you to miss the Worldwide HP Virtual Conference: Functional, Performance and Security Testing in Today’s Application Reality. And just to show you how committed I am to you and to the conference, I'm going to attend the conference non-stop for the entire duration, just as we did in the promotional video! I will be online in chats, at the booth, in the lounge and presenting the entire time and I will also be documenting the experience live from my home office, with video streaming and chatting. Click here to register for free, now!!!
Follow Mark on twitter and ustream.tv for the duration of the entire conference!
Follow the Entire HP Conference on twitter
This conference is going to be the most awesome!
- 40 sessions covering Agile, Cloud, Web 2.0, Security, customer best practices and more
- Localized booths and content for Benelux, Nordics, Austria & Switzerland, France, Germany, Japan, Korea, Iberia and Israel
- Live worldwide hacking contest
Here are just the Top 5 reasons you should attend:
#5 - No need to spend days out of the office
#4 - No travel or registration fees
#3 - No long registration lines
#2 - No need to choose one session over another - see them all!
#1 - No need to choose one representative from your department to attend. Everyone can attend and learn!
(Of course, I think the best reason is it's a great excuse to work from home for the entire day...which is exactly what I'll be doing!)
Conference Dates and Schedule
Americas – 29 September:
11am – 7pm EDT/ 8am – 4pm PDT
APJ – 30 September:
11:00am – 5:00 pm (AEST) / 10:00am – 4:00pm (Tokyo)
9:00am – 3:00pm (SG time) / 6:30am – 12:30 pm (Bangalore)
EMEA – 30 September:
8:00am – 4:00 pm (GMT+1) / 8:00am - 4:00pm (UK)
9:00am to 5:00pm (Amsterdam, Berlin, Paris, Rome)
REGISTER NOW!!!
See you online, at the SHOW!
Performance Testing Needs a Seat at the Table
It is time Performance Testing gets a seat at the table. Architects and developers like to make all the decisions about products without ever consulting the testing organization. Why should they? All testers have to do is test what's created. If testers can't handle that simple task, then maybe they can't handle their job. I know this thought process well. I used to be one of those developers
. But I have seen the light. I have been reborn. I know that it is important to get testers input on products upfront. And actually it is becoming more important now than ever before. 
We need to get more groups involved up front. The more you know, the better the decisions, the better off the application is going to be. Performance Management for Agile Projects
Performance management is an integral part of every software development project. When I think of agile projects, I think about collaboration, time to market, flexibility, etc. But to me the most important aspect of agile processes is its promise of delivering a “potentially shippable product/application increment”. What this promise means for application owners and stakeholders is that, if desired, the work done in iteration (sprint) has gone through enough checks and balances (including meeting performance objectives) that the application can be deployed or shipped. Of course, the decision of deploying or shipping the application is also driven by many other factors such as the incremental value added to the application in one sprint, the effect of an update on company’s operations, and the effect of frequent updates on customers or end-users of the application.
Often application owners fail to provide an objective assessment of application performance in the first few sprints or until the hardening sprint—just before the application is ready to be deployed or shipped. That is an “Agile Waterfall” approach, where performance and load testing is kept aside until the end. What if the architecture or design of the application needs change to meet the performance guidelines? There is also a notion that performance instrumentation, analysis and improvements are highly specialized tasks which result in resources not being available at the start of a project. This happens when the business and stakeholders are not driving the service level measurements (SLMs) for the application.
Application owners and stakeholders should be interested in the performance aspects of the application right from the start. Performance should not be an afterthought. The application’s backlog in agile contains not only the functional requirements of the application but also the performance expectations from the application. For example, “As a user, I want the application site to be available 99.999% of the time I try to access it so that I don’t get frustrated and find another application site to use”. Performance is an inherent expectation behind every user story. Another example may be, “As an application owner, I want the application to support as many as 100,000 users at a time without degrading the performance of the application so that I can make the application available globally to all employees of my company”. These stories are setting the SLMs or business-driven requirements for the application, which in turn will define the acceptance criteria and drive the test scripts.
It is important that, if a sprint backlog has performance related user stories (and I’ll bet you nearly all of them do) its team has IT infrastructure and performance testers as contributors (“pigs” in Scrum terminology). During release planning (preferably) or sprint planning sessions these contributors must spend time in analyzing what testing must be performed to ensure that these user stories are considered “done” by the end of the sprint. Whether they need to procure additional hardware, modify the IT infrastructure for load testing, or work on the automation of performance testing; these contributors are an active member of the sprint team participating in daily scrums. They must keep a constant pressure on developers and functional testers to deliver the functionality for performance testing. After all, the success of the sprint is measured as whether or not every member delivered the final product that fully met the acceptance criteria and on time.
To me, performance testing is an integral part of the agile process and it can save cost to an organization. The more you wait to conduct performance tests, the more expensive it will become for you to incorporate changes. So don’t just test early and often – test functionality and performance in the same sprint!
ROI: You Get What You Pay For
We've all heard that saying. But how many times do we really follow it? We have bought, ok I have bought, cheap drills, exercise machines, furniture, only to be sorry about when they break prematurely. Or you find a great deal on shoes only to have them fall apart on you while you are in a meeting with a customer. I'm not saying that happened to me, but I know how that feels. Cheaper always seems like it's a better deal. Of course it's not always true. I can
tell you that now I pay more for my shoes and I'm much happier for it . No more embarrassing shoe problems in front of customers (not saying that it happened to me). In fact when my latest pair of shoes had an issue, I sent them back to the dealer and they mailed me a new pair in less than a week! That's service. You get what you pay for. The same holds true for cars, clothes, hardware, repairs, and of course software testing tools. You knew I was going to have to go there.
I hear from some people that Performance Center is too expensive. I'm always amazed when I hear that. I'm not saying Performance Center is for everyone. If you don't need PC's features and functionality, it may appear pricey. If you are only looking for a simple cell phone, then a phone that connects to the internet and to your email and also has a touch screen may seem a little pricey. But if you need those features then you are able to see the value in those features.
I can sit here, go through each unique feature in Performance Center and explain to you the value (Not saying that it will not come in a future blog
). But why would you listen to me, I'm the product manager. Of course I'm going to tell you that there is a lot of value to PC. Well IDC,a premier global provider of market intelligence and advisory services, has just released an ROI case study around HP Performance Center. A global finance company specializing in real estate finance, automotive finance,
commercial finance, insurance, and online banking was able to achieve total ROI in 5.6 months. Yes! Only 5.6 months, not 1 or 2 years. But a total return on investment in 5.6 months. If anything I think we should be charging more for Performance Center
. This company did not just begin using PC, they have been using PC for the last 4 years. And during that time they have found a cumulative benefit of $24M. I'd say that got a lot more than what they were paying for. Not only did they see a 5.6 month return on the investment but they are seeing a 44% reduction in errors and a 33% reduction in downtime in production. What gave them these fantastic numbers?
Increased Flexibility
By moving to Performance Center they were able to schedule their tests. Before PC they had controllers sitting around being idle while other controllers where in high demand based on the scenarios that were on them. But once they were able to start to schedule their tests, they began performing impromptu load tests and concurrent load tests. They started to see that they were able to run more tests with fewer controllers.
Increased Efficiency
While they are able to increase their testing output, they didn't increase their testing resources.
Their testers/engineers were able to more through PC than what they could do with any other tool.
Central Team
With the central team they were able to increase their knowledge and best practices around performance testing. By doing this along with performing more test, they were able to reduce their error rate by 44% and their production downtime by 33%.
So you get what you pay for. Put in the time and money. Get a good enterprise performance testing product. Invest in a strong central testing team. You will get more out, than what you put in. In the case of this customer they got $21M out over 4 years.
Also invest in good shoes. Cheap shoes will only cause you headaches and embarrassment (Not saying that it happened to me).
Finding a Needle in a Haystack
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. 
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. Taking visibility for granted?
Testers are naturally curious people. We enjoy the creation of questions for the purpose of finding the truth, or better still for the purpose of creating new truths. For centuries, the true professional testers have been scientists who more often than not were the determiners of new truths and thus we recall them as inventors. Back in the mid-1700's a theologian and scientist Joseph Priestley conducted several experiments to determine what types of gasses were generated by plants. It started with a curiosity about the observed behavior of a wax candle burning within a glass jar. And it was truly a curious thing because the wax candle burned out long before it exhausted the fuel supply of wax or wick. The flame had consumed all of the fuel supply of oxygen from the sealed environment, proven by the fact that when he tried to re-ignite the candle inside the jar using a simple magnifying glass to converge intense rays of sunlight on the candle's wick, it failed.
When Priestley attempted the same experiment but this time adding a sprig of mint into the glass jar with the candle the result was similar at first: the candle burns, oxygen is consumed, candle goes out, can't re-ignite it with sunbeams. But after nearly a month with the candle left isolated in the jar with the sprig of mint, Priestley then re-attempted to ignite the candle with the magnifying glass and rays of sunshine. And of course it worked. The candle was lit and once again consumed the oxygen until it burned out. Priestley deduced that the plant was somehow producing a gas that allowed the candle's flame to burn once again. What he could not have predicted, is that he would be the first to discover a new truth about the role of oxygen in photosynthesis.
Priestley's methods really got me thinking, especially about his test tools and techniques. All he used were rudimentary equipment and simple deductive reasoning for analysis. What if we were to attempt this same experiment today using contemporary scientific inventions? We would probably use a oxygen sensor to measure the amount of oxygen in the jar. This would make all the other implements for the experiment obsolete: the wax candle, the magnifying glass, the need for bright sunshine. The creation of the lambda probe oxygen sensor in the late 1960's was a response to the demand for measurement of oxygen in an experiment, machine or system. The design of the sensor allowed for visible measurement of an invisible gas. Even Priestly himself would have appreciated the sensor not simply for the new visibility it provided, but for the ease of use and accuracy in measuring his experiment.
For Priestley in the mid-1700's photosynthesis was unknown and oxygen was both invisible and immeasurable. Boris Beizer more than 200 years later was challenged to measure the known workings of the computer which were, for all intents and purposes, inside an invisible black box. The discoveries and solutions that resulted from their work show us how inappropriate it is to take any prior science for granted and also provide for us a new baseline for how to test. Simply, it is easier to correlate a visible test measurement to the tests objectives or pass/fail criteria. As a result, testing tools today already make test measurements visible, actionable and automatically correlate* the results back to pass/fail criteria. Today we take for granted that nearly every testing tool comes with mechanisms for "making visible" the performance metrics from the system under test. Just as we take for granted that every modern automobile now uses oxygen sensors and an onboard computer as essential components to improve fuel efficiency.
But just making something visible isn't enough. Consider LoadRunner's monitoring and diagnostics capabilities. Could you imagine today having to monitor CPU resource utilization without having the test tool automatically make the measurement visible for you? In the 1980's Boris Beizer shared stories about his counting CPU ticks with an AM radio next to the machine. That sounds like such an old solution - almost like having to measure oxygen with a wax candle in a jar. My point is that visibility should be understood as a means to improving measurability. Measurability is what truly accelerates the testing process. Innovation in performance testing should improve and extend the visibility and measurability we have today. What more can we make visible? What new methods of measuring, arranging and correlating test data can we create? Can we automate the capabilities we have today or build intelligence to aggregate or parse this new data?
And we don't have to start with a wax candle in a jar or an AM radio.
*- see lr_end_transaction("login", LR_FAIL);
Tomorrow: a webinar with Nationwide
|
|
|
|
-
Product Manager
-
Sr Prod Marketing Mgr
- WW Sr Product Marketing Manager for HP ITPS VP of Apps & HP Load Runner
-
-
Follow Us on Facebook
-
Follow Us on Twitter
-
Follow Us on LinkedIn
-
Follow Us on Flickr
-
Follow Us on Youtube
-
Follow Us on SlideShare
-
Follow Us on Google+
