Back-ups …
So with the release of Amazon’s investigation into it’s AWS outage, our office conversation I covered yesterday spilled over into today!
Once again, it was a good example of what might be called “blue sky time” — thinking about the problem in different dimensions. Our architects thought of designs which might avoid it — specifically using several providers. We testers thought about ways to test those systems.
It looks like Amazon’s issue was down to a bit of human error, and it turned our office into a bit of a confessional …
“I once accidentally deleted all our company templates … that goodness for back-ups.”
“I once made a lot of changes, but didn’t understand one of the key dependencies in the code … that God for back-ups.”
“Yeah … I messed up our back office code … and we didn’t have backups. We do now, thanks to that.”
Ah yes, back-ups. Back-ups are just an overhead and a pain in the ass … until you need them, and then like Mr Back Office found out, then they’re invaluable!
It’s worth thinking about back-ups a little. Sometimes you’ll have a bad requirement which goes “the system will have back-ups”.
If you’re doing non-functional requirement testing, you might do a shallow test where you look at the system, you see a large back-up file, and go “yup, it’s backed up”.
Back in 2005, we would do a daily back-up to tape (yes, tape!) of our test server. It’d run at 2am, and if we came in and it spat out the tape, we knew it’d recorded.
What we didn’t know was there was a problem with the back-up. What we needed to do was try to restore from the back-up tape … then we’d have found a problem!
It’s not enough to know there are back-ups, make sure you test once in a while that you can restore from those back-ups. That is a lot of effort I know, but it’s a fantastic test!
I’ll leave you with my favourite strip from CommitStrip …
