Recovery Testing overview | David Tzemach
Recovery testing is one of the essential methods in the world of testing. It belongs to the non-functional side of testing and is executed on different levels of the tested system.
When we perform recovery tests, we want to validate two crucial aspects of the software.
The first is the time it takes the user to return to regular work since the failure occurred. The second is how the software recovered: is there data loss? Does the software work as before the failure?
Why should we run recovery tests?
We need to run recovery tests because both hardware and software should recover from unexpected failures in a reasonable time. Our task as testers is to ensure that the software can return to a functional state in the expected timeframe.
Think about software that failed to recover after an unexpected failure. Will you want to use it again? Will you work with software that may lose crucial data in the case of a failure?
Recovery testing helps us understand whether the tested system can recover from unexpected system failures. In addition, recovery tests have some additional benefits that are relevant specifically to this type of testing:
Recovery testing allows you to provide answers to a client who wants to understand the losses in case of failure.
Recovery testing allows you to understand the effectiveness of the recovery process.
Recovery testing allows you to understand the weak points of the system.
You can eliminate software risks at earlier stages of the SDLC.
Recovery testing demands a deep investigation of the software architecture and supported platforms.
Recovery testing allows you to understand how the software behaves in case of failure.
Verifies that the recovery plan works.
When to use recovery testing
Recovery testing should be executed whenever the client specifies that the continuity of the regular flow of the system is critical. In such a case, the client will determine the exact requirements of the recovery process (timelines, data integrity etc.) that allow them to gain confidence in the software.
Example:
Data integrity should not be affected by the recovery process.
The software should be fully functional within 7 minutes.
If there is a loss of data, it must be minimal.
After recovering from a failure, the user can continue from the last working point.
Success factors for recovery testing
The user gets a valid explanation of the error.
The software returns to the last failure point and continues the original task.
The system recovers quickly and efficiently.
After the tests, you can approve that the recovery plan is working as expected.
The tester can supply the exact timelines to recover the lost data.
Proof that the software can be used without data loss.
Ability to eliminate unknown system behaviors.
Increases the confidence in the product.
Increases the stability of the product.