Dr. Dobb's Journal - November 2008 - (Page 47)

ADVERTISING SECTION DR. DOBB’S BEST PRACTICES TESTING Optimize Testing and Refactoring Efforts with Software Readiness Management Ben Chelf, Coverity CTO Software has reached an inflection point: a disproportionate amount of overall development budgets are spent on finding and fixing defects, as high as $22 million annually for many organizations according to the recent IDC report ‘Improving Software Quality to Drive Business Agility.’ This problem is compounded by the increasing complexity of software itself—with outsourced, legacy, and open source code in so many applications, development leads are more exposed to risk in their code bases than ever before. Additionally, the extensive reuse of code in SOA environments and the need to develop multi-threaded applications for multicore hardware push development teams to develop new coding skills on the fly, often without the benefit of formal training. Whether you use agile or waterfall methodologies, development managers must navigate a balance between functionality, timetables, and quality before advancing software from development to QA and finally field release. While tools provide managers with a wealth of information regarding the progress of code, data and metrics from those assorted tools are uncorrelated, preventing objective comparisons of the component parts of a software system such as code branches, code blocks or methods that are necessary to evaluate the quality and risk of failure of the application under development. Coverity, Inc. 185 Berry St. Suite 2400, San Francisco, CA 94107 USA General: (415) 321-5200 | U.S. Sales: (800) 873-8193 International Sales: +1 (415) 321-5237 oriented to prove a system meets functional requirements, leaving quality and security testing to QA teams downstream in the software development life cycle, who lack familiarity with the complex inter-dependencies of large code bases. The idea of simply widening test coverage can help managers understand more about their code base, but it quickly becomes impractical. For example, on a 64-bit machine, assuming a nanosecond per test case, exhaustively testing the square root function would take 584 years! (Note that this only tests one single-threaded function independent of its context or of its state during the function call). data types. In doing so, managers can drill down to the appropriate level of specificity in a given software system to evaluate code based on the metrics identified above. Moreover, analysis from multiple perspectives can provide valuable information regarding defects or vulnerabilities that may cascade through a code base. Software Readiness Management Today, new technology is bringing the discipline of analytics to software with the intent to improve development processes. At Coverity, we call this Software Readiness Management, because it allows teams to objectively assess release readiness by leveraging analytics that automatically incorporate, normalize, and correlate data from multiple tools. Importantly, Software Readiness Management provides visibility into code at both the physical and logical levels, allowing managers to pinpoint high-risk code with actionable, prioritized recommendations for testing and refactoring efforts early in the development life cycle. By improving the accuracy of testing and debugging, release managers and QA leads can improve the predictability and efficiency of their development processes while delivering higher quality code. The Need for Multiple Levels of Visibility Into Code Software systems can be analyzed at varying levels of detail. These levels can be grouped as physical (directories and files) and logical (code bases, packages, classes, and methods). Some data is available only at certain levels, for example, source code analysis typically is done at the physical file level. Meanwhile, some data is only meaningful at specific levels, such as cohesion and coupling at the class and project levels. Software readiness management takes these factors into account, as well as the variety and disparate nature of the Exhaustive Testing Is Impractical to Assess Release Readiness Testing software is a complex process that can be pursued with a variety of tools and means. Too often, testing is

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2008

Dr. Dobb's Journal - November 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer's Notebook Saving Open Source Conversations iPhone Building Your Own Web Server Green Telnet What's New In Boost Threads? Testing Service Oriented Architectures Test Case Generation, UML, and Eclipse Unit Testing Web Services C3 Programming The Agile Edge Swaine's Flames Effective Concurrency

Dr. Dobb's Journal - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.