Development Team to Access QA Database?
Published on StickyMinds (https://www.stickyminds.com)

Home > Development Team to Access QA Database?
QAE m's picture

Development Team to Access QA Database?

QAE m asked on June 10, 2015 - 10:48am | Replies (6).

In terms of testing best practices, should Development Team have access to QA Database? If not, how do the developers troubleshoot/debug data related issue? 

kurt moore's picture

I do think that the dev team should have access to the QA DB. There are far too many scenarios that come up on a daily basis within testing that having a "pristine" DB is just not possible most times. Allowing a developer to edit/change data for the QA Team is also extremely valuable, as actually creating the data through an app or customer path can take too long for release cycle purposes. 

 

We use Stackify's app (stackify.com) that allows the QA team to query their DBs at anytime to pull back end data for validation testing. This helps new and less experienced QA to access data without having full DB access, and being able to see saved queries for regression testing as well. Their app also allows our team to limit all users (dev, qa, etc.) access to DBs/Apps/Logs on a user basis if we wanted to lock things down for any given reason.

Ankit Chourasia's picture

Dev team should have access to QA DB but it should be read only authority. Otherwise, there could be manipulations put on by the developers to save there context. And, yes that could hamper the best function of processes and applications. But, dev team would be benefited to have access to it as they won't be needing a approval or authority to gain the experience from the previous occurances. They will directly reach the QA information centre and can link the occurances of the defects and can see the reports to benefit clients as well as development practices.

 

Subramanian Ramachandran's picture

Provide dev teams to have readonly accounts to QA database. By this approach, dev can access QA database with readonly accounts to view the data, however cannot modify/disrupt QA data.

Kieron Horide's picture

I'll assume "QA Database" means the system's database in the test environment, rather than the database of the defect tracking/test management tool.

I hear behind this question that you have a figurative wall of mistrust between you and the developers. Improving that relationship might be where you need to focus your efforts.

It may be that you're talking about a production staging or UAT environment, in which case I would want developers who are trouble-shooting environment-specific problems to behave responsibly. That requires you to trust them, and for them to understand that absolutely everything in that environment is subject to a change control process they must follow.

Within teams the developers have admin access to system test and of course their own development and build server databases. Often we rely on them to build and maintain the environments. They know they are not to stuff up testers' data or execute any commands that could affect tests under way. Therefore, investigations are done after checking with the testers first, and possibly backing up the database. That requires you to trust them, and for them to understand how testers work and talk to testers nicely (and vice-versa).

Trust of course is earned, not freely given.

David Christian's picture

Developers don't need access to Production data or QA Database. If you're working with any integration project then you really need to see the grot in the data in order to identify and deal with data issues.One can create alternate enivironments for their research needs.

Dan Walk's picture
Dan Walk replied on June 12, 2015 - 6:24am.

Variant A. They should not. Troubleshooting and debugging are done in pair with a tester.
Variant B. They should. Troubleshooting and debugging are done according to schedule for sharing QA resources.
Variant C. They can have their own. Troubleshooting and debugging are done on copy or replica of QA DB.

6 Answers

Dan Walk's picture
Dan Walk replied on June 12, 2015 - 6:24am.

Variant A. They should not. Troubleshooting and debugging are done in pair with a tester.
Variant B. They should. Troubleshooting and debugging are done according to schedule for sharing QA resources.
Variant C. They can have their own. Troubleshooting and debugging are done on copy or replica of QA DB.

David Christian's picture

Developers don't need access to Production data or QA Database. If you're working with any integration project then you really need to see the grot in the data in order to identify and deal with data issues.One can create alternate enivironments for their research needs.

Kieron Horide's picture

I'll assume "QA Database" means the system's database in the test environment, rather than the database of the defect tracking/test management tool.

I hear behind this question that you have a figurative wall of mistrust between you and the developers. Improving that relationship might be where you need to focus your efforts.

It may be that you're talking about a production staging or UAT environment, in which case I would want developers who are trouble-shooting environment-specific problems to behave responsibly. That requires you to trust them, and for them to understand that absolutely everything in that environment is subject to a change control process they must follow.

Within teams the developers have admin access to system test and of course their own development and build server databases. Often we rely on them to build and maintain the environments. They know they are not to stuff up testers' data or execute any commands that could affect tests under way. Therefore, investigations are done after checking with the testers first, and possibly backing up the database. That requires you to trust them, and for them to understand how testers work and talk to testers nicely (and vice-versa).

Trust of course is earned, not freely given.

Subramanian Ramachandran's picture

Provide dev teams to have readonly accounts to QA database. By this approach, dev can access QA database with readonly accounts to view the data, however cannot modify/disrupt QA data.

Ankit Chourasia's picture

Dev team should have access to QA DB but it should be read only authority. Otherwise, there could be manipulations put on by the developers to save there context. And, yes that could hamper the best function of processes and applications. But, dev team would be benefited to have access to it as they won't be needing a approval or authority to gain the experience from the previous occurances. They will directly reach the QA information centre and can link the occurances of the defects and can see the reports to benefit clients as well as development practices.

 

kurt moore's picture

I do think that the dev team should have access to the QA DB. There are far too many scenarios that come up on a daily basis within testing that having a "pristine" DB is just not possible most times. Allowing a developer to edit/change data for the QA Team is also extremely valuable, as actually creating the data through an app or customer path can take too long for release cycle purposes. 

 

We use Stackify's app (stackify.com) that allows the QA team to query their DBs at anytime to pull back end data for validation testing. This helps new and less experienced QA to access data without having full DB access, and being able to see saved queries for regression testing as well. Their app also allows our team to limit all users (dev, qa, etc.) access to DBs/Apps/Logs on a user basis if we wanted to lock things down for any given reason.
©2011-2013 TechWell Corp.