Real-Time Technology Solutions (RTTS) Blogs and News Updates

Steve Jobs - the End of an Era

2011-10-24T10:46:22.275-04:00

Steve Jobs has left us. I was never an Apple user, due to my corporate customers’ use of the Microsoft operating system. But as an entrepreneur, I have always been a curious observer of his career. He’s one of the original Pirates of Silicon Valley who revolutionized the convergence between corporate technology and the consumer.

Steve not only brought to the consumer the original widely adopted PC, the Apple II, but created a home computing revolution with the introduction of the mouse and graphical user interface (GUI) with the Mac, which was co-oped from Xerox’ PARC research center. He had famously said about his taking of PARC’s discovery “Good artists copy. Great artists steal.’” But Bill Gates and Microsoft one-upped him by co-opting the MAC’s mouse and GUI in the Windows operating system that went on to dominate the market and drive Jobs and Apple to a point of irrelevancy. “It’s more like we both had this rich neighbor named Xerox, and I broke into his house to steal the TV set and found out that you had already stolen it” said Gates.

When Jobs returned to Apple in his famous second stint, be gave birth to the iPod, iTunes, iPhone and iPad, essentially creating the portable music store/player, smart phone and tablet markets. He allowed consumers to enjoy and customize their entertainment while also keeping an eye on their corporate happenings through email, blogs, and other sources of information. Thus he helped create ‘convergence’, a term that started cropping up around 8 years ago. It refers to the blending of the line between corporate technology and consumer products (see my blog “The Technology Just Crept Up on Us…” http://bit.ly/jNLt9k).

The impact on our lives is amazingly life changing. Work life and personal life have blended together so subtly that we hardly noticed, mostly because of Steve Jobs.

The end of an era......

Posted by Bill Hayduk on Monday, October 24, 2011 10:44 AM EDT
Leave a comment | View Comments (0)

A discursive and irreverent but not necessarily untrue history of the IBM Rational test tools (pt 2)

2011-10-24T10:28:29.275-04:00

<a href="http://www.rttsweb.com/interactive/blogs/viewComment.jsp?bid=75&bun=abaruz&bc=+Allan">Where was I</a>? A few <s>days</s> months ago we kicked off this series with the SQA company based in Cambridge, Mass. Rational picked them up for their automated functional test suite; this had nascent but inadequate load testing capabilities.

The genesis of the main performance tool began with the Performance Awareness Corporation’s test tool, preVUE, which ran on Unix and was scripted using a language called VU. Versions of the tool could record and play back TTY, X Window, client-server, HTTP, and certain database sessions. It included a number of graphing tools and pre-packaged metrics for presenting the results of performance tests.

Rational acquired Performance Awareness in March, 1997, only one month after the merger with SQA had been finalized. Rational bought some third-party tools (NutCRACKER) to make a quick port of the tool to Windows, and merged the IDE with the SQA Robot interface. The control and role-modeling portions were incorporated into Rational TestManager. Now, testers could run emulated network loads while executing test cases on their client-server applications, all within Rational SQA LoadTest. Rational added some features and started mismarketing the amalgamation under various names (“Rational Performance Studio,” “Rational TeamTest for Performance,” and so on).

I would say that VU lies somewhere between C and Perl in its language model, though <a href="http://www.rttsweb.com/interactive/blogs/blogs.jsp?bc=Jon+Harris&bun=jharris" >Jon Harris</a> argues that it’s like a subset of C with VB-like string handling. It featured a number of in-language additions to allow for easier string handling, garbage collection, and a small-scale distributed shared memory. Whereas SQA Robot would record actions and properties of the Windows components, the VU environment would record the network traffic between the client and server. The modeling environment distinguished between virtual users, the roles they play, and the actions that each role may perform.

Protocol handling was somewhat primitive compared to today; the scripter had to be anywhere from conversant to expert in the protocol to do anything beyond the basics, but allowed access to the lowest levels of protocol detail. Distributed shared memory allowed seamless communication across agent hardware, so the programmer could emulate people working together, and even allowed limited communication between user and running schedule, so with some moderate programming effort up-front, you could shift the workload priorities mid-test. The preVue environment allowed you to specify that virtual users be emulated using threads or processes, trading a more reliable scripting environment for scalability across the generators, but defaulted to processes, the safer bet—LoadRunner defaults to threads. (I do not know how much amateur code I’ve gone through to find that poor variable scoping in relation to threading caused inexplicable errors.) The (third-party?) graphing package had informative views of the data but not in a form that could be published or printed easily, especially outside of the X Window system.

Rational did add a few features, though. Protocol-specific support for new environments such as Tuxedo and other tools were added to the VU language. In addition to the C control constructs in VU, the individual scripts could be composed with GUI “selectors” to model the scenarios in place, and these scenarios could be mixed and matched for the various roles that people played in the population being emulated (“user groups”). So a VU-savvy programmer could model the low-level aspects of the network protocol, but a naive business analyst could alter the weight, pacing, and transactions to determine how traffic and performance would be affected under a number of projected what-if situations. This gave the tool unrivalled performance and scalability modelling capabilities that is only matched today by the exercise of heavy programming skill.

About this time (February 1997?), Rational also acquired Requisite, Inc., which sold tools that allowed you to collect application requirements. One notable feature was it could comb through Microsoft Word documents to aid in the generation and maintenance of a requirements database from legacy documents. If you had such a collection stored somewhere, adoption of RequisitePro was easy; configure it to follow your requirement naming and formatting conventions and point it to your document store, followed by a clean-up phase. It eventually became RQM.

To be continued....

Posted by R. Allan Baruz on Monday, December 20, 2010 3:16 PM EST
Leave a comment | View Comments (0)

The Land of Opportunity No More - Indian Tech Workers Go Home

2011-05-27T11:55:50.909-04:00

We have now come full circle on the outsourcing situation. A recent poll from a tech-job portal states that 69% of technology professionals from India intend to head home, with 57% of these professionals being US citizens or permanent residents ()http://bit.ly/jC8svA . Read that again - that is over two thirds of the Indian IT professionals in the US. We are no longer the land of opportunity for the world’s technical community. In the late 1990’s and throughout the 2000’s, workers from around the world, and more specifically India, would come the US to work for our blue chip firms and learn the ways of corporate IT from America. Many would hope to get their green card and then citizenship in hopes of striking it rich during the technology boom and live “the American dream”. Based on a survey of over 1,000 Indian IT workers, many feel that the opportunities are better in India than in the US. Another reason some are heading back is they believe their children will receive a better education in India.

So there you have it. The “land of dreams and opportunity” for Indian IT workers that once was the US is no more. And we did it to ourselves. Big tech firms and CEOs from corporate America talked out of both sides of their mouths. From one corner they would say there were no tech jobs in the US and from the other corner would lobby the government for more H1B visas. Why? Cheaper labor and therefore lower costs, of course. Their short-sightedness regarding quick quarterly profits never took into account the damage that would be done to the US workforce.

According to the Department of Defense, there has been a 43% decline in computer science graduates over the past 5 years (http://smrt.io/m4w9SB). Adding to the shortage is the pending retirement of baby boomers. And although there is currently a high unemployment rate among American workers, knowledge workers experience only a 3.7% unemployment rate. So, America, get your kids to stop drinking Espresso and start learning Java. Supply is down and demand is high for young IT workers, meaning increased opportunity and increased wages. While the Indian labor force has had its fill and corporate America has helped cause this dilemma, there may be something to be gained by this for the US labor market. Time will tell…

Posted by Bill Hayduk on Friday, May 27, 2011 11:53 AM EDT
Leave a comment | View Comments (0)

A Social Commentary on Social Networks

2011-02-11T12:55:33.940-05:00

Social networks have been around for awhile now, or at least when measured in in internet years (Friendster launched in 2002, MySpace and LinkedIn in 2003 and Facebook in 2004). I get LinkedIn and I like it. It is a great way to perform virtual networking at a speed and volume that would not be possible before. It also is a great resource to share targeted information with people in your industry, to look for jobs and to keep in touch with colleagues present and past.

I only dabbled in MySpace to check it out but found myself joining Facebook to, primarily, keep an eye on my 14 and 11 year olds. But the longer I was on Facebook, the more people tried to “friend” me. I understand why, on LinkedIn, someone who I may not know, but is a contact of someone I know, may want to expand their network. And I do this also. But I do not understand why someone who either barely knows me or never was a friend of mine would want to “friend” me on Facebook. Why would they want to read posts meant for my friends or look at pictures of my kids? Why would they want to see posts from my kids or my friends? Is Facebook creating the ultimate voyeur environment that was started by the reality shows like MTV’s ‘The Real World’ and has sunk to new lows with ‘Jersey Shore’ and ‘Keeping Up with Kardashians’? Am I too old and don’t get it?

What’s your opinion?

Posted by Bill Hayduk on Friday, February 11, 2011 12:49 PM EST
Leave a comment | View Comments (0)

A discursive and irreverent but not necessarily untrue history of the IBM Rational test tools (pt 2)

2011-01-12T11:15:08.249-05:00

Where was I? A few ~~days~~ months ago we kicked off this series with the SQA company based in Cambridge, Mass. Rational picked them up for their automated functional test suite; this had nascent but inadequate load testing capabilities.

The genesis of the main performance tool began with the Performance Awareness Corporation’s test tool, preVUE, which ran on Unix and was scripted using a language called VU. Versions of the tool could record and play back TTY, X Window, client-server, HTTP, and certain database sessions. It included a number of graphing tools and pre-packaged metrics for presenting the results of performance tests.

Rational acquired Performance Awareness in March, 1997, only one month after the merger with SQA had been finalized. Rational bought some third-party tools (NutCRACKER) to make a quick port of the tool to Windows, and merged the IDE with the SQA Robot interface. The control and role-modeling portions were incorporated into Rational TestManager. Now, testers could run emulated network loads while executing test cases on their client-server applications, all within Rational SQA LoadTest. Rational added some features and started mismarketing the amalgamation under various names (“Rational Performance Studio,” “Rational TeamTest for Performance,” and so on).

I would say that VU lies somewhere between C and Perl in its language model, though Jon Harris argues that it’s like a subset of C with VB-like string handling. It featured a number of in-language additions to allow for easier string handling, garbage collection, and a small-scale distributed shared memory. Whereas SQA Robot would record actions and properties of the Windows components, the VU environment would record the network traffic between the client and server. The modeling environment distinguished between virtual users, the roles they play, and the actions that each role may perform.

Protocol handling was somewhat primitive compared to today; the scripter had to be anywhere from conversant to expert in the protocol to do anything beyond the basics, but allowed access to the lowest levels of protocol detail. Distributed shared memory allowed seamless communication across agent hardware, so the programmer could emulate people working together, and even allowed limited communication between user and running schedule, so with some moderate programming effort up-front, you could shift the workload priorities mid-test. The preVue environment allowed you to specify that virtual users be emulated using threads or processes, trading a more reliable scripting environment for scalability across the generators, but defaulted to processes, the safer bet—LoadRunner defaults to threads. (I do not know how much amateur code I’ve gone through to find that poor variable scoping in relation to threading caused inexplicable errors.) The (third-party?) graphing package had informative views of the data but not in a form that could be published or printed easily, especially outside of the X Window system.

Rational did add a few features, though. Protocol-specific support for new environments such as Tuxedo and other tools were added to the VU language. In addition to the C control constructs in VU, the individual scripts could be composed with GUI “selectors” to model the scenarios in place, and these scenarios could be mixed and matched for the various roles that people played in the population being emulated (“user groups”). So a VU-savvy programmer could model the low-level aspects of the network protocol, but a naive business analyst could alter the weight, pacing, and transactions to determine how traffic and performance would be affected under a number of projected what-if situations. This gave the tool unrivalled performance and scalability modelling capabilities that is only matched today by the exercise of heavy programming skill.

About this time (February 1997?), Rational also acquired Requisite, Inc., which sold tools that allowed you to collect application requirements. One notable feature was it could comb through Microsoft Word documents to aid in the generation and maintenance of a requirements database from legacy documents. If you had such a collection stored somewhere, adoption of RequisitePro was easy; configure it to follow your requirement naming and formatting conventions and point it to your document store, followed by a clean-up phase. It eventually became RQM.

To be continued....

Posted by R. Allan Baruz on Tuesday, January 11, 2011 11:15 AM EST
Leave a comment | View Comments (0)

Rise of the Smartphone

2011-01-11T10:41:11.155-05:00

For some time I've been travelling with a cell phone, small video player and GPS. About 2 months ago I upgraded my cell phone to a Droid X. I was at Verizon looking at the slew of available smartphones I had the Droid X in hand) when another customer approached me and started praising the phone. He said he was an application developer (freelance or hobbyist I suppose) for the Android OS and had tried out many of them and ended up with the Droid X for his own use. I was actually sold on the phone even before he approached me as I wanted a single unit to take the place of the multiple devices I was carrying around. Though all of the smartphones posses my desired qualifications, the Droid X had the biggest screen. So I took the plunge and bought the phone. Since then I've been reading any article I come across that catches my eye with words such as "Droid", "Smartphone", or "Android".

It is interesting to read the articles on sales of the phones. Currently according to a recent Nielsen survey, over the past 6 months, 40% of the smartphone sales went to those with the Android OS. There are statements and statistics regarding the overall market share between Apple, RIM, Android and Windows 7 phones. The point I want to make is that progress is moving us in a certain direction; and that direction is changing how we as a people interact; and that interaction is changing the landscape of my home turf in performance testing.

No matter where you go, there are people on their web-enabled smartphones accessing some site. I went to the theatre last weekend to see a movie and as I'm making my way from the ticket line to the concession stand to the theatre, I commented to myself the number of people staring at their phones. Heck, After getting to my seat, I was checking email and browsing web sites. I could jest that they didn't need to have the lights on in the theatre because of all of the light being emitted by everyone's cell phones.

Back to my point. With millions of smartphones being sold, people are accessing web sites more often, and that is changing the dynamics of the digital world. I came across an advertisement on smartphones while on line at the post office that wasn't specifically about this topic, but spurred the thought. How do we take this into account when testing comes into play? This new class of users needs to be quantified. How quickly is their population rising? Are they changing the characteristics of the already existing users? Are there enough current statistics or are there even measuring tools in place to gauge the changes?

As these questions can only be answered on a site by site basis, if you have been dealing with these new parameters, I'd like to hear about it.

Posted by Jonathan Harris on Tuesday, January 04, 2011 12:10 PM EST
Leave a comment | View Comments (0)

Software Firms Gorge at the All-You-Can-Eat Buffet

2010-09-16T17:41:10.550-04:00

What is it with HP, IBM, Oracle and others gobbling up companies? They remind me of the Nathan's Hot Dog Eating Contest in Coney Island on the 4th of July.

Since 2009 these 3 firms have been on a binge - gobbling up companies like Kobayashi and Joey Chestnut swallow hot dogs (FYI - the record for hot dog eating is 68 in 10 minutes). A partial list of firms acquired are:

HP has acquired EDS, Lefthand Networks, 3Com, Palm, 3PAR, ArcSight and Fortify. This does not include previous purchases of Compaq, Peregrine, Mercury Interactive, Spy Dynamics and Opsware.
IBM has acquired Guardium, Lombardi, NICS, Initiate Systems, Intelliden, Cast Iron Systems, Sterling Commerce, Ounce Labs, Coremetrics, BigFix, Storwise, Datacap, Unica Corporation and OpenPages. This does not include previous purchases of PricewaterHouseCoopers (PWC), Rational Software, Candle, FileNet, ISS, Cognos, SPSS, Watchfire, and Telelogic.
Oracle has purchased Silver Creek, Sun Microsystems, Convergin, AmberPoint, Phase Forward and Secemo. This does not include previous purchases of Seibel, PeopleSoft, Hyperion and BEA Systems.

My point is that this takeover of niche players or players in single verticals is a trend that is gaining momentum and speeding up. There is a convergence of markets and all three are trying to become a one-stop-shopping place for the F500. All are beefing up for the fight in spaces such as storage, security, computers, operating systems, database software, middleware and applications.

This gorging will continue as the big 3 try to fill their stacks. My question is: which one is Joey "Jaws" Chestnut, which is Takeru "Tsunami" Kobayashi and which is Patrick "Deep Dish" Bertoletti?

Stay tuned...

Posted by Bill Hayduk on Thursday, September 16, 2010 5:36 PM EDT
Leave a comment | View Comments (0)

Unwarranted government interference

2010-09-09T15:12:23.081-04:00

What in tarnation? Senator Kerry is drumming up his base to rally the vote. Sounds like unwarranted government interference to me. I call for a separation of Sports and State! Oh, by the way, Send Swish! You have until 4:00 pm today to vote. It's down to the wire.
Posted by R. Allan Baruz on Thursday, July 08, 2010 2:13 PM EDT
Leave a comment | View Comments (0)

A discursive and irreverent but not necessarily untrue history of the IBM Rational test tools (pt 1)

2010-09-09T15:12:08.034-04:00

SmartBear Software, AutomatedQA, and Pragmatic Software recently merged to become SmartBear Software. I was feeling a bit nostalgic and pieced together some of my recollections of what was going on when I first entered the test industry, from the perspective of a user of the testing toolchain of what was eventually to become the IBM Rational division. I leave it to others to describe how the personalities behind the scenes moved things about, although I may drop a few names of people I do not know. I only have a few minutes to dash this off, so if you see any errors that require correction or if you know more about the gonigs-on than I do, hit the Comments button below and set me straight. Rational Machines first hit the market in the early eighties, selling their Ada programming environment tools to customers who were interested in building the kinds of applications one builds with Ada. These applications must have been very process-heavy (m*cough*ilitar*cough*y), as it required the combined might of not just Grady Booch, but James Rumbaugh (1994) and Ivar Jacobson (1995) as well, to develop not just a method, but a methodology capable of guiding developers through it. After some negotiation, their respective processes and object notations were ironed out. We finally had a Unified Modeling Language and the Rational Unified Process, just around the time that the Agile Manifesto and Extreme Programming were coming into vogue. Anyway, let's back up a couple of months: When Rational Software decided to enter the testing market, it entered swiftly and surely: they bought Visual Test (formerly MS-Test) from Microsoft, then announced they would merge with SQA Software a month later (November 1996). This was the age of the client-server application suites, where thick clients were created to access back-end databases using proprietary protocols over networks that could be based on Ethernet or token-ring technologies. The original functional testing tool that SQA Software had been peddling was called Manager, which allowed users to manage their testing efforts. They created a functional automation tool which eventually came to be called Robot. With Robot, you could record (most of) the actions of a computer user, and then re-play those actions using Visual Basic 2. One of SQA's biggest claims to fame was their tight integration with the "fourth generation" application building tool, PowerBuilder. All controls that came out of the box with PowerBuilder were easily recordable and scriptable using the tool. Perhaps running a Manager, Robot, Visual Basic, and PowerBuilder on a 1993-era workstation presented some resource issues? Whatever the reason, SQA picked up a third-party clone of Microsoft Visual Basic called Softbridge Basic Language (SBL) from Mystic River Software and integrated it with Robot. The re-branded "SQABasic" language was used to manipulate some of the object-oriented Windows components then in use. SQA created a built-in library of data control objects to manipulate and query the properties of these components during playback. The results of a test looked like the results of unit testing frameworks of today, with green, yellow, and red "verification points" that showed whether the system under test matched the expected status. Manager was used to control the test engine, display the results, and model the test process, and the whole thing was called SQA Suite. Upon merging in February 1997, Rational re-branded the suite as SQA TeamTest, SQA Manager, and SQA Robot. The version at the time was TeamTest 6.1 or so. As the market for benchmarking tools for termcap-based tools faded and performance and scalability tools for client-server tools increased, SQA had started adding features to the test engine to automate Robot instances on several workstations and kick them off from a central testing point; this was the origin of SQA LoadTest. This approach was not scalable and Rational began casting about for a new solution. To be continued...
Posted by R. Allan Baruz on Tuesday, July 20, 2010 9:59 AM EDT
Leave a comment | View Comments (0)

The Cloud as a Metaphor

2010-06-22T14:52:19.435-04:00

The term "cloud" is appearing everywhere recently. It is an interesting phenomenon, since hosted computing, remote computing and shared computing have been around for as long as I have been in technology (don't ask!).

So as we all rush to brand our services as cloud services, I became interested in how many different types of cloud metaphors have been used. I tripped across a blog by Lenny Rachitsky where he identified the 7 most used cloud metaphors. He identified weather patterns such as "partly cloudy", "dark lining", "dark side", "bursting", "rain", "clearing the air", and the always optimistic "silver lining".

Have a look and enjoy it.
Posted by Bill Hayduk on Tuesday, June 22, 2010 2:51 PM EDT
Leave a comment | View Comments (0)

Don't be that guy

2010-06-17T15:54:16.361-04:00

Speaking of social, I am sure that if you have not been hiding under a rock you have heard of Chatroulette (no link; if you're at work, you can thank me later). The 17-year-old creator had this to say about the phenomenal growth of his site:

<blockquote>Each time the user count grew, I had to rewrite my code completely, because my software and hardware couldn’t handle it all. I never thought that handling the heavy user load would be the most difficult part of my project.
from Brad Stone's New York Times weblog, by way of Andy Baio</blockquote>

Imagine having to re-write your whole architecture from scratch each time you want to scale to the next level. That may be fine for a one- or two-page site, but think about your own infrastructure, and how much an entire re-write would cost you. Andrey Ternofskiy is 17 years old. What's your excuse?

Posted by R. Allan Baruz on Friday, March 19, 2010 3:51 PM EDT
Leave a comment | View Comments (0)

Building a Community Site

2010-02-23T13:58:50.688-05:00

Jabber, jabber, jabber. People love to write and talk; it’s inherent in human nature that a person who experiences something will want to talk about it. The web facilitates that by massive connectivity and relative anonymity, and finding people who want to talk about or listen to your interests is now easier than ever before.

At a recent panel discussion about social media, there was much discussion about the features that make or break a social site. Foursquare and Facebook Connect, and how to best leverage (or avoid!) the tools and buzz of "social," seemed to be the reigning topics of the night. However, everyone on the panel agreed on one thing: you must have a specific purpose in mind before implementing social features.

For site builders, it's a hard question to ask of a client: "How do social features fit into your business strategy?" You may lose the client if they reconsider adding these features. But if your client implements "social" to keep up with the Joneses, the Facebooks, and the Buzzes, they will not succeed. Even a minimal reconsideration of the role of social features can be the difference between "What a site!" and "What's the point?"

No one could really define the killer features that allows a site to build a community. They discussed the massive growth of Facebook, the civility of Metafilter discourse, and the seeming implosion of Myspace and Friendster. (Who?) The good and bad of letting people comment on a site--a lot of ambivalence about comments. But what features made a social-oriented site grow, or die on the vine? Rather than deal with how or why, the panel began focusing on the pragmatics of the tools.

The philosophical tech addict will still ask: why?

It came to me leaving the discussion: Site builders don’t create the community. The most you can do is provide tools, structure, and resources that facilitate a community coming together; the best you can do is make those tools and resources seamless, intuitive, and accessible to whatever community you plan to support. I'm not saying that you can't give a little nudge here and there, or, if you're into the gardening metaphor, pruning the conversations where necessary. Put out those tools, let everyone know what's fair and what's unacceptable, and then step back and let it grow.

Because a community either defines itself or is biding its time until it can disband.

Posted by R. Allan Baruz on Tuesday, February 23, 2010 1:46 PM EST
Leave a comment | View Comments (0)

What a Game!

2010-02-17T15:04:01.240-05:00

Two of my greater passions in life are technology and sports. The way technology is evolving constantly changes the manner in which sports come into our lives. Between following the game on our blackberries and recording with DVR systems, there is almost no excuse for missing any of the action.

Why do I love sports so much? A sporting event is the ultimate reality show. They were reality shows years before reality shows existed. No actors, no yelling “CUT!” no do-overs. What you see is what you get. Entertainment in its purest form.

That brings me to this year's Super Bowl. Watched by over 106 million people worldwide, it is the most watched television program EVER. This was a great football game as well as a spectacular display of technology. The way we watch the Super Bowl keeps getting more and more amazing. This Super Bowl was being filmed by more than 50 HD cameras (http://bit.ly/cX2R3L ) and that is just the tip of the iceberg. I am sure cameras in the stadium for both still and video photography numbered in the hundreds of thousands, if you include all the mobile devices.

The question that is always raised is “How can it get any better than this”? Every generation is more advanced than their predecessors. Many future enhancements cannot even be fathomed right now. We have every slow motion replay, from every angle, not to mention the on screen animation that we hardly notice anymore. Seemingly, every technological and communication need is being met right now.

What more can be done to enhance the experience? This question is shared by technology enthusiasts as well. When I first had a 128 MB thumb drive in my hand I thought that nothing could be better. Or remember the first time you loaded software from a CD? We were going from 1.44 MB floppies to 650 MB CDs! You looked at both and thought “There are 450 of those in there?”

That is why we stay tuned to advancements in technology as it relates to any industry or walk of life. It helps satiate our curiosity and continually answers the question…What will they think up next? For their 10-year anniversary with the company, RTTS gets all employees a Movado watch. Maybe I’ll be able to watch the Super Bowl on it by the time my 10 year comes around.

Posted by Joe Brandsdorfer on Friday, February 12, 2010 12:30 PM EST
Leave a comment | View Comments (0)

Software Testing New Technology: The "Eyes" Have It

2010-02-01T12:58:31.628-05:00

Time Magazine has just published an article titled "Are Face-Detection Cameras Racist?" which is pretty interesting. The article centers on face detection technology which is turning up everywhere in the current hardware market, from digital cameras to computer security, and problems with the technology dealing with different racial groups. I am certain that there is no shortage of opinions as to why this occurred, but I have my own to share here.

After reading the article, I have to admit that it's nice to see a technology story that gets to the heart of the issue; that adequate testing was probably not conducted on this feature before moving it to market. Testing for this feature was probably relegated to the end of the production cycle, so it took the hit when time or resources became an issue. Since this is a hot, new feature, there is the inevitable urge to get the technology into the product and to get it into the hands of the consumer ahead of the competition. That is a pretty basic idea and there is always a certain amount of risk present in that situation, but at this point in history, when the internet makes it possible to register consumer disgust on a global scale in minutes, it may be worthwhile for a company to reevaluate how to mitigate that risk.

One way to correct this is with a well-planned and dynamic testing effort that is started well ahead of the completion of the feature, shortly after (or possibly during) the initial planning phase. Moving away from the Waterfall Model may still be difficult or hard to grasp for some companies, but if you are looking for solid evidence that indicates why this model is flawed, look no further. Moving the testing phase further up in the development cycle (in addition to making it an iterative, traceable process) enables defects to be located earlier in the development lifecycle and rectified at a smaller cost. Organizations that choose to do so may be able to improve overall quality, cut costs, and save face…no matter what racial makeup that face may consist of.

Posted by Steve Hamilton on Wednesday, January 27, 2010 10:56 AM EST
Leave a comment | View Comments (0)

Software Development Goes Agile

2010-01-27T11:32:50.690-05:00

Change is in the air, and it is everywhere. The recession has caused companies - from the enterprise to small firms - to re-evaluate the cost of hardware, software and to look for efficiency of processes.

Back in the day (I am familiar with current 'young people terminology'), we were all taught about the software development life cycle (SDLC), which was a euphemism for the Waterfall process. Big and cumbersome, extreme in documentation and low on flexibility, the Waterfall was perfect for developing on the mainframe (or so people believed) for operational software targeted at internal use. They applications changed little and their functional direction was driven by the "powers that be".

Then came client/server technology and the iterative process, where the mantra was "code a little, test a little" and where the dominant process was the Rational Unified Process (RUP), led by the Three Amigos at Rational Software - Grady Booch, Jim Rumbaugh and Ivar Jacobson. Incredibly innovative, incremental and highly automated, RUP focused on both the management and technical perspectives of software development. While revolutionary in its approach, RUP was still a very bloated process that required much training and documentation (vision doc, use cases, etc.) and provided much more information than most projects needed, and required a 'pick-and-choose' effort by the software team to decide which parts of RUP they would use and which would get discarded.

With the advent of wide-spread use of the web (especially now with web 2.0), many applications are client-facing and require shorter product cycles and multiple releases. This has led to the 'age of Agile' or adaptation of the light-weight processes such as Extreme Programming (XP) and Scrum. Around since the 1980's, Agile methodologies have really taken off in the Web 2.0 age, as the highest priority is to satisfy the customer through early and often delivery of software. Characterized by requirements written on post-it notes, short, daily 'scrum' meetings and 2-4 week 'sprints' or releases, the Scrum methodology works extremely well with SaaS-based applications that need to constantly improve their offerings to stay relevant.

I recently read about an interesting survey of 900 developers in InformationWeek magazine. Some interesting statistics:

- 45% of developers who say they use a formal process use some form of Agile (Scrum is the most popular)
- 20% of Agile developers say it's a key part of their success (as compared to 12% of those using iterative and 8% of those using waterfall)
- 27% of developers using Waterfall feel this methodology creates a significant amount of busy work (as compared with 2% of Agile users)

We currently use a version of Scrum internally to develop our software and have found that as we get more familiar with the process and modify it to suit our needs, we are becoming more efficient at producing builds that are targeted towards our clients' needs than we were before. And as we speak with clients, we find that more and more of them are adapting an Agile methodology for their software development efforts. It is quickly beginning to dominate the landscape.

What are your thoughts?

Posted by Bill Hayduk on Tuesday, January 26, 2010 12:25 PM EST
Leave a comment | View Comments (0)

Light at the End of the Recession Tunnel

2010-01-26T14:42:30.362-05:00

2009 was a difficult year. However, this recession does have some similarity to others I have experienced. With unemployment still over 10%, this one may not be over, but there have been signs of a light at the end of the tunnel.

The past quarter was very hectic for our sales team. Fortunately, for the first time in a year, we had engagements for every one of our Test Engineers and a few even juggled a couple simultaneously. Regrettably we even had to turn down a few opportunities, but this was better than having more resources than assignments.

Last week we hosted a booth at a college career fair for the first time in over a year. During the last recession, it was two and a half years before we started recruiting again. The college was expecting 3,500 candidates, however, 3,800 job hunters attended. We collected 120 resumes and some of the students had excellent credentials. If the recovery continues, we will probably hire a number of these June graduates.

And the stock market continues to climb. With the Dow over 10,600, NASDAQ over 2,300 and the S&P over 1,100 on January 13, 2010, they are all higher than they were a year ago (Dow around 8,200, NASDAQ around 1,500 and the S&P around 840). Hopefully these indexes will be leading indicator like they have been in the past.

Every downturn I have lived through has been followed by an uptick in business and healthy recoveries. Lets hope this happens again and that 2010 will be a great year for everyone.
Posted by Ron Axelrod on Friday, January 15, 2010 11:15 AM EST
Leave a comment | View Comments (0)

Software Development Goes Agile

2010-01-26T12:26:08.581-05:00

Posted by Bill Hayduk on Tuesday, January 26, 2010 12:25 PM EST
Leave a comment | View Comments (0)

Business Intelligence Goes Mainstream

2009-09-17T13:28:53.387-04:00

The ‘new new thing’ that is growing at a rapid pace is Business Intelligence (BI). It’s white hot and all of the big boys in enterprise software are racing each other to get there. IBM bought Applix, Cognos and SPSS and is incorporating these technologies (specifically the Cognos engine) into its’ other software brands. SAP bought Business Objects and is doing the same. Oracle bought Hyperion. SAS Institute built its business around it and Microsoft is big into BI. And HP is doing a dance with Informatica, as seen in their recent partner press release.

According to Wikipedia, Business Intelligence (BI) refers to technologies (and people and processes) used to help a business acquire a better understanding of its commercial context. BI really started in the realm of data warehousing and data marts, but is moving rapidly into any data store that can provide critical information to your business. We have already seen this upfront and personal, with IBM’s new Rational Insight product, garnered from the Cognos purchase, already making its way into products like ClearCase, Rational Quality Manager and MS Project, along with XML data sources.

So why now? What is driving this? That’s easy. Businesses are always looking for real-time information that can consolidate metrics and provide analytical data that make it easier for them to determine the direction they take, and thus, provide a competitive advantage. And in the past, most software vendors were pretty poor at performing this task. Ask anyone using enterprise tools what they think of the reporting and analytics and they will roll their eyes, curse and then tell you about the cool stuff they have done in Excel. Well, that’s all about to change. BI is rolling out to an enterprise tool near you and your competition is either getting ready to utilize this information or already is using it to gain a competitive advantage. So either get on the wagon or get run over by it. Either way – it’s (main) streaming down the road….

Posted by Bill Hayduk on Thursday, September 17, 2009 1:28 PM EDT
Leave a comment | View Comments (0)

Paintball: the Ultimate (Software) Team Game

2009-09-16T11:39:38.856-04:00

Recently I played in my sixth Invasion of Normandy paintball event at Skirmish USA in Jim Thorpe, PA. The Sporting Goods Manufacturers Association estimates that over 5.4 million people played the game in the United States in 2007. It is the wildest, most insane and self-indulgent thing I do. One of my brother-in-laws talked me into this in 2004 and I have not missed one since.

It is a re-enactment of D-Day and the landing at Normandy that starts on Saturday and ends on Sunday at 1:00 PM. This year 3,500 paintballers played (several hundred more would have played, but they have to limit the number due to the camping facility and infrastructure). Half represent the Allied forces and the rest the Axis side. It is a true team sport where you depend on your comrades to cover and help you, not much different from our test teams at RTTS.

At noon on Saturday the Allied forces are placed in plywood replica troop carriers and all of the Axis players are over 100 yards away in the woods. Once a siren sounds, the plywood door drops and you, along with 100’s of teammates race out to face thousand of paintballs flying through the air. If you don’t immediately get a face full of paint, you spend the next 45 minutes trying to break through the tree line by sprinting from pallet to pallet, barrel to barrel or mound to mound just in front of the tree line. The fun lasts until you run out of compressed air or pods filled with paintballs or until you can’t stand from exhaustion.

This year was the first that I got to experience breaking through the tree line with my teammates. It took a trip back to our camp site for my group and I to reload and rehydrate and about a dozen direct hits to my body.

And it is rewarding to win the battle. Teammates (who you've never met) must come together as a group and support each other, communicate through verbal and non-verbal ways and ultimately work towards and achieve a common goal. In the end, it's just like our software teams!

After the first battle, which lasts a couple of hours, is won, the rest of the event is free-format. You insert at one end of the field and roam around until you find a fight to engage in. There are no rules to the free format except when it hurts too badly you leave the field of battle. My favorite part is making an enemy player run away or when I hit them so badly they raise their gun and retreat. Of course there is a price to pay and sometimes I was the one running away. Although I had over 50 welts and I could barely walk on Monday morning, I can’t wait to do it again next year.

If you would like to learn more about this event visit www.skirmish.com or visit http://www.youtube.com/watch?v=tMJRkT4QGbg to see a video of the fun.

Posted by Ron Axelrod on Thursday, August 06, 2009 9:50 AM EDT
Leave a comment | View Comments (0)

Wide-banding Issues for a Better Project

2009-09-16T11:19:43.778-04:00

Recently my mother in-law to be decided to inform me of a new security exploit. As I listened to her and gently reminded her that my professional background might cover something of this nature, I began to think. I thought about that fact that here was a woman that did not have any involvement in the field of IT security and may have requested that I “put the internet back on [her] desktop” one or more times. All said, she is a wonderful woman and, as we all know, the domain of application/internet users is varied (not everyone can be a superuser). The point of my bringing up this story is related to the release of software issues and their resolution.

With the Black Hat Conference and Def Con (two of the most famous hacker/security conferences) having recently convened, security issues ranging from SSL exploits to high-security lock breaking have made it into the mainstream media. And in reality, the release of security exploits and vulnerabilities to a public audience can be the primary goal of hackers (notoriety, financial gain, and the simple joy of accomplishment are some other goals). “Wide-banding” (a term taken from a William Gibson story meaning to broadcast information to anyone and everyone that will listen with the goal of giving everyone ownership instead of just a privileged few) a security hole can sometimes be a very efficient way to get it fixed and let users know what risks they may be incurring.

So, since my mother in-law and hackers are two mutually exclusive groups, what is the point here? The point is that this model for defect reporting may have some promise, not only for security issues, but for other areas of software testing. Letting all members of the software development team know about issues and defects can be helpful:

More attention is paid to well-known issues
More ideas for resolution can be solicited from the group – think of the Kaizen and Hansei elements of the Toyota Production System which speak to improvement in the process and the organization
Increased sense of project ownership for all team members
Allows for the creation of contingency plans – since not every problem can be avoided, planning what to do when trouble strikes can be crucial
Easier risk assessment – problems can be overemphasized/underemphasized by individuals that don’t fully understand them. Getting more eyes on the problem can also mean getting the right set of eyes on it.

To clarify, I am not suggesting that security issues or defects found in a project should be broadcast to the public or even every person in the office. That is not always a good use of resources and would frequently violate a slew of corporate confidentiality agreements. Instead I am advocating a “broadcast of issues” to the entire project team. Getting the word out allows the expertise and resources of several individuals on the project to be drawn upon for a solution. Utilizing this “team of resources” can frequently speed the resolution of issues and consequently add up to real savings in many areas of the project (opportunity cost savings, monetary, time).

Posted by Steve Hamilton on Saturday, August 29, 2009 11:15 AM EDT
Leave a comment | View Comments (0)

Software Testing is Cool

2009-07-31T15:46:14.163-04:00

Software testing is one of the least considered career paths in the SDLC (software development life cycle). Albeit the least considered, in my opinion it is one of the most rewarding.

I have been in the QA game now for ten years, and it is a constantly revolving and challenging career. Since I work for a professional services firm, I get to see applications being built in different and evolving industries. One of the great things about working in different industries is that you gain and absorb business knowledge pertinent to those industries. Personally I have learned the internals of reinsurance and prime brokerage. Along with learning how different industries work, I have also had the opportunity to learn different tools in the QA/application lifecycle management (ALM) arena. When I speak of tools I am referring to automation (capture/playback) and requirements/defect tracking (metrics gathering) . Some examples of these tools are IBM Ration Quality Manager, Robot and Functional Tester, and HP's Quality Center and Quick Test Pro.

Test automation tools not only speed up the execution of test suites, they also foster development skills. So, being a QA Tester could more often than not mean having development/programming expertise honed using various automation tools. From my experience it is very fulfilling to code test cases and then watch playback (simulated user interaction) of an application I have been working on. Along with the satisfaction of watching the playback, I realize (1) how much time I save the client (increased ROI), while (2) eliminating manual execution errors. Those two aforementioned points add coolness to the arena of software testing.

What you do you think? Is Software Testing cool to you?

Posted by Homer E. Pope on Thursday, July 30, 2009 12:26 AM EDT
Leave a comment | View Comments (0)

Part I: Application Security, Milgram, and Confidence

2009-07-21T14:28:36.114-04:00

For my first blog entry, I thought about discussing automated testing, security software, or even the recent scene-stealing security breach of the week. In the end, I thought about the importance of a solid foundation and what was almost always the first chapter/lesson that I encountered when I was getting started with security and learning about hackers; social engineering.

If the term is unfamiliar, social engineering is the act of manipulating people to obtain a reward. Social engineering is basically a con (short for confidence game) which is set up in order to gain the victim’s confidence and capitalize on it. The real problem we see with social engineering is that a good con can sometimes render application safeguards useless when it comes to protecting an application. In short, it doesn’t matter how thick the castle walls are if your own people open the gate for the pretty horse chock full of men with swords.

There are several human traits that factor into social engineering, but I only want to focus on one of them in this posting and I will talk about another in my next posting (along with my thoughts on solutions – teaser, teaser, teaser!) For now, I want to discuss how obedience to authority can pose a problem. There are numerous experiments that demonstrate the lengths that obedience can be taken to, but my favorite is that of Dr. Stanley Milgram who showed us that sometimes a look of authority (and a white lab coat) is all that is needed to coerce people to do something they may not want to. A good social engineer can take this implicit obedience and use it against a victim and/or the company that they work for. They may not demand that the victim apply electrical current to another person, but they may use this obedience to gain access or acquire sensitive information.

Case in point; I used to work in a position that had me visiting several locations a day in order to perform on-site IT work. At these sites, I would almost always work in a wiring closet, secure area, or server room that was supposed to be protected and would require the help of some gatekeeper to access it…who was almost always nowhere to be found. Consequently, I found that instead of playing hide and seek with someone who was just going to grant me the access I needed after a spirited 45 minute chase through an office complex, a simpler and more effective method could be used. I learned that most people would not question me if I strolled through to the target area armed only with a look on my face that said “of course I know where I’m going”. I found I could even pull this off with an improved posture – shoulders back, back straight, head held high – and people would assume I belonged there, no questions asked. It was simply amazing to see where I could go if I walked around like I owned the place.

So in closing, think about how your organization’s security could be susceptible to someone posing as something they are not. Ask yourself how you might engineer exploits like this and think about the ways that they can be stopped. Next time, I will share another facet of social engineering with you and attempt to make suggestions that might help improve the security of your application.

Posted by Steve Hamilton on Monday, July 20, 2009 10:58 PM EDT
Leave a comment | View Comments (0)

technorati

2009-07-20T14:50:59.942-04:00

m3cbnt2wj9

Posted by Bill Hayduk on Monday, July 20, 2009 2:50 PM EDT
Leave a comment | View Comments (0)

Help Wanted: Certified Public Accountant - No Skills Necessary

2009-07-17T12:35:49.340-04:00

Jon Harris' most recent blog posting reminded me of many conversations that I have had with colleagues regarding software quality assurance as applied to automated performance testing. Jon’s blog posting questions whether programming skills are required for a successful automated performance testing initiative. It reminded me of how I always get weary when I encounter marketing campaigns or sales pitches for automated performance testing “solutions” that claim "No technical skills are necessary!", "Start testing your application within 30 minutes!", "Click, Record, Test, Done!", etc. These claims are very misleading and quite frankly undermine the perceived level of effort and qualifications required for value-added performance testing. How comfortable would you be if someone offered to do your complicated federal income taxes, if they simply had an electronic calendar in their hand? Would you feel comfortable with the claim that this can be done in 30 minutes? Heck, it takes a lot more knowledge than knowing how to use a calculator to submit that federal tax return and it certainly takes more than 30 minutes! So, simply having a tool accessible is not going to provide added value; it actually can cause more trouble (i.e. think tax audit). Education, training, mentoring, and experience will provide the foundation of managing a wide cross-section of varying income portfolios; it's not a one-size-fits-all solution. Even when software packages, such as TurboTax, are provided to streamline the process, there is almost always a unique situation that requires the tax preparer to adapt. So, what does this have to do with using tools, such as HP LoadRunner, IBM Rational Performance Tester, Microsoft VSTS, Apache JMeter, Micro Focus QALoad, etc.? It's just that; these products are all just tools. They become a solution when used in conjunction with an adaptive methodology that meets both the business goals of the target application and its technical requirements. And the combinations of business requirements and technical requirements are limitless and can’t be grouped into a single turn-key solution. Technical skills are necessary to manage constantly evolving technology and non-technical skills are needed to address the business requirements of the application. These are skills that don't come in shrink-wrapped boxes or an electronic download. And they definitely don't evolve in the time it takes for a Domino's Pizza Delivery. How can we start to dissuade this negative perception towards automated performance testing and set better expectations?

Posted by Matthew Adcock on Friday, July 17, 2009 11:07 AM EDT
Leave a comment | View Comments (0)

Test

2009-07-17T12:35:37.701-04:00

46mqcpsk3d
Posted by Steve Hamilton on Thursday, July 16, 2009 11:42 PM EDT
Leave a comment | View Comments (0)

The technology just crept up on us....

2009-06-30T08:30:47.279-04:00

I was at my younger son's baseball game the other day and the game was running a bit longer than usual. My older son called me with his cell phone to see when I was getting home, because I would be barbequing and he wanted to eat. My wife called me to ask me the same question. Also, one of my friends text messaged me to see how the game was going, as it was a playoff game and his son is in the same league. I also took pictures of my son's 1st at -bat and then filmed his second at-bat with my Blackberry Smart Phone so I could show it to him after the game. In between innings I browsed through my emails for work and then checked the latest score on the Yankees/Mets game.

Then it struck me - when did the technology of work and home life blend together? Did I miss it? I had been reading about convergence for a long time, but it just occurred to me that it happened in such a sneaky, unsuspecting way, that it had crept into every part of our lives. My kids listen to iPods and play every game system imaginable, my Tivo that I had suped up runs on Linux. We all have flat screen TVs evolved from computer monitors. My Blackberry had become a camera, camcorder, browser and game system. Co-workers can always find me at home and family and friends can always find me at work. Now our work and home lives have been hopelessly intertwined with the same technology. Life will never be the same – for better and worse.

Posted by Bill Hayduk on Tuesday, June 30, 2009 8:30 AM EDT
Leave a comment | View Comments (0)

Do testers need Programming Skills?

2009-06-29T12:40:27.467-04:00

Does the sun rise in the morning? Ok that's not fair unless I am more specific. I've been reading articles/blogs/opinions/comments, etc on whether testers need programming skills. All of these articles make sound arguments and all are logical and on and on. I agree that testing skills and programming skills are two totally different things and that a good tester may not necessarily be a good programmer (or vice versa). The context of all of these is in regards to functional testing. When it comes to performance testing, the answer must be that the tester has to have programming skills. They do not need to be a rocket scientist in the language, and I tell everyone who asks and who I teach, that they need to be proficient in string manipulation coding. Every tool I know and use has a programming language behind it (C, C++, C#, Java, JSP, VB, VB.NET, and a few proprietary). If someone came up with a performance testing tool that had artificial intelligence well enough to not need custom coding to get an automated transaction to work, they would corner the market. Just one additional skill that is needed in conjunction with programming expertise is the ability to analyze and find patterns. Without these you would not be able to use your programming skills to manipulate a server response to get what you need.

As usual, if you have any comments or anything to add, please feel free to do so.

Posted by Jonathan Harris on Thursday, June 25, 2009 2:27 PM EDT
Leave a comment | View Comments (0)

Second Class Citizens - Really?!?

2009-05-27T15:12:20.617-04:00

Every now and then, on testing blogs, forums, lists and in the workplace, I hear the classic tester's lament "why are we second class citizens?"

Get over it!

There are really only two possible scenarios, if you feel like a second class citizen as a tester.

First, there is the remote possibility that you are a highly skilled tester, who adds significant value to the project, yet you are not viewed as valuable as the developers. I've got news for you - if that's the case, it's time for you to move on to a place that will appreciate you.

Second, and more likely, is that you did it to yourself. I think we testers as a whole sometimes play the victim role. We got bad or no requirements from the BAs. We got code that did not meet the requirements from dev. We got no time in the schedule for proper testing from project management.

This "second class citizen" lament has been bugging me for a while. And I'm not the only one. Matt Heusser recommends critical thinking and asking the tough questions:

As an industry, we seem determined to complain that we are treated as second class citizens.

What do I think are the keys to getting first class?

Well, one place to start is the questions above.

Alan Page, however, takes a more hard line stance, closer to my own viewpoint:

What really bugs me (believe me, I've had to edit the "bad" words out of this rant more than once already) is when people change the meanings as an attempt to raise the value of test, or show that test "has a seat at the table", or is a "first-class citizen".

I have to tell you, I'm sick and tired of testers whining about not getting respect.

If you want respect, you have to give respect and you have to earn respect.

Well said.

Now, I will readily admit that, earlier in my career, testing was not as fun. Back then, I did encounter some "second class" scenarios, where QA was not taken seriously. On those early projects I had to fight hard to earn respect. Some of those projects certainly viewed test as a necessary evil. I can still hear the refrain "just QA it" from one assignment. To this day, I have not a clue what that is supposed to mean. However, those projects are few and far between nowadays. I cannot remember the last time a developer did not take me seriously. I have been an integral team member on a number of projects, collaborating with developers on test plans and execution. If you are smart and get things done, you will earn the respect of developers and management alike. In my opinion, the adversarial relationship between dev and test is more cliche now than reality. Am I saying that you will not encounter a developer who does not respect you? Of course not. As long as humans are involved, anything is possible. But while it is possible to come across a few people who do not respect test, if you feel there is some organizational or cultural bias against test where you work, it may be time to look in the mirror.

Second class testers, step your game up!

Are you holding up your end of the bargain and doing the necessary leg work before logging a bug? Are you researching the spec, digging through the app's log file to glean additional information, writing clear bug reports with impeccable repro steps as including detailed descriptions of what you were doing, what you expected to happen (should be) and what actually happened (as is)?
Are you keeping up on the latest testing techniques and technologies? Reading blogs? Writing a blog?
Do you exhibit a critical and questioning mind when it comes to your application's business domain and technology platform? Are you going through the motions with your testing? Or are you really trying to understand how this thing is built? I like the analogy, I want to attribute it to a thread on the software-testing yahoo group, of test to building/engineering inspectors. How can you test something you know nothing/little about?

Posted by Tom Eble on Wednesday, May 27, 2009 11:14 AM EDT
Leave a comment | View Comments (0)

IBM Rational Software Conference

2009-05-26T16:38:40.039-04:00

Saturday I am heading back to Orlando for my 15th or 16th user conference. The first was in 1994 and was run by SQA, Inc. Robot and Test Manager were the only products back then. In 1997 Rational took over and since 2003 IBM hosts the conference which features RQM, RFT, RPT, AppScan and dozens of other industry leading quality assurance testing tools.

RTTS will have a booth in the exhibit hall again and I am looking forward to Jeff Bocarsly's, RTTS Division Manager, presentation on Internationalized Testing with Rational Functional Tester.

I am looking forward to seeing everyone we have known for years and learning what is new from IBM. Hopefully it will be fun, but not as fun as last year.

Posted by Ron Axelrod on Tuesday, May 26, 2009 11:57 AM EDT
Leave a comment | View Comments (0)

The Advent of ALM Software

2009-04-28T11:48:33.367-04:00

Over the last 12 – 18 months, the application life cycle and accompanying tools have gotten much play and adaptation in the marketplace. And – it’s white hot.

Application Lifecycle Management (or ALM) is defined as the process of software development as an iterative cycle and is coordinated through the use of software products. ALM can increase productivity, improve quality, promote collaboration among teams in different locations, speed up the development and test cycles and decrease costs.

A lead analyst at one of the top firms recently told me that 55-60% of all development and test management is managed and tracked in Microsoft Office. Wow! As someone who has been on projects using MS Office primarily as the asset tools, implementing these ALM tools should REALLY improve communication and information sharing along with providing reporting across assets. Welcome to the new millennium!

Typical ALM suites are typically role-based and provide software for requirements, transaction/use case/user story definition, project management, development management, change management, test management, defect management, metrics gathering and analysis, monitoring and reporting, and role workflow and methodology. An ALM tool may have some or all of these features.

One of the first ALM tools that we used was Test Director from Mercury Interactive, now part of the Quality Center suite at HP. Originally geared towards testers and now with a refocus towards business analysts and developers, Test Director provided a view of ALM through a quality prism and provided a central data store for requirements, test cases, manual test runs and defects with a distributed architecture (i.e. web) for the new distributed software dev teams. It was (and is) easy-to-use, web-based and provided a great central information area.

Other enterprise players that have joined the game include Borland, Microsoft (with its Visual Studio Team System), Seapine and MKS. Now IBM has joined in with its Jazz platform (Team Concert for developers, Requirements Composer for BAs and Quality Manager for testers). I would not be surprised to learn that Oracle is either developing (less likely) or looking to purchase (more likely) an ALM tool to compliment it’s entry into the development and test space with its tools for dev and test acquired from Sun and Empirix respectively.

And there’s more. The small and medium sized businesses have their tools to chose from. There is Artisan and Lighthouse and Rally and others. Not to mention TOMOS Software, which just won Gartner’s “Cool Tools in Application Development 2009” and is a SaaS based solution (and was incubated here).

So this movement by the vendors of dev and test products in this direction is good news for all of you practitioners out there who have struggled aggregating information and tried to make sense out of all the information that is needed to determine the progress and health of an application under build. Now all you need to do is pick the right tool for your needs and get going and you’re on your way to a more efficient software process.

Please comment if you are already using an ALM tool and let us know what you think of it!

Posted by Bill Hayduk on Tuesday, April 28, 2009 11:48 AM EDT
Leave a comment | View Comments (0)

Getting It Right The First Time

2009-03-13T12:23:49.069-04:00

When Microsoft released Visual Studio Team System (VSTS) 2005, I was excited to take a look at the new web testing component. Over the past 20+ years, I have used most of the performance testing tools on the market, so typically I first look at the basic functionality; how to record, how to playback and what numbers it gives me. I was pleasantly surprised at the ease of use and depth of functionality I found. The only awkward feature I mucked around with was pulling data from external files (datapools). The setup of this was not straightforward. The newest release, VSTS 2008, makes this task simple and very straightforward, so kudos to that enhancement. RTTS has performed numerous highly successful engagements utilizing VSTS because of its rich feature set and the price is attractive for clients. I am looking forward to the next release in 2010.

For anyone out there using VSTS, how do you like the tool?

Posted by Jonathan Harris on Wednesday, March 11, 2009 11:52 AM EDT
Leave a comment | View Comments (0)

Building a Reliable Scripting Framework

2009-02-12T14:49:22.832-05:00

Every performance engagement I do is both unique and repetitive. Unique in regards to a new application in a new test environment. By new I mean that it's different from any other test I've done before, even if some or many of the components are similar. They are brought together and used differently from site to site. By repetitive I am referring to the methodology I use to get the job done. Even though the process is the same, the details of getting the tasks completed change.

In every engagement I do, during the scripting phase when I create the automated test scripts, I automatically think of ways to make the scripts robust and reliable. Robust in the way it is scripted so that if changes are needed, it would have the least amount of impact on time and complexity to make the changes. Making the script reliable means handling known and possibly unknown conditions that would otherwise hang or stop the user. There are other factors in making a script reliable as well, such as after detecting issues having the ability to report on them. This way you can roll it back into the reliability of the script for next time it occurs.

This is something I have been doing for a long time, but recently put a name to it; a "Reliable Scripting Framework." Here is an example. Let's say you are testing a Citrix application and there are issues when running large numbers of virtual-users from a single test driver. This has something to do with the ICA middleware not being written to support many connections from a single machine. Sometimes typed characters get lost. This can cause the script to get an unexpected response. You have two options: (1) add code to detect that something went wrong and attempt to correct it, or (2) add code to test that what you typed was correct and avoid the error in the first place. Both approaches are acceptable, but it would take less thought and code to avoid the problem in the first place.

Here is a second example. In web testing there are times when a request fails intermittently due to a network or application glitch. If you try the same call again, it works perfectly. Though these are serious issues to attend to, when you performance test, having the ability to report on the error and retry would be nice. In most test tools you need to handle this yourself in code. If you do not explicitly handle it you may end up getting cascading errors which muddy up the waters when you try to analyze what happened. So putting a framework in place to handle something like this would make the script robust and more reliable.

If you have any form of scripting framework you use, I'd like to hear about it in the comments. Take a look in the near future for a whitepaper I'm writing about creating a Reliable Scripting Framework using these two examples.

Posted by Jonathan Harris on Wednesday, February 11, 2009 2:21 PM EST
Leave a comment | View Comments (0)

Rational Performance Tester Tips for use with ITCAM

2009-02-04T12:12:15.748-05:00

I've been using IBM Rational Performance Tester (RPT) since it was the Prevue tool long ago. I've used it in many ways, outside of the box, so to speak, for things other than performance testing. One of those things is for monitoring, specifically for production monitoring to verify the target system(s) are up and running correctly. Currently I am involved in an engagement utilizing IBM's ITCAM (IBM Tivoli Composite Application Management) product. As part of its use, we are creating RPT tests (tests is the term used in RPT for automated scripts). For those who may use ITCAM in the future, here are a few up-front working tips.

(1) After creating tests in RPT, you upload them to ITCAM. ITCAM will only see tests located in the root directory of the project, so you must place the final working versions there.

(2) ITCAM will only see custom code located in the "src\test" directory, so make sure you keep them in this default location.

(3) ITCAM does not currently see additional Java classes you create and import into your custom code (i.e. utility/reusable functions). You can get around this by creating a new custom code file and adding it to the beginning of the test. Don't add any executable code to the "exec" function. Place all of your utility functions after the "exec" function. ITCAM will now upload the custom code and since it is located in the default "src\test" location, you do not need to "import" it into the other custom code you create.

I hope this helps some. If anyone has similar tips regarding RPT use in ITCAM, please feel free to share in the comments.

Posted by Jonathan Harris on Monday, January 26, 2009 12:02 PM EST
Leave a comment | View Comments (0)

Vote!

2008-11-03T10:24:12.925-05:00

November 4 is just a few days away. What I cannot believe is that during the last presidential election only 59.6%, or 122 million people, voted (out of 204 million eligible voters).

As a result of low voter turnout in 2004 and previous presidential elections, the United States is ranked near the bottom of 172 countries in terms of voter participation rates (our ranking is 139).

We talk about freedom and liberty but we do not take advantage of one of the greatest privileges we have.

So while I am a huge supporter of one of the candidates, I do not care about who you vote for, I just am passionate that you VOTE. Get up early or leave work at 5:00 for once or file an early voting form, but most importantly find an hour during the day where you can cast your vote. It will make you part of the process and it does make a difference, so get out there and VOTE!!!!
Posted by Ron Axelrod on Friday, October 31, 2008 5:07 PM EDT
Leave a comment | View Comments (0)

Plan for Success the NFL Way

2008-10-20T11:35:24.265-04:00

For the last couple of years I have been coaching NFL-sponsored 5-on-5 flag football for my younger son (who is 8). In the first 2 years, coaches were allowed on the field, which made it easy to diagram plays in the huddle that made sense to 6 and 7 year-olds. This year, since we moved up a division to 8-10 year olds, the coaches must call plays from the sidelines. That made the visualization of diagramming plays on a hand-held whiteboard impossible, what with only 30 seconds in between plays.

So utilizing my background in software, I created a Plan, a strategy document that provides visualization of what we were trying to execute. I started by first providing a visual of each pass route (i.e. ‘square in’, ‘post’ or ‘button hook’) and the showed different formations (‘trips right’, ‘twins left and running back back’ or ‘stack back’) and then combine the formations with the pass patterns to form a play. Now everyone understands what we are trying to do and is on the same page (even 8-year-olds!). And during the game we strategize to call plays that will produce the results we are looking for depending our desired outcome and calculating the risk involved for each play (i.e. interceptions).

If this works for 8-year-olds, why not for software testing? This is no different than creating a Test Plan, or strategy document, that outlines the approach to testing, the strategy utilized and the expected outcomes, depending on the risks (security, usability, performance, etc.). Yet I constantly observe that software projects do not have formal test plans that provide all participants (stakeholders) with the strategy (choice of plays), structure (plays and patterns) or desired results (first down or touchdown) of the tests. Believe me, if you want to be successful in developing and testing software (or in flag football), create a plan that keeps everyone informed.

By the way, we currently stand at 2 wins, 2 losses and 1 tie (we tied the only undefeated team) with by far the youngest team in the league. And everyone plays the same amount of time and everyone has fun. For those not familiar with organized kids’ sports, everyone sharing time and having fun is usually not a path to success (see ‘Kicking and Screaming’ with Will Ferrell about kids’ soccer). But with a plan, we’re getting it done. Good job, kids!!!

Posted by Bill Hayduk on Monday, October 20, 2008 11:34 AM EDT
Leave a comment | View Comments (0)

The Financial Services Mess

2008-09-23T17:09:10.032-04:00

What a mess. Mortgages were sold to people who couldn''t afford them by companies who sold them to other comapnies who resold them to firms who repackaged them to others who created new instruments and resold them and now no one can pay anyone and the entire US economy is about to come crashing down. Does that about cover it?

Some of Lehman''s assets, including 10,000 employees are being acquired by Barclay''s, which means 14,000 people will be on the streets. Bear Stearns is already a memory, with the employees scattered around other brokerages, hedge funds and smaller players. Goldman Sachs and Morgan Stanley are becoming banks to survive.

About once every 8 years Wall Street comes up with a new gimmick to make money and ends up shooting itself (and everyone else) in the foot. The junk bond scandal, the savings and loans, the dot com "new new economy" and now the sub-prime stuff.

Which means the brokerage industry that I grew up working in and with is no longer. A self-inflicted gun shot wound to the head - this time a kill shot. RIP Wall Street. You''ll never be the same. And you did it to yourself. Again....

Posted by Bill Hayduk on Tuesday, September 23, 2008 5:08 PM EDT
Leave a comment | View Comments (0)

Why is Software Quality Still the Poor Stepchild of Software Development?

2008-09-23T16:34:19.328-04:00

In the recent past, our organization reviewed the software quality planning for a very large, complex software implementation for a large organization. The implementation was being performed by a well-known consultancy, one which had successfully completed multiple such implementations in the past. The initial overarching project planning document was approximately 300 pages long; not more than 5 pages were devoted to testing and software quality.

Now, in all fairness, the document did refer to future planning tasks for testing cycles that were scheduled to be written. And some of them were, eventually.

The main point here, though, is one of emphasis. If, at the current stage in the maturity of the industry, software quality attracts so little attention at the beginning of a large project, and one implemented by a respected and successful organization, then it is clear that the case for investing in software quality has not been made to the industry.

Now, you might look at the recent history of the field, and conclude that all the companies that have been building their own software and have deployed with what, on paper, looks like insufficient testing, have “gotten away with it.” The economy has not faltered (at least, not because of software defects), and there haven’t been an overwhelming number of reports in the press about companies stumbling due to major glitches in their software. NIST, the National Institute for Standards and Technology, recently pegged the cost of inadequate software testing at $59 billion. Not chump change, but, you might argue, an acceptable cost in a trillion-dollar economy.

This is looking at it in the wrong way. Software quality investments should be looked at in the same way we look at insurance policies, because that is essentially what they are – mechanisms for reducing risk to the enterprise. Just as no individual can afford to drive without insurance because the personal risk is too high (even though society may be able to absorb the costs of the uninsured), no organization can afford to short on software testing – because the risk is too high. Anyone who views this from the perspective of organizational risk will “get” it – and the argument that the status quo has worked in the past falls flat from a risk perspective, because statistically, the longer one goes without a major failure, the likelier a failure becomes, not the opposite.

Posted by Jeff Bocarsly on Thursday, May 22, 2008 2:41 PM EDT
Leave a comment | View Comments (0)

Tools that make consulting a pleasure

2008-08-29T12:49:57.668-04:00

Over the years I have had many different laptop computers that I used on client sites. One of the nicer ones was a Dell Inspiron with a 15-inch screen and a 1600x1200 screen resolution. The drawback was it weighed over 10 pounds. In recent years I downsized my machines to a 12-inch screen with a 1280x800 resolution. I did this for a few reasons. First was that they only weighed about five pounds and second is that on my numerous plane trips I could actually open it up without having it pressed against my stomach; especially when the person in front of me reclined their seat.

Well, over the past year and a half I flew enough to attain platinum level status in the frequent flyer program for US Airways. I am getting upgraded to first class ahead of the hordes of gold level people. So I upgraded my laptop from a Dell XPS1210 to an Inspiron 1720. This baby rocks. It has a 17-inch screen with a 1900x1200 resolution. Here is the kicker; it has a full keyboard with a numeric keypad. It is a pleasure to use on client sites. I outfitted it with VMware so that I can create a virtual machine and load whatever tools I need in a matter of minutes, and when I'm done I just blow it away.

For added toys of convenience I found a USB powered network hub with four ports. I can't tell you how many times I was in a room with other consultants and there was only a single network cable. I also purchased a USB mobile battery to power USB devices (and my cell phone) and a USB fan and light. To round it all off I got a 320 GB mini drive. With all of this cool stuff I bought a rolling laptop case that also fits nicely on top of my suitcase for the airport (until I check my luggage). Now I have my sights on a mobile printer. I'm looking at a Cannon BJC85.

Does anyone have a BJC85 that can share their opinions of it? What about any cool gadgets or software?

Posted by Jonathan Harris on Thursday, August 28, 2008 11:46 PM EDT
Leave a comment | View Comments (0)

Recruiting Blunders

2008-07-07T09:44:48.011-04:00

Someone recently sent me an interesting article on recruiting blunders. It talked about candidates sniffing their armpits when walking into the interview room; receiving phone calls during the interview and asking the interviewer to leave the room so they could have some privacy; and other ridiculous errors that some candidates commit.

This reminded me of some of our most unusual candidates. While most of the candidates I have interviewed are excellent, some of them boggle the mind. Some are not only unprepared but they seem to speak without thinking. Many of the things they did or answers they gave were so off the wall that they just cannot be made up.

One candidate pulled out a 2-quart bottle of water and slammed it on the table at the beginning of the interview. Then every time he was nervous he would take a huge gulp and finish with a big “Ahh.” Another candidate asked where she would sit if hired. We showed her the cubicle and she said that would never do. Then she saw an office to her liking and asked if she could have that. I told her no, it is the President’s office. We also had a candidate that had greased up his hair with so much oil or gel that it looked like he had just come out of the shower. After a 45 minute interview his hair was still soaking wet.

One of my all-time favorite candidates had an interesting answer to a “tell us a little bit about yourself” question. Near the end of a long-winded monologue the candidate proudly boasted about being a very friendly and cheerful person whom friends have nicknamed, “The Cheerful Idiot.” Definitely not the best way to describe yourself to a potential employer.

We also ask the candidates what their strengths are followed by their weaknesses. One candidate gave us the standard answer for the former, but when we asked for weaknesses we were flabbergasted by the answer. First the candidate said they tend to be late, then said they lose focus when under pressure, then added they had trouble meeting deadlines and finally said they like to goof off from time to time. That candidate still holds the all-time record for weaknesses at four.

There have been other colorful answers from a plethora of other candidates. Some of the best are listed below:

Why should we hire you?
“I don’t know?”

Tell us about an event that really challenged you?
“That’s a silly question.”

Rate your self on a scale from 1 to 10.
“A 10.”

When would you be able to start?
“In a couple of months, I need to rest.”

Would you accept the offer?
“Only if I do not get a better one.”

What do you know about RTTS?
“Not much. I had to travel to get here and did not have time to look at you web site. I was hoping you would tell me what you do.”

Why didn’t you wear a suit to the interview?
“It was hot outside.”

Why did you major in Computer Science?
“I didn’t know what I wanted to do and my brother told me to try it.”

What is your strongest programming language?
“English.”

While many of the answers are very truthful and honest, they did not put the candidates in the best of light. But at least I have never had anyone smell their armpits.
Posted by Ron Axelrod on Thursday, July 03, 2008 2:58 PM EDT
Leave a comment | View Comments (0)

A View from the Road

2008-05-24T11:08:43.917-04:00

I recently went to 2 conferences: Software Test and Performance (in San Mateo, CA) and STAR East (in Orlando). I noticed an interesting trend at these shows.

There was the proliferation of new companies offering test-related tools that either competed with the big boys (HP, IBM, Microsoft, Borland, Compuware) or provided something in a different slant. Companies covering code analysis, security testing, application monitoring, test management, and traditional automated functional and load testing were everywhere. What this leads me to believe is that the software testing industry is still growing and thriving with new products that may be hitting the market under the noses of the primary players. It has always been the path of the big boys to see what the market needs, keep an eye on the new up-and-coming software firms and then swoop in and buy one to enter the marketplace (See HP's and IBM's acquisitions of SPI Dynamics and Watchfire last year in the application security testing space). The IPO is dead thanks to Sarbenes-Oxley, but the targeting of a takeover is the new way for these ISV's to get to the end game.

We are entering the age of relevance of the Tester. Since the adoption of the agile processes (XP, Scrum, etc.) and the slow death of the waterfall process, Testers are finally getting a seat at the table of IT. So, as application lifecycle management (ALM) adds the quality component, that means more focus on the Tester role and more tools to make that role successful.

All in all, the Tester and the tools for the Tester are at an all-time boom. Enjoy new-found respect, job stability and growth, you previously unappreciated toilers of software!

Posted by Bill Hayduk on Monday, May 19, 2008 1:21 PM EDT
Leave a comment | View Comments (0)

A View from the Road

2008-05-24T10:59:44.120-04:00

I recently went to 2 conferences: Software Test and Performance (in San Mateo, CA) and STAR East (in Orlando). I noticed an interesting trend at these shows.

All in all, the Tester and the tools for the Tester are at an all-time boom. Enjoy new-found respect, job stability and growth, you previously unappreciated toilers of software!

Posted by Bill Hayduk on Monday, May 19, 2008 1:21 PM EDT
Leave a comment | View Comments (0)

Not seeing the forest for the trees

2008-05-15T10:37:27.630-04:00

Seeing the bigger picture is an important skill in all aspects of business (and life). Many times I see someone performing a task a certain way over and over, while I’m thinking “Why not do it this way?” or, “If you do this part of the task this way once, the rest would be easier and repeating it would be more efficient.” What makes me smack my head and proclaim "Doh!" is when I'm the recipient of such advice. Sometimes when you are down in the thick of detail, you don't see the forest for the trees. In my last blog entry I talked about statements-of-work (SOWs). Because creating them is a significant component of my work, here is one head-smacker to add; and by the way it also falls under the heading of Evaluation and Improvement, both part of the RTTS methodology (Doh! times two).

Usually, after creating and submitting the SOW we have a follow-up call with the prospective client to discuss the document. We seem to always get into a conversation on process, needs, requirements and tools. Even though I enjoy talking about performance testing and tools, it would probably be a good idea to include an explanation of the previously mentioned topics within the SOW itself. For example, regarding process, describe the steps and artifacts; what is involved, setup and requirements, etc. Since there are a number of performance and scalability test tools available, the SOW could include a generalization of what the available tools are; how they work; and what they can and cannot tell you.

Fitting title for the subject. Have you had any head smacking Doh's lately?

Posted by Jonathan Harris on Monday, April 28, 2008 5:19 PM EDT
Leave a comment | View Comments (0)

Following Directions and Asking the Right Questions

2008-04-23T12:20:42.595-04:00

I write quite a few Statements of Work (SOW); some call them proposals and I'm sure there are a number of other terms as well. The RTTS format I follow fits perfectly with its intended response; acceptance by the client or winning the project in a competitive situation. I take the client’s information and requirements, sift through them for relevance to the project at hand, and match the details against what can and cannot be done with automated performance and scalability testing. When communicating with potential clients and putting together the SOW, there are two aspects that must be covered even before getting to the “how long” and “how much” part. The first is that we understand their business motivations and have the methodologies in place to address them successfully. The second is that we understand their technical requirements and have the tools, skill sets, methodologies and a plan to successfully address them. However, I have found that not all companies maintain relevancy to the project at hand.

Recently, a prospective client issued a Request For Proposal (RFP) and supplied quite a bit of information regarding the testing environment, the application, business transaction volume requirements, expectations and instructions on what to include and exclude from the proposal and strategy presentation. Following the initial RFP was the opportunity for all responding vendors to ask questions. The unusual part, or at least out of the ordinary as I have not had this occur before, is that all of the questions and their answers were combined into a single response document and returned to all of the vendors. I believe this was in response to one of the questions asked by another vendor asking for access to all of the questions and answers (maybe to size up the competition, huh...).

After going through all of the questions and answers, I can surmise that there were maybe four or possibly five vendors involved. Some of the questions were duplicates that I had asked as well. Some of the questions, though valid, were coming out of left field from my perspective. One of the questions referred to additional services and tools when the RFP explicitly stated to include only tools and services needed to test the application. Another question asked for the procedure for reporting issues. As I can see it is an important point once the project starts, I cannot see its relevance in forming a testing strategy. One of the questions asked if the demonstration was against the client’s application. One of the requirements of the presentation was to do a demonstration of the tools selected for the testing with an overall length of the strategy presentation and demo not to exceed two hours. If you've ever performed a demo against a live application you have never seen before, it can take hours if not longer just set it up, not to mention the possibility of discovering the nuances of the script modifications needed to get it to play back correctly. There were a number of questions asked where the answers referred vendors back to information contained in the RFP. I can only guess whether the people asking the questions were testers or salesmen.

Anyway, from my perspective, it's all about decoding information, inferring, making educated hypotheses and putting together the best SOW possible. And, there are always good questions to ask, just make sure they are the right questions.

Posted by Jonathan Harris on Wednesday, April 23, 2008 12:04 PM EDT
Leave a comment | View Comments (0)

Code Coverage? Why do it by Hand?

2008-03-12T12:54:36.182-04:00

Code coverage is one of those items that is better done by computer, yet people still insist on doing by hand.

When it comes to code coverage – estimating how much of your code is exercised by your testing regime – there are a number of top-notch tools. There are commercial tools for most technologies and open-source or bundled tools as well (just Google “open source code coverage”). You might think that, with all the effort and expense that is put toward software testing, development organizations would use these tools to accurately measure what their testing efforts actually buy them.

Not so.

Relatively few organizations do so, even when the tool is open-source and the only cost of ownership is the cost of installation, training and administration. The reasons are many: “Oh, our BA’s know the application so well, they can fully cover it,” or “The developers are handling that with their unit tests…,” or “We’re not there yet; we’re waiting until we shore up our core process.”

Well, maybe. Some reasons are better than others. Few organizations actually invest in even checking out whether there is an appropriate coverage tool for the technologies they are implementing with, or, if there is, what the cost might be. Some do invest in code coverage tools, and then only use them to measure the coverage of unit testing, but not the coverage of Integration or System testing. (Or UAT for that matter.) It is another area where the engineering and technology are mature and available, yet most organizations don’t take advantage of it. It is another example of how technology is ahead of process by leaps and bounds.

Posted by Jeff Bocarsly on Thursday, February 14, 2008 4:43 PM EST
Leave a comment | View Comments (0)

Architecture vs. Design - An Artificial Distinction?

2008-02-07T12:20:07.439-05:00

I recently read a blog entry by Jason Gorman on "Architecture vs. Design - An Artificial Distinction?" where he talked about the scope of architecture and design being arbitrary and the meaning ultimately resides on your point of view. I agree 100% that almost anything is arbitrary based on your point of view, but being in the software testing arena, architecture and design are two totally different things. The distinction comes into play based on a timeline. In the beginning, software and systems are designed (conceptualized) as to what they are intended to do and what they are supposed to support. The architecture of these applications and systems denote their implementation. Many definitions of design talk about planning. Definitions of architecture talk about structure. It makes me think about the comic strip that came out many years ago where each cell in the strip shows the interpretation of a tree and swing by each of the producers.

As proposed by the project sponsor

As specified in the project request

As designed by the senior analyst

As produced by the programmers

As installed at the user's site

What the user wanted

From conception to delivery you never really know what you'll get. In the end in my world, the proof is in the pudding. Design is one thing, but what you end up with can be something entirely different. When I teach methodology, my definition of architecture is that it defines how components work, how they interact with other components and how we interact with them. Ultimately, architecture determines how well or poor a complete solution will work. There are so many ways to put today's technologies together and depending upon the circumstances, needs, resources, requirements, etc., a system with an elegant design may or may not be put into architectural practice to yield the best possible results. Again, my position on architecture and design is that there is a definite a distinction.

Now you know my position on architecture and design, what's yours?

Posted by Jonathan Harris on Wednesday, February 06, 2008 1:53 PM EST
Leave a comment | View Comments (0)

The Utility-Complexity Curve

2008-02-07T12:12:37.189-05:00

As applications are designed and developed, they typically start out with a minimal feature set that is sufficient to garner enough market share to make the product viable. Then, the feature set is built out, either in response to the original vision, competition, or both.

Initially, as features are added, the application becomes more usable, in exchange for a relatively modest increase in complexity to the user. At this point, the Utility-Complexity curve is on a steep incline – with each release, the app becomes significantly more usable, for a modest cost in complexity for the user. However, this game doesn’t last forever – as more features are added, the app continues to become more complex, but the utility of the app doesn’t change by as much – the features being added speak to too tiny a segment of the user population, or are too trivial. At this point, the Utility-Complexity curve peaks and the intuitive character of the app has peaked.

Eventually, as more releases are designed and delivered, the complexity continues to increase but the utility of the application actually declines, as “feature-clutter” sets in. Subsequent releases produce a tool that is incrementally less useful to the user. The Utility-Complexity curve turns over and starts to descend.

Why does this happen to good applications with well-considered designs (at least, initially)? It happens for perfectly good capitalistic reasons - the need drive revenue by continually releasing new versions with new features. How can you convince buyers to pay annual maintenance or upgrade to a new version if you’re just releasing bug fixes and no new features?

So, every new product is on a path from an initial good, intuitive design to a maturity in which the intuitive nature of the original design is violated, where the app becomes less usable with additional features. Vendors continue to add features well beyond the optimized design for their products, and the products become incrementally less useful to the user. I wonder if anyone has tried to calculate the loss in worker productivity due to this sort of feature-creep.

Think about some of the most common applications that you have seen released with significant re-design or enhancement, especially where the changes require a great deal of re-learning by users. Are users 100% more productive with the new application? 50%? 10%? Most likely not. They are probably no more productive than they were with the earlier version, minus the re-learning, which puts productivity in the negative. Why did the vendor do it? Just to have a reason for people and organizations to buy again, and buy more.

This applies across the board - some tools on the market today are hitting or crossing the Utility-Complexity peak. They started out with nice, minimal designs, making them very intuitive and useful products. The initial phase of releases filled out the functionality in areas where things were a bit thin at the outset, and with the addition of features, utility and ease-of-use continued to rise. Somewhere in the more recent releases though, these tools have peaked. The new stuff is just getting in the way. Which means competitors will just come on the market to start the cycle again…

What do you think? Do you agree with my observations and prediction? Or do you have a different opinion?

Posted by Jeff Bocarsly on Friday, February 01, 2008 2:18 PM EST
Leave a comment | View Comments (0)

You Get What You Pay For

2008-02-04T12:20:33.709-05:00

Over the holidays I ran into my neighbor at a party. I asked her why she switched her landscaper last summer. She said her previous landscaper was the least expensive one she found, but did not do the job well, in fact he was awful. Then she added sometimes you get what you pay for. I knew what she meant. Whenever I went for the lowest bidder on a home project, I regretted it.

The conversation reminded me of many of our clients that went with offshore solutions. In the majority of cases it was upper management’s decision to select an offshore consulting firm, mainly because of cost. While $20 per hour for resources was a common price (it has since increased), I had heard as low as $8 per hour. But most of the time these engagements ended in disaster.

One of the most memorable stories involves a client that asked their internal U.S. developers how much it would cost to develop a new system and the developers said five million dollars. The management team then went to an overseas outsourcing vendor and the bid came back at two million. They fired their developers and signed up with the outsourcer. Twelve million dollars later they had a partially built system that was a year and a half late.

I have been witness to quite a few other stories like this. For example, one client contracted two of our test automation experts. To save costs they also employed a dozen overseas consultants. The overseas consultants were instructed to create a specific number of test automation scripts in a two-month period. We were tasked with a similar workload. One week before the scripts were supposed to be run, the overseas group said that nothing was completed. When asked why, they blamed our Test Engineers and said we had not provided them with the proper information. Fortunately we were prepared for this false accusation problem because we had experienced it a number of times before. We had documented everything in emails, including the overseas management’s acknowledgement that we had sent them all the information they needed. They backed down immediately and agreed to work around the clock to fix the problem. Unfortunately this meant that one of our employees had to work 12 hours on Thanksgiving Day and another 13 hours the following Saturday, but with our help, the testing was successfully completed. The bottom line is the overseas consultants were not working towards completing their tasks until they were called upon to show their status. There was no return on their low cost.

We are not the lowest cost provider of software testing and we are also not the highest, but our clients tell us we are the best value for the buck. It is the main reason why a significant amount of our work is from repeat business - our clients say we exceed their expectations and they get more value than what they paid for.

Posted by Ron Axelrod on Thursday, January 31, 2008 3:53 PM EST
Leave a comment | View Comments (0)

Happy New Year! (Error Code 2048)

2008-01-31T18:25:00.115-05:00

I’m sure I am not the only one that brings my career experience into my daily non-work life. So, when I attempted to send several text messages to friends and family members shortly after midnight this past New Year’s Eve (12/31/2007), I was not surprised to encounter messages on my cell phone stating System Busy or Failed to Send Message. It seems that many of us in the larger metropolitan areas had the same idea at the same time and there was just not enough capacity to handle the volume of calls and text messages. So, it was at this point in the evening, over a glass of tasty sparkling white wine, and after wishing good tidings with my newlywed wife, that I had some thoughts pertaining to the technologies and challenges that I will probably encounter within the upcoming year, similar to a press release that RTTS distributed discussing similar concepts.

Here were some of my thoughts before resuming my social engagements for the evening:

RIA Rises - Rich Internet Applications using Web 2.0 technologies will probably make performance and scalability testing more challenging due to the dispersion of physical and logical data sources, the complexities that are now being pushed onto the web clients and the quick paced evolution of communication protocols, including SOAP, REST, JSON, and XML-RPC, amongst others. I don’t think that the Click-N-Test Methodology is going to be very effective in this arena.
Enter the Enterprise - Lately I’ve been seeing corporations creating Intranets that go way beyond the role of providing static documents. Intranets are starting to be integrated into the role of the business, providing process workflow, enabling access to corporate applications, establishing social networks, and facilitating collaboration via Wikis. If providing this functionality to a business with hundreds or thousands of employees, performance becomes a critical factor in determining the success of the application, the productivity of employees, and in some cases corporate morale. Again, applying the principles of Performance-Testing-In-30-Minutes-Or-Less will not work to one's advantage.
Meet the Mainframe - No, I don’t think that Mainframe systems are on the rise again. However, with the momentum of server virtualization picking up, the Mainframe paradigm is taking hold again. Server consolidation will mean that great care needs to be taken when establishing application capacity and assigning system resources to components that are going to share a physical platform.

So, if I had to sum up my thoughts, I would say that performance testing will become even more critical as business and technology continue to merge, and automated performance testing will become even more challenging as result of the increasing complexity of this generation of applications.

What are your thoughts pertaining to these technologies and challenges? Which other ones do you expect to encounter within the upcoming year?

Posted by Matthew Adcock on Wednesday, January 30, 2008 3:24 PM EST
Leave a comment | View Comments (0)

Educating the Business: It Ain?t Widgets

2007-12-24T12:41:27.359-05:00

The biggest communications failure in modern business is not between marketers and customers, nor between management and workers, nor between businesses and their partners or investors, nor between regulators and businesses.

The greatest communications gap is between business resources inside an organization and the internal software teams that build custom software to support them. I say that this is the largest communication gap in the modern history of business because:

· it is pervasive, crossing multiple verticals

· it encompasses nearly everything that modern business does

· it affects business decisions virtually every minute of every day

This disconnect between software development teams and the businesses they support is the 800-pound gorilla sitting in the corner of every meeting and every discussion that occurs between technical software resources and the business resources that depend on them. Business types are from Mars and technical types are from Venus (or the other way around, if you like). They are, too often, ships passing in the dark.

The essence of the miscommunication is that business resources are inclined to think of a software development group as a widget factory, and the technical side in almost every organization has utterly failed to educate their business sponsors about the true nature of the beast.

The Widget Factory

Business folks are, by definition, trained to look at the world as a set of chunkable, repetitious tasks – and they are trained to write project plans and budgets around numbers of tasks and subtasks, each with an estimated time associated with it. Once they have all the tasks listed, and the time estimated for each task, they magically have a cost estimate on which to budget a development project. This is not a bad way to think – it works for much of economic life – the whole manufacturing sector uses it, and it applies to any area of the services economy where tasks are completely well-defined and repetitive. Every widget factory, I imagine, has this sort of predictability associated with it, so the projects for Widgets, Inc. always come out on time and at budget. This could work for software development, in principle, except for one small problem: it ain’t widgets.

The True Nature of the Beast

Alas for everyone involved in software development, the development groups, the support staff, the managers, and the business users, software development is largely a creative activity that just doesn’t work with the widgets model. And this is the key point that software teams fail to convey to the business side, and utterly fail to educate their business colleagues about.

However, businesses must run on budgets, and so everyone on the business side expects that the software side can work in a regime of predictability just like they do. And because business is the sponsor, the software side doesn’t like to say “no”, or “let’s strategize on this”. Instead, everyone plays along, produces a project plan, a set of dates, a set of effort estimates, and off they go again. As dates begin to slip, and hours worked rise, and deadlines loom, the same tempers that frayed last time fray this time.

Is There A Better Way?

In the most concrete, practical terms – probably not. Businesses need to run on budgets and project plans. Software development will only require more creativity as technology progresses, not less. Neither of these will change.

The thing that can change – the education part - can make a difference. All parties, software and business, will benefit if both sides are more aware of the nature of each others’ domains. It won’t change the stress associated with delivery deadlines, or the vagaries of trying to build a project estimate. But it can create an environment of greater understanding between the two sides that will smooth the path when the going gets rough. And the burden of educating the business side about how software is built – that is on the software side.

Posted by Jeff Bocarsly on Monday, December 24, 2007 10:51 AM EST
Leave a comment | View Comments (0)

Dear Santa

2007-12-21T16:15:50.843-05:00

Since this is the holiday season and I am in the spirit, I figured I would apply a tried-and-true way from my childhood of getting my wishes fulfilled. With that in mind…

Dear Santa:

I was good this year (I think) and I was hoping you could help me out with my wishes. Below is a partial list. Feel free to use your infinite discretion.

1) A PC that does not freeze on me every other day. I know I have asked for this in the past, but no matter how many upgrades and state-of-the-art purchases I make, I still freeze up.

2) A clean desk. I know you did not mess it up, but whatever you could do to fix this issue would be greatly appreciated by me (and my co-workers).

3) Test tools that are way too complicated for people to use. Enough with the wizards and stuff in the tools. Give me tools that only consultants can figure out.

4) Vendor conferences at different times of the year in exotic locales. Why do all the vendors have them in May and June? And why in the desert in summer? How about the Bahamas in winter? That works for me!

5) While we’re on the vendors, how about deals with no paperwork. No more 50 forms and 22 acronyms inputted into 30 different systems. One email and that’s it.

6) Can you make cell phones with ear zappers? If you talk on the train/bus while others are around, you get zapped.

7) I need a “Guide to the Y Generation” book. What’s with YouTube, Facebook, MySpace, etc? Let’s force people to have to speak face to face, not Facebook to Facebook. (I should put that comment on my LinkedIn page).

