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 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.
