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...

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

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

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

Taking to Testing


By David Rubinstein
February 15, 2007 — 
The message these days from software purveyors and industry analysts alike is that testing needs to be done just as soon as coding begins. They say it costs too much to wait until an application is completed before fixing things that are wrong.

Vendors and pundits like to chart how costs increase exponentially as a software project moves further along the life cycle, from determining requirements, through design, coding, testing and maintenance. They say traditional software methods often squeeze the time for testing at the end of a project, almost ensuring that defects will make it into the final release.

You don’t hear people arguing against these points. What you might hear, however, is pushback from developers, who say extensive test-case writing is not what they signed up for. There is cultural resistance from those developers, the analysts and software vendors admit, to have testing invade their territory.

I recently moderated a Web seminar in which continuous integration testing was the topic. And in much the same way a parent would cajole a teenager to perform certain household chores, one of the presenters—Ian Hayes, founder of Clarity Consulting—laid it out for developers and managers: “What’s in it for you?”

The traditional end-of-cycle approach usually works like this: Code is written, code goes to the QA department, QA finds as many bugs as they can and throws code back to the developers. In this scenario, the error might occur in a bit of code the developer has not seen or worked on in quite a long time.

Continuous integration testing works like this: Code is written, test case is written, defects are found and corrected. The test cases are reused throughout the life cycle, ensuring better test coverage of the code.

So, developers want to know, “What’s in it for me?” First, defects are caught while the code still is fresh in the developer’s mind.

The problem is fixed before anything else is built upon it, so the fix won’t break anything else. Second, better code is passed through to QA, so there are fewer returns to the developer, who now has more time to do what he or she loves—that is, creating new code.

What’s in it for development managers? How about daily visibility into the quality of the code being produced. Progress can be charted, so scheduling becomes more predictable. And, issues are corrected before they can compound.

For executives, the benefit is more value from the business system being delivered. If ROI is a function of a system’s cost to develop versus the value it delivers to the business, lower development costs translate to higher value.

Clarity’s Hayes argues that a best practice would be for development organizations to embed testers with their developers, to create and maintain tests scripts going into the nightly build for functional testing.

That makes sense. Bring in the specialist. Just as you wouldn’t have your family doctor perform brain surgery, you should leave the test scripting and maintenance to a tester, freeing up the developers to do what they do best—innovate.

David Rubinstein is editor-in-chief of SD Times.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading