I have question about DB privileges for QA tester. Our company has set strict rules for DB privileges and QA tester has mostly just privileges to view/read for all tables.

  • There is occasionally case when tester needs to do changes in DB, and for fast / flexible testing activities is maybe good to have set better privileges (mean write) then just view in particular tables if not full DB. There is also separated department for DB changes. For flexible testing it is pretty unconfortable (not flexible) to asking for this kind of changes.

So my questions are:

  • If there is any rule how to set privileges to DB set by QA documentation or is it strictly dependant on company policy ? (ISTQB, ISO ?)

  • Is any strong argument how to argue to grant better DB privileges for QA department as owner of test environment ?

  • What should be main argument ?


It depends how your process is set up. It makes sense to have read-only access to PROD environment for investigation.

Does QA have own copy of the system for integration testing (separate from development system)? In this QA system, QA should be able to make any changes. But even here, it would be smart to get proposed changes to be reviewed by DBA and/or developers, because (depending of the design of your system) might be easy to make manual changes which are not possible to do when using system "correctly" using services, and database would be broken in hard-to-predict ways.

Main argument is: what is the process which allows all of us as a team (developers, QA, DBA, sysadmin) to be most productive and deliver best value to our customers for time invested? If some process requirements makes you (QA) less productive without preventing bugs and delivering value, they should be reconsidered, modified, abandoned.

But it does not mean that QA should be able to do anything they want in QA system: If, say, they save some time but make more work to DBA, DBA have a valid point that such practice decreases productivity of the whole team.

There is no replacement to common sense and acting with good intentions.

  • If you break the DB because you did not fully understand the system, then maybe it was a lesson worth learning? If I have a fundamental misunderstanding of how the data works then how can I be confident my tests are comprehensive? – David Cain Aug 23 '16 at 19:06
  • I agree. But also one fool can in one hour create a mess which will take a week for an expert to clear up. And such errors would NOT be errors which your customers can ever encounter, so such "learning" might be a waste of time. As I said, use common sense. – Peter M. - stands for Monica Aug 23 '16 at 19:31

Anyone should have all the ways to do your work properly. It means the a QA should have the tools and access to investigate known and to-be-discovered issues.

Basically it requires:

  • Full access to the product in some way (E.g., a test environment that properly mirrors the production environment - hardware and software);
  • Proper time to do the work;
  • Necessary support to do the work.

Regarding DB access, two aspects are important:

  • The access to a mirror test environment fully on your control and easily restorable;
  • Help from people with access to production environment to create test data (fuzzed/smoked DB dump) necessary for your work.

I'd raise these issues and attack them one by one, creating ways to efficiently work on issues on production/strict access environments. (Automation and continuous integration?)


This is really a company specific question. Maybe your test environment is really complex and used by many people. In that case, maybe it is a good idea to not give out write access to everyone, only more experienced people. And meanwhile add additional test environments and keep them seperate.

In other cases, in my opinion. It's TEST environment, let testers do whatever they want, there should not be any argument even. If company sees testers as so incompetent they cant be trusted with test environments, then it is not a company you want to work for.


Yes, you should have your own (QA) environment that you have full control over. You should also have a mechanism for resetting the state of that environment in case you mess it up. Testing requires numerous changes in test data, waiting for someone else to make a change for you will just slow you down and will lead to you just not running some tests.

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.