next up previous contents
Next: Soak testing Up: Acceptance testing Previous: Data validation

Error handling

Designers of software systems intended for delivery to ING must ensure that they plan and design effectively for failures. Software systems must be designed to be robust to illegal input, erroneous or missing data files, network failures, instrument failures (where applicable), dynamic memory failures and predictable numerical failures. Here, classic programming misjudgements are programs which need not be sensitive to alphabetic case, but which fail to perform string comparisons in a case-insensitve way, or do not strip unnecessary white space off strings which are to be compared.

In an operational environment where software systems are frequently used by non-specialists it is safe to assume that if any of the above can happen, then sooner or later they will. It is the responsibility of the programmer to ensure that these predictable errors are checked for at run-time and that an informative error message is delivered to the user if an error occurs. In such cases, the aim of the programmer should be to have the software system recover from the failure and to leave the system in a known and usable state. If a successful recovery is not possible, then an error message describing the failure and informing the user that the failure is not recoverable should be delivered before closing the system down in a controlled way.

The software system's robustness to illegal input, erroneous or missing data files, network failures will be tested in detail. The software system must be able to recover from the failure and deliver an error message via the user interface. The error message must indicate the nature of the failure in enough detail to isolate its cause. If the software system is a control system, each instrument mechanism will be induced to fail and the resulting behaviour of the software system observed. The software system must not fail - it must be able to recover from the failure and deliver an error message via the user interface. The error message must indicate which mechanism has failed and, where appropriate, how it has failed. Any MIMIC display must also be updated to indicate that the mechanism has failed.

All error messages delivered by the software system must conform to any error reporting conventions provided to the developers during the development phase.


next up previous contents
Next: Soak testing Up: Acceptance testing Previous: Data validation


Fri May 23 10:19:54 BST 1997