8) Anabolic steroids and HTH for my Knicks. Hey - if it works for Bonds and Clemens, why not? They can’t be any worse.

9) While we’re on sports, how about blinders for my Dallas Cowboys’ Tony Romo? Every time he looks into the stands at Carrie Underwood and Jessica Simpson, he stops looking at T.O. and Witten!

10) A customer who would like a 10-year deal for as many people as we have.

11) A golf club that hits a ball straight. The ones I have bought all seem to be damaged.

12) A fantasy football season where one of my top guys does not break his leg (see Willie Parker and all of my other players over the past).

13) A fantasy tester game where RTTS people are picked in the first round.

14) Oh yeah. One more. Peace on earth and good will towards men (and women and children).

Thanks Santa!!!

Respectfully,

Bill Hayduk

Posted by Bill Hayduk on Friday, December 21, 2007 4:15 PM EST
Leave a comment | View Comments (0)

The Holidays Have Gone Plaid: Prepare for the Back-To-School Season

2007-12-21T15:35:22.484-05:00

Black Friday. Cyber Monday. Green Monday. What's next, Plaid Friday? I don't think I could ever slip in a reference to Spaceballs, but hey I'll try anything for a laugh, or two.

Anyway, it's been quite some time since my last entry, but it's not due to lack of eagerness. I have simply been engrossed in a couple of time-sensitive customer engagements, during which we assisted with holiday e-commerce preparations and an enterprise rollout of a Microsoft SharePoint solution. So, my free time has been costly and as a result this holiday season is rushing past me at ludicrous speed. And I have for the first time purchased all of my holiday gifts through online vendors. There are lots of reports out there publishing positive news for this 2007 Holiday Shopping Season and sales seem to be projected to grow by 20% when compared to last year's online purchases. I have heard of several e-commerce vendors that have experienced significant customer dissatisfaction due to sluggish responses and/or the inability to complete the checkout process due to some form of application error. However, it seems that the vendors that had issues during the 2006 Holiday Shopping Season have prepared themselves very well. One of my personal favorites, Overstock.com, was featured in several articles discussing its investment of almost ten times the amount of resources in previous years towards the goal of better application performance management. And yes, I did shop there this season. For the most part I have had few issues with the large online vendors, most of which occurred on Black Friday. From a personal experience, what I do see is that some of the brick 'n mortar vendors may be experiencing an unanticipated deluge in sales. Many of these smaller web sites have been slow, but even more significant, the order fulfillment process has been painful; I am still waiting for several gifts from these smaller vendors.

