CHANNELS
 
 
 
 
 
 
 
 
ON THE WEB
 
 
 
 
PRINT EDITION
 
 
 
 
BZ MEDIA
 
 
 
 
ADVERTISER LINKS
 
 
 
 
 
 
 
AS OF 11/19/2008 6:35AM EST
Automatically Automate Your Automation
Stories Columns Opinions Resources

By Edward J. Correia

April 29, 2008 —  It’s not an exercise in repetitive redundancy. It’s a plan to use automation technologies to help automate your tests. And it’s the brainchild of IDT testing consultant and author Elfriede Dustin.

In her upcoming book, “Implementing Automated Software Testing,” (Addison-Wesley, Jan. 2009), she explains how the effort of developing software to test software can become more efficient by being streamlined. “Using automation to implement software test automation is an effective way of removing required and error-prone manual human interaction as much as possible,” she says. The ultimate goal is therefore to automate the automation of tests.

“For example, companies often spend time developing a test framework from scratch, creating functions to allow for batch testing, distributed testing or e-mail notification,” she says, pointing out that numerous frameworks already exist to provide such capabilities. Taking advantage of existing and free [and usually open-source] components allows for reuse, ease of customization and addition of features, and saves time and money. “Instead of developing new testing framework features, we will find that much of what we need has already been developed and is ready to be downloaded from the open-source community.” Component repositories like Koders and Krugle make it easy.

As any tester doing automation knows, the creation of automated tests requires a mini-development lifecycle all its own. So borrowing from what the software development community has already figured out, Dustin suggests using tools that help automate all phases of the lifecycle, from requirements to design, to implementation, testing and defect tracking. “As part of your test framework, you could follow a model-driven design for test procedure development.”

A good open-source automatic test generation framework is AndroMDA, which, according to its Web site, lets you “use your own EMF-based metamodels and write model-to-model transformations to transform from a Platform Independent Model (PIM)—at the highest level of abstraction—down through a stack of intermediate Platform Specific Models (PSM) using easily understandable transformation steps until you finally reach the lowest level PSM from which it is easy to generate code using simple model-to-text transformations.” Run-on sentence translation: Automation makes things easier.

Tools such as Telelogic’s Automatic Test Generator (ATG) and Test Conductor (TC) is a promising commercial solution. “Together, ACT and TC generate a “test harness/platform” that can be used to generate test cases and the test code needed to completely test your model on the development platform as well as the target.

There are other ideas for automating the generation of test procedures. “For example, if all test procedures were written in a Model-to-Text Transformation MOF Language, then automated test code could be generated from the manual test procedures,” Dustin says, referring to the OMG’s specification for turning MOV models into text.  

In her experience, Dustin finds many testers faced with the challenge of verifying vast arrays of test data combinations and permutations. They find it “tedious and error prone to manually develop such data sets using a spreadsheet. But manual test data creation processes are still common in many testing shops,” she says. “Why not use one of the many test data generators that provide us with automated combinatorics-based data output?”

For example, the National Institute for Standards and Technology (NIST) has developed a test data generator called FireEye that can be downloaded once you contact NIST for a login id and password.  FireEye allows for such automated test data generation. NIST also published a comparison of FireEye with other available tools.

There are numerous ways to automate test automation, such as by using existing Java libraries to test a user interface (i.e. the Jemmy unit-testing automation tool), by using an Interface Design Language (IDL) for code generation, or self-testable components. “As long as we are required to use [or] develop software to test software we might as well automate that process as much as possible.”

This article was in part a response to my Test & QA Report of Dec. 4, 2007, in which I pointed out the apparent paradox of developing software to test software, an idea originally brought to me by Dustin. We concluded that the best tool is still the best tool, regardless of the task at hand. “So even though developing software to test software seems counter-intuitive, it is for now the best tool available.”


Share this link: http://www.sdtimes.com/link/32098
 


 
 
 
 
 
 
 
 
 
 
SUBSCRIBE TODAY!
 E-Newsletters:
  News on Mon/Thurs.  More info
  Test & QA Report  More info
  EclipseNews  
  SPTech Report  More info
 
 
 
PDF & PRINT EDITION
* Requires Resource Account!  LOGIN or SIGN UP

Download Current Issue!
ISSUE 11/15/2008 PDF

Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE
 
REGISTER
 
GET NOTIFIED!
About all of the latest Resources
 
 
SD TIMES 100
It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.