What good is disaster recovery planning if there is no testing? Testing your plans and preparations is a vital part of DR, but the next question is – how (or when) should that testing be done?
There are hints in the way that software engineers test their work. Their new software release is in a sense equivalent to your recovery from IT disaster, even if there is a difference between deliberately proceeding to a release and deliberately taking steps to prevent a disaster (which may still happen, hence this discussion).
“Shift Left” is the new software testing mantra. How might it apply to disaster recovery testing?
First, let’s define shift left testing. In software testing, shift left testing refers to moving testing activities to make them happen earlier in the overall development cycle, i.e. towards the left on the timeline that usually runs from left to right. This is in response to the difficulties engendered by testing late in the cycle, which are:
- Testers are less involved in initial planning and design, meaning they know less about potential vulnerabilities that should be tested
- Testing and the resources required are neglected or insufficient
- Requirements and defects are not uncovered and fixed until after significant effort has been wasted on planning and implementing them
- There is less time to fix defects in the plan or design found by testing, which increases the risk they will be postponed until later, and possibly too late.
Expressed like this, the similarities between software testing and disaster recovery plan testing should be obvious. Software engineers then have different models for “shifting left”, and some of their concepts and definitions are more specific to software development.
However, the general principles hold good for disaster recovery testing: integrate testing early on, preferably when the DR plan is being formulated, and benefit from insights throughout the process for a DR plan that is robust and reliable afterwards.