Setting up a system for testing by users (tables are tables?)

[guettli]

I have a task which looks simple at the first sight:

 Setting up a system for testing by users.

In my case it is a custom issue tracking system.

The users who should do the testing say "The new system should be like the production system."

If this would be true, then dump+restore of the database should work.

No Nr2: the production system contains a lot of issues, and these should not be in the new system.

No Nr2: The production system contains configuration (in the database) of remote storage systems. These

database rows must not get copied, otherwise the testing system would transfer testing data

to the production storage system.

Configuration like the list of ticket types should get copied.

Tables are tables, or is there a difference between tables?

Up to now I only found one hint to this task: In SAP this is called "client copy" and there seem

to be different "delivery classes" of a table:

https://help.sap.com/doc/saphelp_crm70/7.0.0.18/en-US/43/45860774b711d2959700a0c929b3c3/content.htm?no_cache=true

Are there tools/framework which support copying a system? I am curious, if you know a framework outside django, please tell me.

Up to now I could not find a tool or hint about solving this in a reusable way in django. If I was blind, please let me know.

Any kind of feedback is welcome.

Regards,

  Thomas Gütler

[guettli]

I see: no reply. Why?

[Derek]

*The users who should do the testing say "The new system should be like the production system."*

You need to let them know ASAP that that is very unlikely to be the case, unless you are using exactly the same tools.  You can probably provide similar functionality.

Otherwise you are too vague to give better feedback - "copying a system" has too many meanings.  If its just the database you need, and you plan to write a new front-end from scratch using Django, then that is "do-able" (assuming you can extract the data from SAP - that is a problem you will need to ask the SAP experts about).  Once you have the database available, you can follow this guide:

https://docs.djangoproject.com/en/2.1/howto/legacy-databases/

[Mikhailo Keda]

1. take a dump of production db

2. remove/anonymize all sensitive or unneeded data (you can use django admin or sql or python script)

3. reduce amount of data if needed

4. take a git branch with fixes 

5. make sure there are no sensitive data in your code

[guettli]

Yes, these steps look good.

I don't like thinking. Up to now I need to think if I need to decide if data is sensitive or unneeded.

It would be nice if this could be defined somehow. I think per row is not useful, but per table looks feasible.