Rationalizing inadequate quality control (QC) procedures after an embarrassing and costly system failure is a response no longer tolerated in these days of global market forces and diminishing margins. When test automation and solid procedures can eliminate problems 99% of the time, no excuse has traction.
In the worst case, problems caused by defective software go undetected for days because internal and external users incorrectly believe that IT is already aware of the bug and fail to report it. Sometimes, the ensuing losses are sizable and make the evening news, but most often, these stories go untold. For obvious reasons, companies don't willfully discuss their problems publicly. But despite discretion, the tribulations of high profile companies are increasingly visible, and some people are trying to determine how big the problem is. Analysts at The National Institute of Standards and Technology (NIST) released a 309-page study revealing that software bugs cost the U.S. economy an estimated $59.5 billion each year. Another study conducted by testing automation advocate and tool vendor The Original Software Group, Ltd. explains why. This study indicates that less than 20% of the companies that develop or maintain their own code are comfortable with its stability before releasing it to end users.
It's ironic that software QC should be taken lightly given the fact that in other circles, quality and accountability are the mantras of this century. Lots of reasons exist to move to the higher ground of excellence. Improved productivity, profitability, and customer service are just a few.
Documented quality control processes are now federally mandated, foisted upon companies in FDA regulations and acts of congress like Sarbanes-Oxley (SOX), Basel II, and others. QC consciousness even adds to a company's marketability. Displaying ISO, OSHA, and TQM credentials on company Web sites and in literature helps sell more widgets. The pure reason for moving toward higher quality shouldn't be based on the need to comply or company image, though. It should come from the excessive cost and harm that defects pose.
Most often, the wounds that come from faulty code are self-inflicted. IT departments have the unfortunate distinction of practicing an exacting science in the midst of a speeding supply chain and a brick wall of investors. Often, companies transfer the competitive Darwinist nature of business onto IT and push it to failure.
The intrinsic fallibility of humans is a problem, too. Though it's hard to admit, people are bad at finding miniscule irregularities, especially when they're weary from seeing the same code a dozen times. Some bugs are obvious, but what about those that aren't? Under repetitive circumstances, if bugs exist, humans may overlook them, especially in applications that don't have a UI (but a computer will not). Debugging gets harder when the problem lies in the interaction between subsystems. If the program under scrutiny is sizable, convoluted, and hard to break down into constituent parts, manual testing is impractical and ineffective.
The lack of adequate training also contributes to defects. Methods and Tools, a newsletter dedicated to software testing and workflow, recently asked its readers how many weeks of training on software testing they had completed in their professional lives, and the results were astonishing: 43% of 240 respondents said they had no training, and 19% said less than one week.
The Value of Test AutomationAutomated testing delivers value in almost any instance where software is changed. An automated testing tool can explore interactive, batch, and service programs. It can check these programs for database access, rules, job log parameters, data area program calls, and I/O handling like screens and reports. Its value in a basic sense is weighed by the number of manual tests it saves technicians from running and the amount of rework that can be avoided.
Test automation may not always be appropriate. Though rare, manual testing may be a better fit in an instance where a particular test needs only to be run a single time. It is true that automated tests take time to set up, but they can be reused until the functionality they were designed to check either changes beyond the test's limitations or is eliminated.
To see if test automation is appropriate, first determine if it is necessary to repeat a sequence of actions and if it is possible to automate those actions. Bear in mind that elements such as variable data and scripts that update themselves can also be built into the equation these days. It's also important to be certain that the software under scrutiny does not act differently when it's exposed to the rigors of automated testing.
If the case for test bench automation can be made, this technology can be used in a number of ways:
- Regression and Unit Testing--Software should be tested after every modification. One insurance company uses test automation to QC daily changes made to policy calculation software.
- Load or Stress Testing--Normally, it would be difficult to corral 100 colleagues all at the same time in order to stress test a new application. To really understand what is going to happen when several users hit the Enter key, an automated testing solution can simultaneously run a script hundreds of times without even one technician monitoring the process.
- Compatibility and Black Box Testing--Testing the link to back-end, iSeries-based applications that are accessed through an external interface can be time-consuming and tricky. A large U.S.-based electronics retailer uses test automation to pump simulated transactions though a new POS system. The data entered is then compared to the data that is applied to a back-end inventory application to ensure system integrity.
- Functional Testing--An automated test suite can efficiently interrogate the entire software package every day if necessary. Debugging is much more effective when developers can test an entire application after one day's worth of modifications have been applied. It would be impossible to do this manually.
- Documentation and Compliance--An automated testing program can record the results of a test accurately. This data can be logged and retrieved later for QC analysis. A top pharmaceutical manufacturer uses automated software testing to document every change made to its manufacturing system in order to comply with SOX and FDA rules.
Zap Bugs with Technology
Sound testing practices can eliminate problems that surface when applications go live, reduce development time, and improve the software's maintainability through comprehensive internal documentation. Automated software testing tools simplify the process so that it is done more comprehensively, more frequently, and with less resistance.