12

I have a 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 uncomfortable (not flexible) to ask for this kind of change.

So my questions are:

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

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

  • What should be the main argument ?

Improve this question

5 Answers 5

Reset to default
7

It depends on how your process is set up. It makes sense to have read-only access to the Production 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 the system "correctly" using services, and database would be broken in hard-to-predict ways.

The 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 the best value to our customers for time invested? If some process requirements make 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 has a valid point that such practice decreases productivity of the whole team.

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

Improve this answer
2
  • 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, 2016 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, 2016 at 19:31
1

Anyone should have all the ways to do your work properly. It means 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);
  • The 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 the 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?)

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
0

Meet the needs of your users

And in this particular aspect and part of your process, your users are... the security folks.

So think about presenting solutions for their needs.

For example, consider making a strong case for special roles or groups or accounts (but not shared ones) that provide this level of access on a granular level for a particular group of users in a particular environment. "Explain" that you want to make sure you can both trace (for audit) and also immediately cut off access for security reasons. They already know this but your eagerness to show your respect for those aspects will go down well. Just don't be condescending or over-explain and throw in a few 'as you folks are obviously aware of' to lighten things up.

Making the case using these arguments may have greater impact than strongly stressing your more immediate needs which often become a much-ignored noise to security folks.

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.