So, why did I make the Back-To-School reference? Well, there was a published report this past September 2007 that Online Back-To-School Sales were ranked second in volume when compared to the holiday shopping season. If there were any vendors that experienced issues this past Back-To-School shopping season, I urge them to see what Overstock.com has accomplished. Their plans took some time to implement, but I feel it was well worth it, since I continue to be a return customer.

Happy Holidays!

Posted by Matthew Adcock on Friday, December 21, 2007 11:54 AM EST
Leave a comment | View Comments (0)

Road Warrior-ism

2007-12-21T15:33:31.796-05:00

This may be a little off the blog topic as it does not refer to technology, but since I've have been away from home a lot lately on assignment, thought I’d say something about it. All hail the Road Warrior; those that get to travel all over the world to new and exciting places, and do all sorts of fantastic things. I've been a Road Warrior since I started consulting in the field of testing back in 1988 and whenever I talk with someone about where I've been and for who and what I did there, I get questions like "did you go see this?" or "did you go do that?" Of course they are referring the attractions somewhere within a hundred miles of where I was. In most cases the answer is, "no, I didn't really have time to, but I'll make time for it the next time I go." Now don't get me wrong, I do get to do some fun things. I've visited the airplane graveyard and the Biosphere in Arizona, taken the underground city tour in Seattle, dug for gold and gems in the north-east, gone to countless amusement parks, museums, visited famous beaches and have eaten at many high class restaurants; all of which have been made possible in conjunction with business trips. First and foremost I service the client who has contracted to have me there and in many cases I continue to work back at the hotel. For me this is great since my personal view of my career is that I get paid to play; the work is very challenging and I'm always getting into new situations and devising new solutions.

