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

Bug Developers Less, and Finish Your Scripts Early Too


By Edward J. Correia
April 17, 2007 — 
It's generally considered a good practice to wait until software components are completed before writing automation scripts for testing them. Some might even say it's a necessity.

But there is a way to write test scripts before a component is finished, and according to Torsten Zelger, test-team leader at Audatex Systems, reduce a developer irritant at the same time.

One thing that bugs Zelger and his bug-finders happens after a defect has been identified. "Each time we execute the same script and it fails at the same part, it starts bothering developers since they know of that specific defect and are already in the process of fixing it."

What often happens in these cases, Zelger said, is that testers will remove or "comment out" portions of the test scripts that flag known defects, a practice that itself can be problematic. "This is not a very nice approach because the automation engineer sooner or later will forget about this workaround for the script."

What happens then, as you might guess, is that those portions of the code are never again tested "regardless of whether or not the developer fixes the defect." This could also give rise, added Zelger, to a scenario in which a developer thinks something is fixed because test scripts no longer produce a flag. "But the defect is still there, and unless we remember that certain script, we will never test this again."

To avoid such a horror-cartoon scenario, Zelger's team devised a simple yet ingenious way to tie test scripts to their issue tracker. "A nice solution is the introduction of an extra routine that checks for the status of the defect." The solution works only if you have access either to the defect-tracking system through an API or directly to its database.

Here's one way to complete your scripts before the code is done. "In the following example, we raised a defect with the ID 55559 into the system. We expected the AUT [application under test] to return an error message, but it didn't."

The sample code below allows the automation engineer to complete his script without the need to worry when the developer fixes the defect, said Zelger. "We are able to cover both states of the expected behavior: when the defect is fixed and when it is not fixed."

Sample code:
string sExpectedError = "CustomerNumber must be numeric";

Defect pDefect = DefectTracking.GetDefect("55559");

if (pDefect.GetStatus() == "Fixed")

{

ASSERT(pError.Contains(sExpectedErrorMessage));

}

else

{

// DO NOT PERFORM THIS TEST OR SHOW WARNING

// IF DEVELOPMENT HAS NOT FIXED THE DEFECT

// ...

}

This script checks the defect system and does not perform this test as long as this defect remains unfixed. Once this defect is fixed, the script resumes testing and will show a warning if the defect is found. "With this extra code, we do not flood developers with information they already know," Zelger said, "and we automatically catch this test again as soon as the status of the defect is changed by the developer."

Think of the money you'll save on Post-It Notes!


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading