test (or qa) vs staging environment - clarification on how staging env functions

Question

I looked at this question. As far as I understand test env is for qa department to conduct their tests, and staging is identical to prod, but hidden from end user.

My questions are:

1. Should staging be 100% identical to prod, or is it ok for staging to have "messed up" data in it? Just how much is it ok for staging db to differ from production db?
2. Is it normal/standard procedure to copy tables from staging env to prod env? Is that how other companies do it in the real world?

---

Why am I asking (or where I am coming from)

I have a txt file and I have to dump contents of this file into database. We have 3 environments: dev, test, prod. I can dump data to dev, test but not prod. We are not allowed to dump data directly to prod database. We are only allowed to move data by requesting a database move. Then somebody will copy table from test to prod for me. My concern is that while doing testing in test db I may corrupt correctness of data, and if I submit db move document and it gets approved messed up data will make it to production database. I want to avoid this, obviously.

Answer 1

Should staging be 100% identical to prod?

I believe that the answer to this question can vary significantly from company-to-company. You should discuss the specifics of your company's various environments with someone knowledgable at your job.

My concern is that while doing testing in test db I may corrupt correctness of data, and if I submit db move document and it gets approved messed up data will make it to production database.

If you are worried about messing up data in the "test" environment, I would suggest you develop some type of test(s) which can be executed in the development and/or test environments to ensure your changes are safe. While the form of these tests will vary based on the scope of your work, some suggestions could include:

1. Direct tests against the code you wrote ("unit" or "small" tests)
2. A script which iterates over the database table after you've dumped to it and ensures all data is correct
3. Pull a representative sample of test cases to verify by hand (or by a script)

There may be other forms of verification that make sense but without context on your specific system, it is hard to point to a definitive test suite!