One of the greatest things about traveling is the frequent traveler programs. When I lived in New Jersey I flew out of Newark and used Continental Airlines since Newark was their hub. I made Gold level status year after year (almost), a couple of them I almost made platinum. Continental had a promotion that if are Gold for 5 years in a row, you stay gold for life. Wouldn't you know it, the fifth year I was on a long term assignment locally and didn't make it. Now I live new Phoenix, so I use US Air (formerly flew America West but bought out by US Air). I've made gold all five years since I've been here and this year will make platinum (RTTS has been busy). One of the benefits of the frequent flyer program is that you get to board the plane before non-frequent flyers, thus ensuring overhead space for your roll-aboard luggage. Others include, depending upon the status level you are, space available for free upgrades to first class and a tag added to any checked luggage marking it as priority so that it comes up on the baggage carrousel first. Also, depending upon your status level you accumulate a percentage of flight miles above and beyond the actual miles flown, which are good towards free flights.

Then there is the hotel frequent stayer program. I like staying at Marriott brands. There are status levels depending upon the number of nights you stay. I've been Gold on the Marriott Rewards program forever. You get points depending upon the amount of money you spend at the hotel that can be used for free nights and they even have a catalog of merchandise you can use your points on. Two of the perks of having elite status at Marriot are the free upgrades to bigger and better rooms and at the full service hotels, admittance to the concierge level and free food (continental breakfast and cocktail hour at night).

