CHANNELS
HOME
TOP STORIES
COLUMNS
OPINIONS
ZEICHICK'S TAKE
EMBEDDED NEWS
TEST & QA REPORT
ECLIPSESOURCE
SPECIAL REPORTS
SD TIMES 100
JOB BOARD
EVENTS CALENDAR
RESOURCE CENTER
WEBINAR CENTER
ADVANCED SEARCH
RSS
ON THE WEB
SITE MAP
ADVERTISE
EDITORIAL
PRIVACY POLICY
CONTACT US
REPORT A BUG
PRINT EDITION
SUBSCRIBE NOW!
CURRENT ISSUE
BACK ISSUES
SUBSCRIBER SERVICES
BZ MEDIA
ABOUT US
NEWS
BZ RESEARCH
SYSMANNEWS
ST&P MAGAZINE
STPCON
ECLIPSEWORLD
ADVERTISER LINKS
activePDF
Alexsys
Altova
Amyuni Technologies
Automated QA
Axosoft
Business Objects
Codejock Software
ComponentOne
Coverity
Data Dynamics
Developer Express
dtSearch
Dundas
Dynamsoft
Hewlett-Packard
IBM
Imagix
Infragistics
InstallAware Software
InterSystems
iWay
Kovair
LEAD Technologies
McObject
Microsoft
MKS
No Magic
nsoftware
Parasoft
Pegasus Imaging Corp
Perforce
Prezza Technologies
Programmer's Paradise
Programming Research
Rally Software Dev
Red Gate Software
ScaleOut
Seapine
Serena
Software FX
Sparx Systems
Swell Software
Syncfusion
TechExcel
Telerik
UrbanCode
WANdisco
Xceed Software
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!
EMAIL THIS ARTICLE
SEND FEEDBACK
MORE TEST & QA
 
SUBSCRIBE TODAY!
E-Newsletters:
News on Mon/Thurs.
Test & QA Report
EclipseSource
SUBMIT
 
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
 
EVENTS CALENDAR
SHARE 2008
8/10/2008 to 8/15/2008
San Jose
SHARE
ACM SIGGRAPH
8/11/2008 to 8/15/2008
Los Angeles
ACM SIGGRAPH
Intel Developer Forum
8/19/2008 to 8/21/2008
San Francisco
Intel
Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software
VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media
REGISTER
MORE EVENTS
GET NOTIFIED!
About all of the latest Resources
SD TIMES 100
6th Annual SD Times 100
It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.