LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Your Test Automation To-Do List


By Edward J. Correia
June 5, 2007 — 
Have you ever sat down to test an application and found yourself asking, "What were the developers thinking? How can I ever test this application?" If the answer is yes, you're not alone. Many applications are written with absolutely no consideration for testers, let alone the automation of their tests.

Is there anything you can do? According to Torsten Zelger, there's plenty. "Many times we sat in front of an application where the basic testability features were not considered at all," says Zelger, a test automation specialist at Audatex Systems in Switzerland. He suggests that before starting any test automation project, the team conduct a test automation feasibility study.

"Over the years we've collected a set of items to check for before automating any tasks, and that has become a mandatory checklist for all testers in our company," he explains. Audatex develops claim processing software and solutions for the insurance industry, and Zelger leads one of the company's test teams.

Test automation scripts can be made smaller, more efficient and less brittle if given a means of recognizing individual objects. An automated GUI testing project shouldn't even begin if no mechanism exists to identify the GUI controls, says Zelger, because "many scripts will become obsolete if the developer shifts a control or a different place or adds new ones."

To Do: Identify areas of the AUT that lack unique object identifiers.

As any good tester knows, output isn't always predictable. Database search results and other types of lists almost always vary, so controls for such functions should be uniquely identified. "If such controls are not equipped with some unique identification, the output is much more difficult for the test automation engineer to verify and leads to heavy validation script development," says Zelger.

To Do: Identify list views and check whether your script can handle data stored in a different order from one test to another.

Consistency is another important consideration. I'm rather a stickler for this in my work, where I encourage the use of a common structure for the naming of files and directories in our team's workflow to simplify data retrieval and training. If a consistent scheme is used for naming objects of the same or similar purpose, scripts can be smaller and more easily maintained because fewer GUI objects need to be referenced.

"I was once given the task to make sure that a user could request a valuation for all vehicles that the GUI offered," Zelger says. "The first step was to identify all models for each manufacturer and then ascertain all submodels for each model." If the resulting page displayed the correct controls, the application tested correctly.

But in the case of an error, the page would display a message in red. "A manual tester could have easily detected a red error message," Zelger explains, "but it was impossible to do this test manually in an acceptable time frame with about 1500 vehicles," and the error messages varied depending on the type of error that occurred. "If a test didn't make it to the next page, we knew something went wrong, but we wanted to know exactly what went wrong without the need to parse the HTML code." The answer? The next item on today's To-Do list.

To Do: Force the AUT into error conditions to determine whether the automated test tool can easily access error descriptions.

You might not think it necessary, but it's worth verifying whether object IDs are reassigned whenever an application is restarted or if they're assigned dynamically depending on the actions of the GUI, says Zelger. "I've seen applications where the name of the submission button depended on the source from which the dialog was called. Such dynamics have an impact on the maintenance of your scripts," he says. So he recommends that as you organize your code into reusable functions, be sure you not only pass the object name, but also know if the name is a variable.

Such conditions make automation extremely difficult. "It pays to demonstrate to development what happens to your scripts if developers perform such changes without notifying you," Zelger says, and adds that it's helpful to repeat the demonstrations from time to time.

To Do: Restart the application after you've recorded the test steps and check whether the object names remain the same.

Zelger says it's also helpful to know how often the development team changes the names of its objects. "Check whether developers hold a central repository of object names and analyze the history. For example, Visual Studio C++ usually stores its objects in a file called resource.h," he says.

To Do: Analyze the developers' object-name repository.

Special characters also can be problematic when it comes to object IDs, particularly for applications intended for European countries, where they're prevalent in alphabets. Different GUI automation tools often will exhibit different behavior. "What is good for tool A might not work for tool B, or the other way around," says Zelger, who uses a pair of such tools and compares the results. "Both tools had a built-in recorder and both recorded the selection of a list box correctly. However, the difference was in the execution." One tool played back as expected; the other threw an exception because the combo box included a special character.

To Do: Check that IDs are not provided with special characters.

Next week, I'll cover automation feasibility as it pertains to programming language, custom controls, obfuscation, application prototypes and testability hooks, stubs and testing beneath the GUI.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading