Saving Development Costs by the Numbers
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
June 24, 2008 —
Last week I told you about 10 cost-saving tips from the U.K. and presented the first five. Here are the remaining five. They’re from Martin Adcock, managing director of London-based software quality management solutions consultancy Experimentus.
6. Begin designing tests for User Acceptance Testing during requirements definition
If an organization is using the “V-model” of software development correctly, says Adcock, then the test team should be involved with the project from the very beginning–during the requirements definition. “Not only can the testers use their expertise and experience to help assess whether or not particular requirements are testable, but they can also start to design the relevant tests, which helps to ease the test schedule later.”
In this scenario, he says that user acceptance tests (UAT) should correspond directly to the user requirements. “This is because the requirements are the items that the user wishes to see in the system, and the tests represent the way that the system is proved to meet those requirements.” It logically follows, he adds, that the best time to write the UAT is when the requirements are being constructed.
7. Begin designing system tests during the system design stage
Whenever possible, it’s important that systems be designed for easy testing. But this can only occur if testing expertise is involved in the system design stage. “Collaboration between testers and the system designers can help ensure that the system [under development] fulfils this aim.” Adcock says that during this early involvement, the testers also can start to construct system tests, which helps ease the testing schedule. An additional benefit to this approach is the enhanced team collaboration between the system design and testing team.
8. Focus efforts on unit testing, where it’s cheapest
Everyone knows that correcting defects early in development is far easier, quicker and cheaper than doing it later. “Given this axiom, it is surprising that many organizations spend little or no time on unit testing activities—often with the reasoning that ‘our developers develop, and our testers test,’ ” says Adcock.
But this approach means not only that potential defects reach later stages of testing than they should, but it’s possible they may not be found at all. “[L]ater stages of testing normally perform different testing activities, in different ways, to those used in unit testing,” he says, and they could therefore miss those found easily with unit tests.
9. Plan test approach using risk to define focus of test effort
Test time is often limited for reasons such as fixed release dates and late software delivery from the development team. This can often mean that not all tests that were originally planned are carried out.
“In this scenario, it is vital that those elements of the system that are considered critical to product success have been tested. Therefore, the approach to testing should always be to focus effort on the ‘highest risk’ areas of the system first. Following this, medium-risk and low-risk areas of the system can be tested in turn, as time permits.”
This risk-based approach, Adcock says, ensures that areas of the system that remain untested (and are potentially flawed) are the lowest risk areas possible from those that are left to be tested when under time pressures.
10. Use tools to test for functional and non-functional errors early on when they are cheaper and more effective at removing errors, and throughout the life cycle
If an automated test set is created and maintained, it can be used repeatedly as a “smoke test” beginning at an early stage of development. “This method has the potential to find many defects quickly and early, saving time in later test phases.”
Additionally, specific tools may sometimes indicate flaws in the system design, which should be exposed as early as possible. “For example, early performance testing on parts of the system that are available might reveal a poorly designed module, which would hinder the system beyond the tolerance levels of the user when released.”
In this way, the module is easily identified and isolated, and can be fixed or replaced. Such identification, Adcock says, would be far more difficult if performance testing was conducted just before the system was to be delivered or deployed.
In other words, test early, test often. Testament.
Share this link: http://www.sdtimes.com/link/32423