IT disaster recovery planning needs realistic risk assessment, but it also needs to be tested. You have to know for sure that in the event of damage, loss or unavailability of any IT-related asset, your organisation can get back to normal operations as quickly as needed and limit prejudice as required. You will never know if that will happen if you do not test. Yet testing is the Achilles heel of many enterprises. From failing to check that data backups can be restored, to finding out too late that a DR plan has missed a crucial factor, shortcomings in testing can be your undoing. Is it time to change your testing perspective altogether?
If you have had any exposure to software projects recently, you may have seen a particular trend in the way testing is done. Historically, testing was often the poor relation. It was pushed back to the end of the process, to be “bolted on” as an afterthought. Worse still, it was slated “to be done if there is time”, which frequently meant it was hasty, incomplete or non-existent. After the resulting quality problems persuaded IT teams that a change was necessary, test-driven development became popular. In this case, testing isn’t just where the project ends: it is also where the project starts, with continual development-test cycles all along the project timeline.
A similar approach with the same benefits is possible for disaster recovery planning too. The tests that the DR plan must pass are defined. Then the plan is built with the goal of passing those tests. There is a continual cycle of testing until that objective is achieved, and regular testing thereafter. All the test situations, scenarios and factors required to test for proper recovery (and there are typically many) are brought forward in the process and woven into it. You increase your chances of a) identifying everything that could go wrong, b) finding good solutions, and c) making sure they work. Is it time for test-driven disaster recovery in your organisation?