Then there are the frequent renter programs for vehicles. I typically use Avis. There aren't any formal status levels, but you get additional flight frequent flyer miles when you rent from them and free upgrades to better class cars. The biggest perk is that you don't have to wait on line. When you arrive, your car is ready with your contract inside.

The points I accumulated over the first 3 years as a road warrior, I was able to take my immediate family (my wife, 5 kids and me) to Cancun, Mexico. All of the flights and the 2 hotel rooms were free. Now that the family is spread out between Arizona, Florida and New Jersey, we use the points to visit the kids and for the kids to visit us. Priorities change over time.

Enter the demons. I was waiting at the gate for a flight recently, watching all of the people and started thinking about traveling. What I find is that when its getting close to boarding time I automatically migrate as close to the jet way door as I can get without crowding anybody, knowing I am elite status and can get on the plane sooner than most. This particular time I was upgraded to first class. The normal process is that those needing assistance are called to board, followed by first class customers, then it’s by boarding zone number. I start to get irritated by the zone 4 person standing between me and the jet way door. Why are they in the way of me and the others who can board before them? Don't they know the boarding sequence? I plan my route on how to get around them when they call first class to board. I'll say "excuse me" and proceed around to their right. Then a woman behind me asks if I am in first class. I say "yes" thinking to myself "first class and elite, thank you very much!" She was in first class as well, but it made me think that you really cannot judge by looks since I see all kinds of people in first class dressed in the full range of attire.

