1

I am in security administration, not QA. Our testers have requested a userID with full access to the QA databases that will run scripts to clean-up/delete (DB2 SQL) data when necessary - which is pretty much every day. I'm not keen on this idea as it's another userID without accountability since many different staff members will be using it each day. They want it to streamline their processing.

How do others manage the clean-up of data in their QA environments.

thanks for your help, Ann M.

3

It varies. I've been in situations where the QA database was owned and maintained entirely by the QA team. That database was typically kept as a backup in a network share, and restored into the test environment at need.

In my current situation, the data cleanup is handled differently. The database is too large to restore in a viable time frame and contains too much sensitive data. Instead, there are other reset mechanisms which I have no access to. My approach here is to keep the data I create as clean as I can, clean up anything I run into which is bad, malformed, or ugly, and make as much as I do reversible as I can.

If the QA database is small enough and it's feasible for the QA team to run their own server (it can be on a quarantined subnet with its own internal firewalls), let them. The reason they want the access is to make sure the data they're working with is kept in a state they can use - I think every long-time tester is familiar with the test that takes 2 hours to configure and 5 minutes to test (and has set up a dedicated data set so that they don't have to do this more than once).

Another possibility is to boost your database logging and give the qa team members the access they want on their accounts. If your main concern is knowing who ran which script at what time, this would give you that information.

Testers do tend to fall foul of security processes fairly often - our major concerns with data are to keep it in a state that meets our needs, which includes a lot of backing up before doing a test with a chance of corrupting data, then restoring if we have to. (Not to mention automation that checks database tables against baselines and needs to be able to run nightly with a non-expiring password).

If you work with them, chances are you'll find a method that suits both of you well enough to be used. You can always tweak once you start if your initial attempt is problematic.

| improve this answer | |
0

I know somewhat similar problem but from the QA perspective. Unfortunately our administrators weren't kind enough to even ask for possible solutions and we heard straight "NO", so I can only give you idea how we've tried to solve it.

Best one we've got so far, is to take all necessary clean-up scripts and restrict access to them to just execution (with compiled executable, execute only files on remote computer, etc...). Then, one brave men gets full access rights to the database and mentioned scripts, being the one responsible for maintaining them. The rest of the crew is happily executing scripts when needed, using his stored credentials, while blaming the poor man if something goes wrong.

| improve this answer | |
0

The way we solved it in our current project, is working very well so thought of sharing it.

In the QA environment, earlier we were using static test data from CSV/excel files which were a pain to clean-up, restore and maintain in QA database.

Now we are completely moved to the entirely different approach where we are automatically refreshing database from production to Dev monthly and from Dev to QA weekly so everything stays in sync periodically. Now every test fetches data dynamically as a precondition from QA DB through SQL queries and works on it so no matter what DB instance we are working on each test itself takes care of its data requirement dynamically. So in a way, we decoupled data dependency from the tests itself.

And if the test doesn't find the pre-requisite data in DB, it simply fails at first step as 'Data Not Found'so basically all test data management process is automated & isolated from the actual tests which are a big relief for the automation team and DBA.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.