they would have been under the old system, and the old system itself is restarted. In the least critical case, the database used by the new system is the same as that of the old system. More often, though, the new system provides expanded database content as well as improved processing. When the contents of the new database must be condensed back into the form of the old database, care must be taken to restore the data to the form in which the old system would have used it.
The software testing required includes at least the acceptance test of the old system, which often is augmented by the running of the most recent set of regression tests used for the old system. Clearly, there must have been some planning for back-out and replacement when the new system was installed. The old system would normally have been archived, but the saving of the acceptance test and the regression tests must also have been part of the archiving process.
Great care must be taken to see that the backing out and replacement are well planned and carried out. Time-critical issues regarding the need for the replaced system can add to the concerns and complexity of this action.
It is rare that a newly installed system is so badly defective that it must be replaced. However, it is the responsibility of the quality practitioner to make management aware of the threat, no matter how remote it may be.
2) Recovery Tests:Most data centers have recovery procedures for the repair of data on a damaged disk or tape, and they also consider the case of operator errors that may invalidate some of the data being processed. Recovery from abnormal terminations or system crashes may also require recovery tests.
Recovery related software testing is conducted when a hardware fault or operating error damages the software or the data. This type of software testing is critical to the confidence of the user when a data or software restoration has been conducted.
Often, restoration type of software testing can be accomplished by using the regression test software. In other cases, the full acceptance test might be required to restore confidence in the software and its data.
3) Stress Tests:Stress tests cover situations that occur when the software is pushed to, or beyond, its limits of required capability. Such situations as the end of the day, when 23:59:59 hours becomes 00:00:00 and the software is required to recognize that 00:00:00 is later that 23:59:59, must be challenged. The rollover of the year field is also a situation ripe for testing. The well-known Y2K situation was concerned with whether software would realize that the year 00 or 000 was later than the year 99 or 999.
Other stress situations occur when the software is presented with the full number of transactions it is expected to handle plus one or two more.
# What happens when the transaction n + 1 is presented?
# Does one of the existing transactions get overwritten?
# Is there a weighting algorithm that selects some transaction for replacement?
# Is the new transaction merely ignored?
Still another test case is the situation in which the software is run for a long time without interruption. This could easily expose flaws in housekeeping or initialization routines.
Stress tests are an important part of any test program. The types of stress that might be exercised will become apparent as the software develops and the testers understand its construction more clearly. There should be a valid way of handling these and other situations spelled out in the requirements statement. The compliance of the software with the requirement is to be challenged.
4) Regression Tests:Regression tests show that modifications to one part of the system have not invalidated some other part. Regression tests are usually a subset of the user or acceptance test. They are maintained for the verification that changes made as a result of defects or enhancements during operation do not result in failures in other parts of the system. Regression tests are an abbreviated revalidation of the entire system using generally valid data to show that the parts that were operating correctly before the changes are still performing as required.
A number of studies indicate that as many as 50% of all changes made to a software system result in the introduction of new defects. This may be low or high, but there is a significant risk involved in the introduction of corrections. Some, of course, are errors in the change being made, such as coding errors, change design mistakes, and the like. Others, however, come from unexpected interactions with subsystems other than the one being modified. A change to the way a database variable is updated in one module may affect the time at which another module should read that variable in its own computations.
Close configuration management control and analysis of changes, and their impact on the system as a whole, is necessary. Software quality practitioners must be sure that a change control board or equivalent function is involved in all change activity during both integration testing and the operation phases of the software life cycle. This protects the integrity of the baseline system itself and helps ensure that changes are being made to the correct versions of the affected software. Delivery of the proper versions of the modifications is also a function of configuration management, which QA or software testing practitioner is supposed to monitor.
Regression tests generally follow some sort of confirmation tests. The amount of regression testing to perform after a change is dependent on the risk associated with the change.