When arriving at my destination airport, my checked bag was one of the last to come up onto the carrousel; so much for tagging it priority. Irritated, but outwardly showing it, I headed to the rental car shuttle. What I've learned is that some airports appear to honor the orange "Priority" tags and some don't. Case in point, US Air at Newark airport never does.

OK! I have an "Avis First" priority reservation. I've had it for a week now. I was here last week and the week before without an issue. I'm dropped off at the "Preferred" counter and have to show my driver’s license and credit card, etc. Hello! Where's the consistency?

I am assuming for the most part that you probably don't know me personally and have not met me personally. I am not one that tends to get stressed or irritated as I mention here. I believe things happen and we just have to navigate our way around them and through them. I have always enjoyed traveling as part of my job and have no plans to stop. The benefits, both for career and personal endeavors, make those momentary demons seem insignificant.

Posted by Jonathan Harris on Sunday, December 16, 2007 9:56 PM EST
Leave a comment | View Comments (0)

RTTS Knows How To Attract and Retain Talent

2007-12-13T15:14:46.570-05:00

A recent article titled “How CIOs Attract and Retain Talent” featured on CIO INSIGHT gave a wide angle look at the trends within IT recruiting. It depicted how some of the leading organizations within IT are attracting and retaining the best talent during a time when demand for resources is high and IT majors are scarce.

As I read through the article I identified many of the recruiting best practices in staffing and retention that are also utilized by us. These include intensive on-the-job training, professional development, and a clear path to career growth. RTTS provides the highest level of training to all of our new hires: 325 hours to be exact. We encourage our employees to pursue professional development opportunities on and off site through mentoring, eLearning courses, and lunch-and-learn webinars and industry events. Our pyramid of professional growth clearly outlines the path to career growth in our organization so that a potential candidate can envision their future career goals being met in two years, five years and beyond.

To attract and retain the best talent, RTTS emphasizes work/life balance, offers competitive salaries, the opportunity to work with our impressive list of Fortune 500 clients and gain exposure to many areas of the business community, a cooperative work environment, and a list of benefits too long for this blog entry!

Our target audience of hires includes recent undergrads, MS/MBAs and career changers. RTTS employs many people taking the first steps in their IT careers and many who have long since grown into senior positions since graduation day. IT majors may currently be scarce but RTTS continues to grow because our company culture and policies actively engage top talent and we are committed to the success of our employees.

I encourage any and all Computer Science and IT faculty as well as Career Services staff to share this entry with students. If you are an HR professional let me know what are some of the things that your company is doing to attract talent. If you are a candidate, what practices are most important to you? I look forward to your responses and a continued exchange of ideas!

Posted by Margaret Lively on Friday, December 07, 2007 11:15 AM EST
Leave a comment | View Comments (0)

Top 10 Interview Do's and Dont's

2007-11-21T16:22:44.353-05:00

Before joining RTTS, I was a member of the Career Services staff at Fordham University. I worked diligently to create opportunities for students to meet with employers on campus and prepare them for the interview process. I reviewed and edited resumes to perfection, administered workshops on how to “Network Beyond the Handshake,” and role-played the interview process so students would have the necessary skills to dazzle recruiters. When undergraduate and graduate students transitioned into the professional arena I walked supportively beside them through each step of the process, calmly coaching from the sidelines, whispering career advice in their ears.

As Director of Recruiting at RTTS I am on the flip side. Now I am the recruiter sitting across the table from candidates, reviewing their resume to see if they meet our standards, and asking the tough questions while listening intently for answers that let me know whether or not they will be a fit for our organization. During the first few weeks in my new role I longed to take a time out during an interview so I could stop and let the candidate take a much needed deep breath, or provide counsel to them on better ways they could have answered the questions they missed the mark on. Although I was not the one in the “hot seat” I found myself squirming around in my chair when I heard candidates provide answers that made no sense, went on forever, or were so inappropriately personal that I could feel my face getting hot out of embarrassment for them!

Over the past six months in my new role I have grown accustomed to the inevitable interview bloopers and have compiled a list of Top 10 Interview Do’s and Don’ts from my experiences as both a Career Services professional and Corporate Recruiter:

DO research the company inside and out. Have a clear understanding of the company’s identity, the specific services or products they provide, and how the role you are interviewing for is positioned within the organization.

DON’T ask the recruiter to tell you about the organization. It is your job to be prepared and make a terrific first impression. If you don’t have a clue as to what the organization is all about, odds are you will not make it past the first interview.

DO dress professionally for your interview. Regardless of what the dress code is within an organization (i.e. business casual); an interview candidate should always look polished and professional. Proper business attire is expected, not optional.

DON’T arrive late for an interview. It isalways a good rule of thumb to arrive 15 minutes ahead of schedule.

DO answer the question, “Tell me a little about yourself,” in 60-90 seconds. The recruiter is looking for you to summarize your resume and provide some insight to your future goals. Be succinct in your answer and careful not to ramble on.

DON’T ask questions until you are invited to do so. An interview is your time to respond to questions and shine. Interrupting the recruiter or jumping in with questions prematurely will make you look pushy and aggressive – a sure turn off!

DO ask, “What are the characteristics of the ideal candidate for this position?” The employer will have the opportunity to go into detail about the role and describe who they see as the ideal fit for the position. You will find that many of your questions will be answered all at once.

DON’T inquire about work hours, vacation, or fringe benefits. At least not during the first (and in some cases second) round of interviews. These discussions are more appropriate once you are aware that an offer will be extended or you have it in your hand.

DO follow up with a thank you letter ASAP. Most candidates will send theirs via email which is the most widely practiced and accepted form of communication. However, don’t underestimate the power of the written word. A hand written thank you will be a rare and welcome treat!

DON’T post inappropriate materials to your social networking site. Recruiters access these sites to learn more about candidates of particular interest. It is important that you remember to keep your profile looking impressively professional – leave the photos from last Saturday night’s adventures set to private!

What do you think? Are there any Do’s and Don’ts that you would like to see included on this list? Your comments are a welcome addition so please leave them below.

Have a Happy and Healthy Thanksgiving!!!

Posted by Margaret Lively on Wednesday, November 21, 2007 2:20 PM EST
Leave a comment | View Comments (0)

Games People Play

2007-10-01T14:11:01.463-04:00

I just read that the Nintendo Wii outsold the Sony Playstation 3 by a ratio of 4 to 1. I am very familiar with the game console systems since my sons (10 and 7) are real gamers. They have the Wii, Playstation 2, GameCube (the Wii's predecessor), PSP (handheld), Nintendo DS (handheld) and the old Nintendo GameBoy Advanced, along with a computer (Dell's XPS) that was specifically designed to play games. Did I just list 7 different gaming systems for my kids?

