This content has been marked as final. Show 9 replies
Fran is correct in what the definitions mean. Where I work we have them as follows:
QA - refreshed from PROD every week so we can test PROD (production) fixes before they roll to PROD. QA is locked down so only DBAs have access to run in scripts through a controlled process. Users can use the front end application to test their script changes.
UAT - Refreshed from PROD periodically, usually every 3 weeks for us. It is externally facing and allows users to test changes before they roll to PROD. It is also locked down and scripts can only roll through a controlled process.
The normal procedure for us is this:
1. A change is requested or a data fix required
2. The script is developed on DEV
3. Once signed off it is rolled to UAT for end user testing
4. Once signed off it is rolled to QA and tested again
5. Once signed off it is rolled to PROD
1006285 wrote:As pointed out, in general terms "UAT" is usually taken to mean "User Acceptance Test" and "QA" is "Quality Assurance".
What is UAT and QA database?
Yeah, so what? I'm reminded of an old Bill Cosby routine:
Teacher: One plus one equals two.
Sudent: That's great. What's a "two"?
"When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean -- neither more nor less."
(Lewis Carroll - Through the Looking Glass)
Should UAT/QA database be cloned of Production?They key is how they are used in your organization .....
Should UAT/QA database be cloned of Production?It depends. If you have a TB database and need to make a change of one small schema for an obscure app, probably not. If you have some critical app with many high profile users, probably so. If you have some app that has environment variable schema references, who knows? If you have database links, watch out!
You may need some sort of data cleanse package if you're restoring these environments from Production.
If you have personally-identifiable information or anything that's protected under various statutes - financial, medical data, etc - you need to check whether you must obfuscate this when running in a non-Production environment - different personnel and policies are likely to be in place in a QA/UAT environment.
For instance, you don't want a tester who has no need to see any medical history being able to associate a real person with a real set of medical records, you might have a 'superuser' that has access to everything to make testing easy, you might have accounts with insecure passwords, etc.
It's also a security issue: data at rest (backups) or 'real' data in less-secure environments can be a blind spot for DBAs and can be targeted by nefarious beings who won't necessarily have to break open your Production database to get at your Production data.
My experience is that the UAT database is a mirror copy of production that is provided for a handful of select people who are the actual people in positions that perform the tasks of the application that interfaces to the production database. And, since they are the only ones who truly know what the data results should be when testing, they would only have the same privileges as production. There is no need to obfuscate the data.
The QA database, however, is a different story. It is usually provided to a separate set of "testers" who work in the QA group specifically for the purpose of testing functionality, and not so much of regression type testing. In their case, depending on the nature of the data, it may be required (even by laws such as HIPPA) that this data be obfuscated. Typically, these testers may have higher than normal privileges since they will be testing functionality of various processes that they may not even understand. Instead, they are just following a set of test instructions and looking for specific results as noted in their testing instructions. Also, a QA database does not necessarily need to be a full copy of production as long as it has representative data for testing purposes - again, depending on the type of testing they are doing.