|
How do you find the bugs in a software application? Many different types of testing help find the bugs that need to be eliminated before your custom software application is delivered to you. Different types of testing for bugs take place during the various phases of the software development project including:
- Module Testing
- Integration Testing
- System Testing
- Acceptance Testing
- Site Testing
Module Testing: In the previous issue of Info Point, we discussed module testing as part of the programming phase of a software development project. In a software application, each group of related screens that automates a business function is considered a software module. Modules are tested individually before they are combined with other modules. Module testing is important to make sure that a module works as designed by itself. The module should accept input and produce output without any errors. Programming in modules ensures consistency, simplifies training, streamlines programming, and facilitates changes. All these features of modular programming ensure that you get the custom software application you need, not a pre-packaged system that doesn’t help you meet your business objectives.
Integration Testing: After a software module passes testing, it is integrated with other software modules, and the modules are tested together. As more modules are added to the integration, various parts of the system are tested to uncover any problems or errors early in the project. The earlier a bug is found, the less it costs to fix in time and money.
System Testing: System testing is a critical phase of custom software development. During the system test, all the modules are integrated and tested together as one application. The main objective of the system test is to run the application in an environment as close as possible to a live environment with as little simulation as possible. If the system test is skipped, bugs may show up during acceptance testing or after the system has been installed. Training can also begin during system testing so that you and your employees can be involved in the acceptance testing part of the project.
|
Why is a bug a bug? At Harvard University, on the evening of September 9, 1947, The Mark II computer was being tested. The test was not going well, and after investigation, Grace Hopper, who was serving in the Navy at the time, and her associates found a moth ensnared between two points of a relay. They removed the moth, taped it to the computer log book and indicated that they had “debugged” the machine. This was the introduction of the term “debugging a computer program.” The original bug, shown below, is now at the Smithsonian Museum in Washington, D.C. Grace Hopper, who retired with the rank of Admiral from the US Navy in 1986, was a leader in the field of software development. She passed away at the age of 86 in 1992.
Courtesy of the Naval Surface Warfare Center, Dahlgren, VA., 1988.
|
Acceptance Testing: During acceptance testing, the custom application is demonstrated and tested to show that the system is what you and the consultant agreed to when you started this project. During acceptance testing, several criteria should be introduced that have not previously been introduced. For example, employees who will
be using the new system and have used the old system should be involved in the acceptance testing. Also, real system data that has not been previously used in testing should be introduced to the system. During acceptance testing, you and your consultants make certain that the system you install accurately reflects your business processes.
Site Testing: Site testing is done at your site with your employees. Site testing uses your equipment, your data, with no simulation at all. If the custom system is new, it can be installed and tested without considering any existing system. However, if the new system replaces an existing system, sometimes the new and old systems are run in parallel. In the case of parallel testing, you can use the output of the new system immediately, but you can switch back to the old system if you need to do so. You also can compare the output of the new and old systems to make sure they are identical. Once the new system is accepted, you can discard the old system and use the new one exclusively.
It can be exasperating to wait on hold for long periods of time trying to get through to technical support for an off-the-shelf software product. Even more infuriating is being told that the problem with the software is a bug that will be fixed “in the next release.” With custom software, you can work with your consultants to make sure bugs are found before your system is up and running in real time.
|