What happened to playing outside with your friends? Now it's play dates or gaming and there is also the hybrid - a play date that includes gaming. I know Sony, Nintendo and Microsoft are making buku bucks from selling these systems and there are some really interesting games, but how did this happen? And why are we enabling this? I even know 2 adults who work all day and then play some online game all night long. I know other adults who are gaming junkies.

I miss the days when, as kids, we would pick up a ball and bat and play baseball all day long with all the rest of the kids in the neighborhood. Or football or basketball or soccer or tag or some other active, competitive game. Now it's the Wii or PS3 or computer games. Not that there aren't competitive video games and not that the kids don't break a sweat (I actually saw my sons sweating from boxing on the Wii). It just seems like this is fundamentally wrong. But just try taking it away from the kids and they cry about how all of their friends have systems and why they will be ostracized for not having the latest and greatest games.

Maybe I can take a negative and create a positive. Maybe I can contact Sony and Nintendo and Microsoft and see if my kids can become beta testers for the games. And maybe I can bill them out as gaming experts. Maybe we can make extra money and put it away for college. Or maybe I can use the money to buy that flat screen TV with the great graphics that I have my eye on. That would work great with my Xbox…

Posted by Bill Hayduk on Monday, October 01, 2007 2:10 PM EDT
Leave a comment | View Comments (0)

The Holiday Season is Coming! So is Microsoft?s Patch Tuesday!

2007-09-19T12:28:58.370-04:00

Are your applications prepared for the Holiday Season Shopping Blitzkrieg? How about Microsoft’s Patch Tuesday? Recent events regarding Skype’s two day system outage again revealed that we must take into account how an application and its infrastructure perform under expected and manageable conditions, in addition to proactively responding to excessive demand during unpredictable scenarios; the latter always seeming to be the most challenging and subsequently news worthy.

The systemic computer restart that occurred on Patch Tuesday revealed another set of conditions that organizations should be prepared to handle; a very large number of clients all requesting application services within a very short time frame. In the case of Skype, a fairly stable system was suddenly barraged with a large demand for access to its systems. Although the type of chaos that occurred due to the proprietary retry algorithms was unique to Skype, the behavior is similar to an e-commerce application that offers special on-line sales for a period of fifteen (15) minutes or an on-line news site that provides high-profile breaking news stories. The result is a seemingly infinite number of user visits, when compared to system capacity, which quickly overloads your application and/or its infrastructure. And in extreme cases, the demand can knock your systems off-line. So, what can be done to prevent this? First, performance tests can be orchestrated not only to validate the expected behavior of your application, but out-of-the-box performance scenarios can be devised to determine if there are potential scenarios that need to be accounted for. Second, determine the performance characteristics and limitations of your application. Third, enable mechanisms that intelligently determine when your application is reaching its limitations and subsequently govern/throttle access to the application’s services. In it's simplest form a message that says your application is busy is much better than allowing an unfettered number of customers vying for access to scarce resources and potentially undermining the stability of the application.

Although it’s not optimal to turn customers away from your application and possibly diminish immediate financial returns, sometimes it may be beneficial to be the Grinch, minimize your losses, and reassess your application’s needs for moving forward. It's better than making the news for all the wrong reasons.

Posted by Matthew Adcock on Tuesday, September 18, 2007 10:32 PM EDT
Leave a comment | View Comments (0)

RTTS Announces Online Distance Learning Program; First Courses Centered Around IBM Rational Tools -- Software Testing Firm Helps IT Professionals Grow Careers On Their Own Time

2007-08-27T10:26:26.276-04:00

New York, July 31, 2007 -- RTTS, a professional services organization specializing in software quality assurance, announced today the launch of its worldwide online distance-learning program. The online distance learning program is an exciting expansion of RTTS' well-regarded in-depth testing tool training courses. The first online courses will be centered around IBM Rational (NYSE: IBM) tools, with additional courses from HP (NYSE: HPQ), Microsoft (Nasdaq: MSFT) and Compuware (Nasdaq: CPWR) to be added shortly.

"We are offering the IT testing community the opportunity to learn new skills on their own time, at a cost-savings to themselves and their employers," said Bill Hayduk, CEO of RTTS. "We have taken our successful classroom courses and divided them into convenient, hour long segments over a two-week period. IT professionals no longer have to take a full week off from work and fly to another city to improve their skill set – they can do the sessions on their lunch hour, and work on the exercises on their own time. "

The online distance learning courses will be taught in real-time by RTTS' group of expert trainers. The typical curriculum will include introductory courses from the vendors that will be supplemented by RTTS' advanced courses. RTTS' internal team of experts developed the RTTS training programs. "All of our instructors have worked here at RTTS as software testers with a wide variety of Fortune 500 clients," said Eric Smyth, Director of Educational Services, RTTS. "So we are end users of the software as well as instructors. RTTS' online distance learning curriculum focuses on topics that have been experientially useful to us as testers as well as the real-world problems that we know will come up, and the real- world tools that will solve those problems."

RTTS is also offering a unique support system for its online students. While questions can be asked in real-time during the sessions, RTTS will also offer online "office hours" twice per week where students can call, email or IM their instructor to ask questions and get help.

For more information on the online distance-learning program, including schedule and requirements, visit http://www.rttsweb.com/training/distanceLearning/.

About RTTS: RTTS is the premier professional services organization that specializes in providing software quality for critical business applications. With offices in New York, Atlanta, Orlando, Philadelphia and Phoenix, RTTS has been serving Fortune 500 and mid-sized companies since 1996. RTTS draws on its expertise utilizing best-of breed products, expert engineers and proven methodology to provide the foremost end-to-end solution that ensures application functionality, reliability, scalability and availability. For more information visit www.rtts.com. Real-Time Technology Solutions, Inc., RTTS and the Real-Time Technology Solutions, Inc. logo are trademarks and/or service marks of Real-Time Technology Solutions, Inc. in the United States and/or other countries. All other company names, product or service names mentioned in this document may be trademarks of the companies with which they are associated.

O Ye Economic Buyers of Tools ... Caveat Emptor

2007-08-16T13:50:36.406-04:00

It is remarkable to me how many people (read: managers) involved in software quality efforts don't really consider the proposition of investing in an automated test tool for their organization with any great care. The most discerning (and usually the most technically aware) actually do pursue the purchase with due diligence, of course, but those are not the folks I'm thinking about. Often, we encounter the manager who just "bought the industry leader" without inquiring whether it really is the best tool for his/her problem, and without even seeing a demo of the tool. Just a pure marketing-buzz buy. The next step up is the buyer who 'gets it' enough to request a demo of the tool, but then decides to buy based on the demo (performed on the vendor's home-built application target, designed by the vendor's marketers to show just what the marketing squad wants the potential customer to see, and nothing else). This buyer is wowed by the demo, and never askes for the obvious: a proof-of-concept in their own environment, on their own target application. Why sales like these happen so often is a bit of a mystery to me. Why don't buyers ask for the gold standard before buying (does it work on MY application in MY environment?)?
Well, risky as it is to try to explain behavior I truely don't fathom, I'll throw caution to the winds. I think it is a combination of two things, both thoroughly American. The first is the idea that you can get something for nothing. A more American idea there never was. Everyone is brought up to look for a 'deal', a 'sale' and a 'great buy'. Its what makes people give mortagages without verifying income and what makes other people take mortgages without reading the fine print. Its what makes our economy go 'round. The second is the visceral American reaction to technology, better known as the gee-whiz factor. The cooler technology can be made to look (regardless of what is under the hood), the greater its market cache. That is why iPods fly off the shelves, even though my music afficionado friends tell me it is inferior to some competing products. Put both of these together, and you have a marketing knockout-punch, at least for lots of folks involved in software quality.

For my two cents, I'd rather buyers think this one through a bit more. That may sound counterintuitive from someone who makes his living by implementing with these tools - the poorer the tool fit to the target application and project, the more work (for us) to make it work, you might think. And you'd probably be right about that. But the better the fit, the better the better the overall quality of the job. We can produce better, more robust, more effective automation projects with better tools and better fits between tool and project. So...automation tool buyers...caveat emptor!

Posted by Jeff Bocarsly on Thursday, August 16, 2007 1:46 PM EDT
Leave a comment | View Comments (0)

Home Is Not Where The Work Is

2007-07-27T00:18:10.245-04:00

I just got back into the office after spending the last 4 business days working from home. Apparently a "steam-pipe blast blew a 15-by-25-foot crater in a midtown street (7/17), spewing a geyser of near-boiling water, gluey muck and rocks 120 feet into the air and onto terrified spectators as they ran for their lives". We're at 360 Lexington Avenue, between 40th and 41st Streets in Manhattan.

Anyway, because of the advent of VPN and remote desktop, IM and cell phones, working from home is supposed to be "the next best thing to being there", or so it is stated. What I have been reminded since I last worked more than 1 day in-a-row from home (back during the 9/11 aftermath), is that it is not.

The lack of face-to-face social interaction with co-workers replaced with email and instant messenger just doesn't do it for me. Yes, the wife, kids and dog come in and out of the office and remind me that I am not alone in the house. But it's not the same.

And it got me to thinking about firms and projects that use remote workers, along with this mode of communication and interaction, as a defacto standard. Where is the time when you get to know each other, understand each other's likes and dislikes, strong points and weaknesses and compliment each other? Where is the give-and-take banter that promotes teamwork and loyalty? It isn't there and no one can convince me otherwise. Using IM shorthand such as brb, l8r, rofl and symbols such as :)) and ^_^ leaves me feeling :/ ( frustrated) and just doesn't cut it. And the feeling of disconnection that borders on isolation just does not seem to me to be a great way to work.

Anyhow, the office re-opened today and even with the commute, the hole in the ground in front of the building and all the other issues with working in a bustling metropolis, I am happy to be back in the office. IM, email and text messaging all have their places, but I'll take a good water cooler conversation with a real person face-to-face any old day.

Posted by Bill Hayduk on Wednesday, July 25, 2007 5:31 PM EDT
Leave a comment | View Comments (0)

Point, Click, Done!

2007-07-17T09:16:56.714-04:00

How far from the truth is that? When it comes to sophisticated performance testing tools, and even the not so sophisticated ones, how many times has anyone been able to just use the out-of-the-box functionality of a testing tool to accurately and thoroughly test an application? Let me guess at this... (thinking) (thinking) (thinking)... None! Ok, in all fairness, there are rare instances when someone tests a simple application, really simple (like a static web site). Anyway, here is my thought as I was flying home from a recent mentoring engagement.

Actually, this applies to all of the tools I use or have used. They all pretty much have the same base functionality. They record, they play back, and they have some form of programming language (compiled or interpreted). The implementation of these functionalities differs, of course. Regarding programming related functionality, in most cases if a specific functionality is not there, you can usually program around it (yeah, right!). For the newbie’s out there, programming around it only applies if you know it is something you need. This is all well and good, but what I was thinking about was the fact that I need to keep programming (or using) the same custom functionality.

Specifically, since the mentoring I was just doing was against a web application, I needed to use custom code functions that are typical and customary to doing web testing. For instance, pulling a list of values from a listbox, randomly picking one and using it in the next request. What about a function to randomly pick a link on a web page? Wouldn't it be great if there was a function that performed this act that comes with the test tool? Of course there are always unique situations for each application that will require custom coding, but the typical things like I just mentioned would serve 2 purposes. First it is code you do not need to maintain or carry with you (importing) and second if it is coded into the test tool itself, it would probably be just as efficient or maybe even more efficient than your custom code (assuming the tool vendors have the right programmers and/or you’re not dealing with interpreted script code).

This blog entry was geared towards newbies since I was recently training people new to these tools. They were all programmers in some form or other (very technical, which is always a pleasure when teaching a technical subject). So for typical code neccessities, let’s have the tool functionality built in. But for custom code – hey, all die-hard programmers out there, we all love our own code creations, right? (wink, wink)

Posted by Jonathan Harris on Monday, July 16, 2007 5:58 PM EDT
Leave a comment | View Comments (0)

The Big Three Show Their Wares

2007-07-11T15:45:02.027-04:00

OK. I finally have (somewhat recuperated) from my whirlwind tour of Compuware in Detroit, IBM in Orlando and HP in Las Vegas for the last 3 weeks (not to mention STAR East 2 weeks before Compuware and 2 weddings on the weekends between all of the conferences and a brief vacation to the Chesapeake Bay area).

My first stop was Detroit and Compuware for the Partner Summit. Compuware again has shown that they get technology. Some of their offerings convince me that they are going in the right direction for customers. Optimal Delivery Manager is the type of dashboard that will allow users to manage test activities from project management to requirements to functional and performance test activities – providing much needed traceability. It borrows some of the key features of Changepoint (their PPM offering) and provides an ability to manage all facets of testing. Peter Karmanos, the founder and CEO of Compuware, was the primary keynote. ‘Pete’ (as he is admiringly known throughout Compuware) reminds me a bit of Jack Welsh, the gruff and brilliant ex-CEO of GE, in that he is says what he thinks. It was interesting for me, seeing someone who started a firm as I did and actually take it to a place where it is global in scope and hitting revenue numbers that well exceed $1 billion. Stephanie Moore of Forrester Research ended the conference with an interesting take on why outsourcing to India is failing and how niche firms who specialize are successful.

The next stop was IBM and the IBM Rational Software Conference in Orlando. From our perspective, there was approximately a 50% increase in the number of partners there. So IBM, who wins many awards for their approach to partnerships, has really (and finally!) infiltrated their concepts into the Rational group. From a quality perspective, the new version of Rational Performance Tester (RPT) has really become a ready-for-primetime player in the load/performance/scalability tools arena. The latest release adds IP aliasing, root cause analysis, additional protocol support (for Citrix, SIP, Seibel 9.8, mySAP and SAP GUI), and has added SOA quality testing. Rational Functional Tester (RFT) has added support for Infragistics, AJAX, .Net, Firefox and Adobe Flash/Flex. IBM is also going after the process market with a quality process management tool that provides traceability with requirements and defects. IBM sees a differentiation between the quality initiatives of subject matter experts, implementers and coders/testers and is working towards providing each with tools for assisting in the testing field. And IBM feels there is a huge need for process. IBM also announced 2 acquisitions – Watchfire and Telelogic (more on this in a later blog).

The last stop was the HP Software Universe at the Venetian in Las Vegas. We were interested to see how the previously named Mercury Interactive, the biggest player in the testing space, had been assimilated. The answer - Mercury is gone. It's all HP now. At the keynote speech by Mark Hurd, the CEO of HP, my thought was “is there a more impressive CEO in the technology field than Mark Hurd?” If there is one, I haven’t seen him/her. He is a straight-shooting, no-bull type of leader. Mr. Hurd explained that HP needed to automate much of its business before it could preach this to its customers. HP’s goal is to reduce the cost of IT for itself and its customers and highlighted 5 areas of improvement: (1) increase efficiencies and automation, (2) the needs of business outweigh the ability to deliver, (3) improve quality, (4) speed and agility matter, and (5) reduce risk. HP then highlighted how they would accomplish these issues. There seems to be a big play to integrate Quality Center tightly with requirements and traceability. HP is also very interested in the data warehouse sector. Their recent release of NeoView, a data warehousing appliance, will have a significant impact on the lower end of the marketplace, especially in pharma. And HP’s SOA strategy, which ties its previous acquisition of Systinet (for SOA governance) with QACenter (for quality) and Business Availability Center (for management) to me, is the most complete end-to-end solution in the marketplace. Very impressive. And HP, on the heals of the previous week’s announcement by IBM of its purchase of a security firm (Watchfire), announced the acquisition of SPI Dynamics, an RTTS alliance partner.

In summary, it is interesting to note that the major vendors have moved away from a ‘software testing’ message to now more of an ‘application lifecycle quality management’ (ALQM) message (as has RTTS). Both IBM and HP preach increased speed and agility of the business needs of customers. All three vendors (including Compuware) are in a rush to get SOA solutions firmly entrenched in the mindshare of customers. All three are touting traceability and management oversight by tying their project and portfolio tools to the ALQM space. All now have solutions for security testing of applications (Compuware has application security testing wrapped in its DevPartner tools). Borland and other smaller players seem to be getting left in the dust. The 4^th big player (Microsoft) is making a very aggressive play in the marketplace via Visual Studio Team System and has the distribution channel (the Visual Studio platform) to pull it off. In seeing the ‘big three’ present their views of the software quality world, I see much more consolidation coming this way, with companies and products being added from the automated build, change management and operations sectors being acquired to complete the offerings. Let’s see where the marketplace goes and who is left standing in 12 months. My prediction is there will only be 3 big players left in the ALQM space.

Posted by Bill Hayduk on Wednesday, July 11, 2007 3:03 PM EDT
Leave a comment | View Comments (0)

The Sopranos - Everyone Dies

2007-06-25T16:13:37.093-04:00

I just got back from 3 weeks of conferences (Compuware Partner Conference, IBM Rational Software Conference, HP Software Universe) and was in on the Disney compound for Rational when the last episode of the Sopranos ran. Disney does not have a deal with HBO, so believe it or not, nowhere on their property could we see the last episode. Luckily Joe Mundy, RTTS' Southeast Regional Manager, lives in Orlando and we were able to persuade (beg) him to have us over. My take on the "black out" ending by David Chase is this: he copped out in case he wants to do a feature movie. This way he can say no one was killed and he can bring Silvio out of his coma.

Since I have been watching it since the beginning and since it was not completed, I would like to finish it for Mr. Chase. Here goes...

Two hit men were sent in to do the job. AJ goes first. I am tired of his act. Tony and Carmella go together, in each other's arms. As the hit men are leaving, they notice Meadow coming in. They bump her off also. Now - just to clean up any lose ends via the Soprano family, one shooter pays a visit to Janice and gives her the Adriana treatment (is everyone as sick of Janice as I am?). The other goes to the hospital and gives Sil the Christopher Maltisanti breathing course. As he is leaving after the hit, he places a call to his boss to inform him that the task has been completed. Cut to Paulie Walnuts putting down the phone, smoking a cigar and toasting himself as the new boss. Now - fade to black.

There you go - I ended for you. Any questions?

Posted by Bill Hayduk on Monday, June 25, 2007 4:13 PM EDT
Leave a comment | View Comments (0)

The LIRR and Microsoft Task Manager? Perfect Together

2007-06-13T15:59:51.296-04:00

No, I am not the New Jersey Governor. And what could I actually be talking about regarding application performance and scalability? Well, without going into a Dennis Miller-like rant (or maybe I will), I’m simply referring to the rather disappointing manner in which the Long Island Rail Road (LIRR) or any mode of public transportation (e.g. airlines) manages to inform its customers of delays, changes, and cancellations. Have you been to LaGuardia Airport recently? Anyway, we’ve all been there, frustrated, standing in seemingly pointless lines, parked on the runway, or sitting on a stalled train that inertia has for all intentions prohibited the train from ever moving again. "Why?" I ask the train conductor. Cue the shoulder shrug…

Well these days it seems that you are even lucky to get that apathetic acknowledgement of what is happening. It’s very frustrating to know that “something” is happening, but not to get any feedback or information pertaining to your delay. If someone, please someone just stand up and explain to us what is happening. Inform us. Set expectations. Manage my satisfaction. Keep me as a customer. That’s fairly simple, uh?

Segue to application performance and customer satisfaction…

So, this morning when I boot up my computer and try to load any program, such as Firefox, nothing happens. I try again. I still see nothing. Gees, I just want to see if that flat screen TV that I ordered had been shipped. Nada. Niente. Nothing. I see nothing except my Desktop and its lineup of icons, but I can hear the hard disk churning away. What is happening? Cue Microsoft Task Manager. Exit stage left LIRR (for now). Microsoft Task Manager is a nifty program that allows me to quickly glance at how my computer’s resources, such as the memory utilization and CPU utilization (amongst other things), are being used. When Task Manager finally loads, I can start to poke around and see what is causing my hard disk to spin like the dickens. I look at the process list. I sort the list by CPU to see what process is currently requiring the most horsepower on my computer. Low and behold, it’s one of the well known antivirus programs. As it turns out, it was performing a system wide scan on my computer. OK, that’s why I have this software; to look for virus and spyware that might be lurking in the depths of my computer. But again, just like the gate agent on my most recent flight who couldn’t seem to manage an answer why we were still waiting to board the plane after 2 hours, why couldn’t this program actually inform me what it was doing? Why couldn’t a simple notification that it was scanning my computer be produced? Maybe a simple message box could have sufficed? Let me know what’s happening. Managing customer expectations goes well beyond running load and volume tests in order to determine application bottlenecks. In the more holistic process of software performance engineering, providing feedback is a key attribute in keeping end-users satiated.

So, I’m not here to pick on this antivirus program, but the lack of feedback from software is more of a norm, rather than the exception. When I submitted my credit card for that flat screen TV the e-commerce web site that I was using gave me no indication of what it was doing while I waited for 20 to 30 seconds to get a confirmation web page back. I think that flag or globe in the Internet Explorer toolbar was waving or doing something to indicate that I actually did submit my payment information. Or did it? I tell you it was not comforting knowing that I just made a large financial investment over the internet as I waited for some clue of what was going on. All I did know is that I just clicked a button to send my credit card information to some remote location and I all had to show for it so far was a blank screen in my web browser. I was thinking, “should I hit the back button and tried it again?”. I’m sure I’m not alone in thinking this way. And I’m sure that non-technical people are even more perplexed on what to do. What could have been done? Perhaps the web application that I was using could have launched a little progress window stating that it was doing something, rather than relying on the web browser’s flashy toolbar as a progress indicator. Perhaps rather than relying on the mouse cursor to change to an hourglass, the application could have provided feedback that was pertinent to the operation it was currently processing. Perhaps the next time I won’t have to rely on Microsoft’s Task Manager to tell me that my antivirus program has taken over my computer to run a system scan. I am betting that this not-so-groundbreaking realization of software performance engineering is much easier to implement when compared to getting some clue why my train is not moving. And I’m sure that the customer perceived performance of your application will be well revered, unlike applications that require people like me to use Task Manager to figure out what is going on.

END RANT
Posted by Matthew Adcock on Wednesday, June 13, 2007 3:59 PM EDT
Leave a comment | View Comments (0)

Why isn't it a standard that all components have interfaces for automated testing?

2007-06-07T14:39:19.453-04:00

Why isn't it a standard that all computing environments and components have interfaces for automated testing?

Where is the engineering sense?
Anyone who has worked at building automated test harnesses knows that while many of the common target environments and UI components work with test automation tools, many still don't. And, if you go back just a few years, even fewer worked.

Building software is supposed to be an engineering practice and process. Software quality should be also. Why isn't an interface that is optimzed for automated testing a standard part of every product design? And why isn't the need for a testing interface part of every computing curriculum in the country, so that engineers are trained to include them as a matter of course?

Well, you might say, it's getting better. And, in fact, it is getting better. With Java, dotNet and Web computing ruling the day, all of the major automated software testing vendors have provided solutions for dealing with the standard UI objects in these environments (and most of the third-party objects too). (Never mind that some of them charge you extra for access to these standard environments.) For web applications, the best-supported browser is IE, which makes sense because it is the de-facto standard in the business world. There already is support for other up-and-coming browsers (IBM Rational's tool, Rational Functional Tester, also supports FireFox as of its most recent release, as does Hewlett-Packard's QTP), and if the browser market splits in a serious way, more automation tool vendors will support more browsers without a doubt. So things, you might say, don't look so bad.

Furthermore, for the middle tier and back ends, access has been around for a long time - you can hit your databases directly from your automated testing tool, and your SOA web services as well, and message queue products likewise have useful interfaces for most test tools. Automated data verification for all of these components has been attainable for a good long while.

So what's my problem? Well, I kind of feel like all these nice things that have been happening for test automation and software quality in the last few years are accidental. It never seems to be a deliberate part of the design strategy, which means that next week, or next year, the next new-new thing might be a step backwards for test automation and software quality engineering.

Even now, there are still many popular components out there where ease of automated testing is clearly not part of the design, not part of the object model, and not a strong interest of the vendor. So even if you can hook the object (and you often can), if the model doesn't expose the object's data, you're still in a tight spot for implementing test automation.

So, where is the engineering sense in all of this? Seems like a no-brainer that incorporating an automated testing interface should be part of how software is designed, and part of the decision when software tools are purchased. It should be a good selling/marketing point for component vendors (some do play up this side, but way too few...), and it shouldn't be too hard to implement. My guess: it won't happen until a virtuous cycle develops in the market - component vendors will have to come to view quality as a selling/marketing/competitive point, and purchasers will have to expect vendors to deliver features that enable and support quality engineering. Don't hold your breath.

Posted by Jeff Bocarsly on Thursday, June 07, 2007 2:39 PM EDT
Leave a comment | View Comments (0)

Houston, We've Had a Problem

2007-05-31T17:04:30.625-04:00

"Houston, we've had a problem." This is a well known quote from Tom Hanks (??); no - it was really James Lovell during the Apollo 13 Mission in 1970, which was supposed to be the 3rd manned lunar-landing mission under NASA's Project Apollo. Although the mission was catastrophic at the time and almost fatal, this particular quote has lived on in infamy to be used in humorous contexts or in my case when I am commercially using or testing an application that starts behaving badly, prompting me with cryptic error messages, taking what seems like eons to respond to a request, or even just refusing to respond to me at all whatsoever. And for some reason this has occurred to me quite often within this past year. This past Black Friday 2006, both Wal-Mart’s and Amazon's e-commerce web applications experienced significant outages and performance-related issues. Well, I didn't want that Microsoft Xbox anyway! On Christmas Day 2006 I could not even create a new account for my nephew on Apple iTunes, so that he could download songs for his brand new Apple iPod. Thankfully we were able to download songs from Green Day the following weekend. Even more recently, using Turbo Tax, 2006 tax returns could not be electronically submitted to the IRS starting several hours prior to the tax deadline. Well, I guess I deserved it for waiting until the last minute. That flat panel TV that I was going to buy using my tax refund would just have to wait a little longer. What's going on here?! Well, as it turns out, these companies just did not anticipate the large demand for their services and merchandise. Whether it was due to stellar marketing, an outstanding sales force, or drastic price slashing for 20-minute sales, their computing infrastructure was just not sized and/or configured properly to sustain the subsequent onslaught of their customer’s demands. So, why am I here? Well, hopefully moving forward we can start to use this Blog to start discussing issues related to the ones I've highlighted here and conversing about better ways to manage the life cycle of application performance. I'm looking forward to see where this is going to lead us.

Posted by Matthew Adcock on Thursday, May 31, 2007 5:04 PM EDT
Leave a comment | View Comments (0)

Travel Time

2007-05-31T14:12:04.812-04:00

Monday signifies the main thrust of my conference travel season. For those who travel frequently for business - my condolences. Between the 2 hour early arrival to the security people dumping out my after-shave because it was more than 2.5 ounces (and more money than I care to think about), travel has become a tiring affair. And what happened to food and movies on the planes? Now all we get are 1 bag of peanuts and "Everybody Loves Raymond". At least they still serve Bloody Marys :).

Two weeks ago we were sponsors at STAR East in Orlando. Monday kicks off our alliance partner tour. First stop - Detroit and a visit to the Compuware Partner Summit. While Detroit cannot be confused with Honolulu or Las Vegas, there are casinos to have some fun in and Compuware shows us a good time. Bob Donald will be our host and always makes for interesting happenings. Compuware has some new offerings and is creating a new marketing message, so we'll see how that all plays out. I was also hoping to catch a Pistons / Spurs NBA finals game, but, as of this writing, the Pistons don't seem to want to hold up their end of the deal. If they can't beat a Cleveland team with LeBron and a bunch of guys who couldn't make my high school team, then I guess I will have to watch Duncan, Ginobili and Eva Longoria's boy toy pound the Cavs into submission.

The following week brings us back to Orlando and our 13th trip to the IBM Rational User Conference (and about my 7th or 8th time at the Swan and Dolphin). We have been sponsors and attendees since IBM was Rational and Rational was SQA. The RUC gives us a chance to hook up with Jeff Schuster and the rest of the test tool dev team for a "look-see" at what they have been up to. We have been beta testing their SOA testing component and like what we see so far. It also means us taking Jeff out for a 54 ounce steak dinner at Shula's or other home of a gargantuan side of beef. Jeff is always on some kind of Atkins-like diet and prefers to clog his arteries with a half of a cow. IBM is spinning a more complete story, if not the most complete story of the entire application lifecycle management space. They are marching towards complete lifecycle traceability and should have some interesting stuff to show us.

The last leg is in Vegas and the HP Software Universe. As I mentioned in a previous blog, it should be interesting to see how HP "does software". Many of the senior Mercury guys are long gone, so this will truly be HP's show. We will have a booth and will be sure to speak with clients to see how the change affects them.

I'll post my thoughts and opinions when I have decompressed from the 3 conferences and can figure out where I am. Until then, does anyone have a bag of peanuts?

Posted by Bill Hayduk on Thursday, May 31, 2007 2:12 PM EDT
Leave a comment | View Comments (0)

Thank God You're Here

2007-05-31T03:12:22.812-04:00

Thought I'd start off with a little thought dump. I just watched a few episodes of "Thank God You're Here", a comedy show where actors are dressed up and thrown into a scene with absolutely no knowledge of what they are getting into and have to improvise in front of an audience and home viewers until a judge has had enough and stops the scene. Some of the actors do quite well, stealing the scene and making it work (mostly through comedy). Others get thrown for a loop and struggle through it (gets boring). This is not too far from my world. There are largely two situations I find myself in. First is when a company has performance testing as part of their pre-deployment in which case my job is to help them “make it work.” Second is when a company encounters a performance problem and calls upon RTTS to help them resolve the problem as quickly and efficiently as possible. That’s the “Thank God You’re Here!” This is the time when we (RTTS) are thrown into the scene, and find out if we have the knowledge and experience to make it work. I’m going to write about many things here, including experiences of mine, perplexing and philosophical questions, methodologies, interesting occurrences, issues and resolutions. I hope some of what I do here will elicit responses and participation or all to share.

Posted by Jonathan Harris on Thursday, May 31, 2007 3:12 AM EDT
Leave a comment | View Comments (0)

The STAR East Conference

2007-05-19T09:52:49.203-04:00

I attended STAR East last week in Orlando, which is sponsored by SQE, who are the publishers of Better Software Magazine and StickyMinds.com. What I realized is how international in flavor the show felt. It seems that after all of this time, software quality has finally become mainstream worldwide as part of the application lifecycle.

I had a thoroughly enjoyable dinner with Theresa Lanowitz of Voke, the premier analyst in the Application Lifecycle Management (ALM) space. We discussed the direction of the software quality industry and other topics, such as the great information that Theresa provides at Voke, along with RTTS’ future direction in the ALM space. I also realized that Theresa grew up in Pittsburgh and I am a life-long Cowboys fan! The horrible flashback of Roger Staubach and the men with the stars on their heads losing twice to Terry Bradshaw, Franco Harris, Mean Joe Greene and the rest of the Steelers. Those of you old enough to remember can understand the pain!

I had an interesting conversation with Yochai Hacohen and Rafi Benami of Radview. They have released a version of their WebLoad performance tool as open source and are hoping that it becomes the dominant opens source tool in its space. Our performance division has always liked the functionality and power of WebLoad, so we will take a look at it to see if it fits into our strategy.

I also met with Michelle Davidson, Site Editor of SearchSoftwareQuality.com (TechTarget) and Holly Bourquin, Director of Publishing of SQE. Both publications sport online resources that are excellent for information regarding software quality. Michelle and I spoke about the need for tools and documented strategies for testing Software Oriented Architectures (SOA) specifically web services. RTTS has been testing web services successfully for years and our resident guru Jeff Bocarsly wrote an excellent white paper on it documenting what SOA is and our approach to testing it.

In 2 weeks the RTTS team goes on the road for 3 weeks is a row to the Compuware Partner Conference (Detroit), the Rational Software Development Conference (Orlando again – our 13^th year there!) and then we finish with a trip to the HP Software Universe show (at the Venetian in Las Vegas – what goes on in Vegas…). We should all be ready to collapse by then. Well, I’m off to 2 little league games for my boys. I hope they faire better than the Yanks (lost to the Mets last night).

Posted by Bill Hayduk on Saturday, May 19, 2007 9:52 AM EDT
Leave a comment | View Comments (0)

The HP Mercury Transition

2007-05-07T09:48:34.390-04:00

Welcome to my new blog! The goal is to provide some insight into RTTS' vision as it relates to business and technology happenings while also delving into my personal day-to-day fun.

On to blogging....

We're all waiting to see what happens in the world of HP. Since the Mercury takeover, it's been pretty quiet. Customers, competitors and users are constantly asking us if we have heard anything. It will be interesting to see if there is a refocus regarding product direction, since Mercury (now HP) is clearly the market leader in test tools. When IBM purchased Rational way back in '03, there was a 2-year time frame where Rational employees were leaving due to the culture change from a mid-size to a giant firm and Big Blue was integrating itself into the day-to-day business. Rational products were almost frozen in time. This may happen again with Mercury. Competitors are definitely using this time to attack their existing base. We at RTTS will be heading out to HP Universe in Las Vegas to hear the new vision. It should be interesting.

Posted by Bill Hayduk on Monday, May 07, 2007 9:48 AM EDT
Leave a comment | View Comments (0)