R Allan Baruz worked a series of small-scale contract programming gigs for educational and non-profit institutions before he realized that even quality assurance pays more than that. Joining RTTS as an automated functional test engineer, he eventually joined the dark side of performance test automation and engineering. With a diverse range of interests, he writes about whatever catches his attention.
A discursive and irreverent but not necessarily untrue history of the IBM Rational test tools (pt 2)
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.
A discursive and irreverent but not necessarily untrue history of the IBM Rational test tools (pt 2)
<p><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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
A discursive and irreverent but not necessarily untrue history of the IBM Rational test tools (pt 1)
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...
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.
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:
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.
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?
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.
