CHANNELS
 
 
 
 
 
 
 
 
ON THE WEB
 
 
 
 
PRINT EDITION
 
 
 
 
BZ MEDIA
 
 
 
 
ADVERTISER LINKS
 
 
 
 
 
LOADING...
LOADING...
 
 
AS OF 8/7/2008 4:31PM EST
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!
 


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

Download Current Issue!
ISSUE 8/1/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.