Taking to Testing



Email    print   
February 15, 2007 —  (Page 1 of 2)
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.




Pages 1 2 


Share this link: http://sdt.bz/30120
 
Most Read Latest News Blog Resources

Add comment


Name*
Email*  
Country     


  • Comment
Loading




close
NEXT ARTICLE
Not so fast when it comes to testing in the cloud
Developers face outsourcing, virtual lab management and mobile devices as obstacles Read More...
 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 

Download Current Issue
FEBRUARY 2012 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?


 
blogs tab
Are you at risk for burnout?
Burnout is a severe problem and it can strike at any time. Here's how to tell if you are nearing the edge.
02/09/2012 02:16 PM EST

Agility, mom, and apple pie
If we're to evaluate the state-of-the-art in software development, we should start with the values espoused in the Agile Manifesto.
02/07/2012 11:57 AM EST

RIM woos developers with free tablet
How do you get more apps ported to the BlackBerry PlayBook? By giving every developer a free tablet, of course!
02/04/2012 01:57 PM EST

GitHire: Use Headhunters to Find Your Perfect Programmer
Are you a hiring manager tired of scouring the job boards? Check out this new service that will find 5 people interested in your jobs.
02/03/2012 12:17 PM EST

Facebook claims hacker cred
Facebook's SEC S-1 filing form includes a short essay on the Hacker Way by Mark Zuckerberg himself.
02/02/2012 08:26 AM EST

Ryan Dahl steps down
Ryan Dahl, creator of Node.js, steps back from his position as gatekeeper for the project.
02/01/2012 04:58 PM EST

 
Events calendar tab
2/13/2012 to 2/16/2012
Santa Clara
TechWeb

2/26/2012 to 2/29/2012
San Francisco
BZ Media

2/27/2012 to 3/2/2012
San Francisco
RSA

3/4/2012 to 3/7/2012
Las Vegas
IBM Tivoli

3/5/2012 to 3/9/2012
San Francisco
TechWeb