Software Testing: The Stepchild of Innovation
Stories Columns Opinions Resources
Preflight builds spread wings for smoother projects
Developers are increasingly turning to preflight builds, allowing them to experiment with ...
|
Coverity creates program to enforce code adherence
The Architecture Analyzer uses mapping technology from the company's Software DNA static a...
|
QCon 2008 features domain-driven development
This year's QCon invites speakers like Eric Evans and Dan North to talk about domain-drive...
|
.NET similarities prove golden for Silverlight
Microsoft has focused on making Silverlight 2 symmetric with the .NET platform, and that h...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Advanced Corda CenterView™ Data Visualization for the BusinessObjects™ Intelligence Platform
Corda Technologies presents a white paper on pervasive BI. The BusinessObjects business in...
|
From Mobile to SOA: A Guide for Optimized Application Deployment
Customer need has driven the emergence of multiple computing tiers. Today’s application d...
|
e-Kit: Web Application Security
Is your network secure? What about your web applications.
If IT security is your top p...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
By Edward J. Correia
August 19, 2008 —
Few would disagree that R&D efforts have given rise to countless technologies. But when it comes to research and development budgets, software testing often gets short shrift. Despite several recent decades of unprecedented technical innovation, "our ability to test these technologies has not kept pace with our ability to create them," says Elfriede Dustin, an author and software test automation consultant.
While most talk is focused on R&D, Dustin says little attention is paid to R&D&T—or research and development and testing—a term commonly used among defense contractors such as Innovative Defense Technologies, where Dustin works as a quality consultant.
"Innovation [teams] do not seem to consider the testing technologies required to accompany [that innovation]. [But] testing has become more important than ever. At IDT, we spend much time researching the latest testing technologies, and have come up with the 'Automatically Automate Your Automation' concept, which we are currently refining further."
In doing so, Dustin says IDT has identified some interesting trends:
Software development/testing is driving the business
While business needs once drove software/testing technologies exclusively, that trend is now shifting. "Software/testing is now also driving the business. Executives can have the best business ideas, but if the software and testing teams don’t deliver or the testing efforts are behind, the competition is only a few clicks away."
'Perceived' vs. 'actual' quality
As in so many areas of life, there's a gap between the quality people think they are getting and the actual quality that is achieved. For example, "[if] 10 defects occur very frequently and impact critical functionality, that would usually be perceived by a customer as poor quality, even if that defect density was very low. On the other hand, a high density of 100 defects that occur very infrequently and have almost no impact on operations would usually be perceived by an end user as good quality. Dustin believes this is due to a lack of adequate research and funding for usage-based testing, which exploits the concept of perceived quality, yielding higher perceived quality, and thus happier customers.
Testing misperceptions that require clarification
When deadlines are looming, the testing cycle in multiple environments can be numerous and can seem to take forever. "Testing often gets blamed for missed deadlines, projects that are over budget, uncovered production defects and lack of innovation." But often the real culprits, she says, are inefficient system engineering processes, "such as the black box approach, where millions of source lines of code [are] developed including vast amount of functionality, only for it to be handed over to a test team so they can test and peel the layers of code, painstakingly finding one defect after another, sometimes not uncovering a major showstopper until another defect is fixed."
These bad development practices, she continues, inevitably result in buggy code, requiring long and repetitive fixing cycles. "Another big pain point can be lack of unit testing. Statistics show (and my experience can back them up) that the more effective the unit testing efforts, the smoother and shorter the system testing efforts will be." She recommends incorporating such practices into an automated build and release process.
Unrealistic deadlines
Some might suggest a shift away from the testing focus and instead focus on improving development processes. "While this is not a bad idea, even if we implemented the best processes and had the most brilliant developers in house, developers don’t test. Software development is an art, and integration and system testing will always be required." Dustin offers numerous human factors to explain why developers don’t perform system tests. "They don’t have time, they don’t specialize in testing and testing techniques, they are busy churning out new code and functionality."
Dustin quotes Josh Bloch, a principal engineer at Google: “Regardless of how talented and meticulous a developer is, bugs and security vulnerabilities will be found in any body of code—open source or commercial. Given this inevitably, it’s critical that all developers take the time and measures to find and fix these errors.” However, pressure of unrealistic deadlines often put this ideal out of reach, as "developers are strapped cranking out new features. First-to-market is the key."
Library concept of code or component reuse
Innovative developers are turning to composite applications for the agility needed to get ahead of rapidly changing business conditions. "At IDT, we like the concept of checking out software components … within a library setting [as a means] to support software component reuse," says Dustin, adding that the ability to capitalize on existing components and assemble them into custom-built information sources will allow for a new look and feel, and new user interfaces and transactions, while also allowing for quick turnaround of a new release.
"We support these 'library' and 'software reuse' concepts by allowing for reuse of automated baseline processes and automated testing of those various tasks." For example, if only one line of code has changed in a component, an automated software testing process will allow for reuse of those testing efforts for each component in a shorter time, allowing support for the required efficiencies of the “library” software component for checkout and reuse.
"The goal is to improve our 'perceived' quality. We can accomplish this by what we have described and by focusing our testing on the most often used functionality—which absolutely has to work—the usability of most often used functionality, mean time to failure, and reliability, which we define as the probability that no failure will occur in the next 'n' time interval."
What it boils down to is this: Rather than a focus mainly on R&D, the effort must expand to include testing to become R&D&T.
Share this link: http://www.sdtimes.com/link/32735