Overall, I do not like pointing to production ever for test/qa etc, even for reads. Inevitably someone will mess up the config setting at some point and you'll

Overall, I do not like pointing to production ever for test/qa etc, even for reads. Inevitably someone will mess up the config setting at some point and you'll write test data into Production. I have had it happen, even when the db user access should have prevented the writes, but stuff happens. I'm a big fan of taking a sample of production data, anonomizing what should be and then pushing that into test environments. I even now always write a script (or code) up front to automate the process before getting to far into development. I also always include "broken" records or strange data that has broken production in the past so that we regression test against it. I add the broken records as test pre-conditions usually so that in case someone deleted those records during other tests they will get recreated. BTW -- depending on which DB you use, I generally have started to configure a test DB that gets replicated to that acts as a source. So essentially what I do is replicate a subset of data from production to the test source DB all the time, then all other copies are made from that source DB which is never itself touched (other than an anonomizer). I only keep enough data in that source DB to make the largest test valid. What this does is let a dev copy say 500 records to his laptop to test with, or with Integration or QA they can have the whole source DB.