Playground or Not, That Is the Question!

Last Updated on June 23, 2012 by John Morehouse

Hmmm, should I swing or slide? This is the question at hand.

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.

2 Replies to “Playground or Not, That Is the Question!”

  1. My company has 3 or 4 environments, depending on the app:
    Dev – Developer work space
    Stage – QA environment
    Integration – Customer facing QA
    Prod

    Of these, the only one I consider a true playground is Development. In there, I’ll grant developers SA (with care) and allow them to adjust backup and maintenance jobs. They can also create databases at will. The assumption is that if they blow their foot off, it’s their own damn fault, i.e. that’s the one bullet Barney Fife gets. Any other environment is hands off. Because we need to maintain a consistent QA environment, control over Stage and Integration is almost as strict as production.

  2. Mike – I completely agree. Our environment is setup much like yours, where the developers only have true rights in Dev & Stage (although our QA world is completely separate) and only reader rights in Integration & Production. I just thought that it was interesting point of view that was taken. I tend to treat QA just like production, since that’s the environment that mimics exactly what should be in true Production. Thanks for your thoughts!

Hey you! Leave me a comment and start a discussion!

This site uses Akismet to reduce spam. Learn how your comment data is processed.