Have you ever had one of those moments, that made you stop mid-stride and go, “Hey, that’s a great question!”? Well, I did.
Awhile back our team’s QA Engineer commented that a bunch of his tests where failing because the data was different. After discussing it with the team, it turned out that some additional data was loaded into the database. Now, that in itself isn’t out of the ordinary. However, because the data changed, the test results changed. So the Business Analyst of the team asked if we could “go back” to the time before the data was loaded.
Here’s where I come into the picture.
Normally I would look towards a backup to see if I could restore the database to it’s previous state. So I took a quick peak to see when the last backup was. Oopppss!! The last backup was well over 2 months ago and no where in the realm of being correct. Not good!
Digging a little further, I double checked the maintenance plans. Yup, all of the user databases were slotted for a full backup daily. Cool. Wait. Hold the phone. If each user database was slotted for a full backup, why no backup then?
Looking at little further, turns out the that agent job to run the said maintenance plan was disabled. Why you might ask? I have no clue.
So I asked.
A quick email off to our production DBA team revealed that the environment was used previously as a testing bed for a backup/restore process and someone turned off the jobs (for unknown reasons) during the testing process. Usually I wouldn’t have an issue, however the agent jobs were never turned back on. Thus all of the user databases in the QA environment didn’t have any recent full backups. Not good in my opinion.
Now the problem was being quickly resolved and no real harm done other than not being able to restore from a backup. However, this begged the question. If it’s QA, do we need to back things up? Is it not a playground?
My answer was yes, we need to back things up (as evident to this issue) and no, it’s not a playground. The development environment is your playground (if you have one). In my opinion, if you have a true QA environment, then it should be treated just like production is. Our QA team uses that environment to verify that production applications are working correctly, not just from a “data” perspective, but more of a hollistic perspective. Thus, if we can’t restore/modify/drop/insert data/objects into the database, then we have a problem.
Of course, I’m just a simple DBA from Nebraska. What do you think about it? Is your QA environment a playground or do you treat it like production?
Leave me a comment and let me know your opinion!
© 2012, John Morehouse. All rights reserved.