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

Ask for What You Need


By Edward J. Correia
June 12, 2007 — 
Last week I gave you a to-do list for evaluating an application's suitability for testing in terms of unique object identifiers. Also came the assertion that many developers give little or no consideration to testers when building their apps. Since I heard no contradictions, here are a few more ways to work around such difficulties.

Like last week, test automation specialist Torsten Zelger shares his checklist of items for determining the feasibility of test automation, this time as related to programming language, custom controls, obfuscation, application prototypes and testability of hooks and stubs.

One way the programming language used to develop the AUT impacts automation, Zelger says, is in the ability of your test automation tool to read the proprietary data coming from the AUT's controls. "Developers might have to include extra code that provides automation tools with the ability to communicate with the AUT," he says. One tool he has used recognized names of Java GUI controls only if the names began with the dot (.) character. "It was documented in the test tool's reference manual, but who was to hit on such a hint in the first run?" puzzles Zelger.

To do: Identify which programming languages are used, clarify that such languages are supported in the test tool, and determine if special programming or add-ons are required.

Custom controls can send up another red flag. "The use of painted or customized third-party GUI controls or components [that incorporate] a lot of graphics may be an extra challenge to automate," Zelger warns. In these cases, he suggests looking for hot-key or tabular-button equivalents to navigate through graphical icons on the screen for testing. "A flight traffic–control application [for example] is full of dynamically displayed pictures, and is therefore not a good candidate for GUI automation unless the developer provides these controls."

To do: Make sure the test automation tool can read important GUI controls. If it cannot, try alternatives such as keyboard equivalents or ask developers to build some.

Zelger provides another example involving the display of a calculated result in realtime each time a new record is entered. "The preview pane control may lack the ability to serve your test tool with information that could be valuable as an automated checkpoint. In such a situation, it is useful to check whether the output can be collected in a readable format from a different source that you can hook to." Sometimes this comes in the form of a temporary file, he says. "In this case, it is more efficient to perform tests using the file and keep only a small set of manual tests to check whether the transformation from the file to the preview pane is correct."

To do: Determine whether display components have a published API and/or can output to a readable format.

Obfuscation tools can cause particular problems for test automation, as their express purpose is to improve security and thwart copyright infringement by making output unreadable. Unfortunately, this also may affect test tools to read the properties of GUI components.

To do: Find out whether obfuscation tools are in use and request that they not be applied to code on the GUI level. The tools can still be effective when applied just to the business and data-access layers.

Application prototypes are helpful not just for acceptance testing, but also for getting an early handle on automation feasibility and even GUI function testing. "A simple demo application, [in which] developers expose all the different GUI controls, may help to quickly identify where your test automation tool may have problems reading or accessing those controls," Zelger says.

To do: Urge developers to give you one or several dialogs that include all the GUI objects to be used in the AUT.

Testing activities can be most effective if testers are given access to tools that allow quick checks and changes to fields in the underlying persistence layer. This can be done, Zelger says, by allowing testers to connect to the database or by providing an interface or API through which to read, update and create data where access to the database is not possible. "Such hooks are powerful instruments that testers often underrate or request from the developer too late," Zelger says.

To do: Ask whether the AUT provides APIs that allow testing under the GUI. If the software allows this, these tests should always be considered for addressing GUI change issues.

Zelger also advises that testers look for testability hooks. "Most applications give away much more information than you might think, if only you set the correct debugging parameters." And if the application doesn't have any, ask developers to give you some.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading