Bugs are easier to reproduce on data similar to production. That is why a copy of a store often ends up in a development environment. Along with it, however, may come names, addresses, messages and documents that are not needed for the task.
Find out what the application will connect to
Start by checking the database address. The test environment should use its own copy. Also verify email, payments and other integrations, so that test actions do not trigger real events.
Make a backup before changing the data. Preparing the database may take several attempts, especially if the application uses custom tables or dependencies.
Read the scan report
Run a scan in Contextadmin. The report shows the type of data and the tables and columns where findings were detected. Pay attention to the areas the chosen profile does not cover. A ready-made store profile may not know all the tables added by integrations.
Review the anonymization plan
Choose a profile or prepare conditional rules for your own schema. Do a dry run and compare its scope with the report. Replacement data should preserve the relationships needed for testing, for example the link between an order and an account.
After the operation, review the follow-up scan. Then open the application and check the feature you plan to develop. An operation that finished without errors does not yet confirm that the data is suitable for your tests.
Look beyond the database
Anonymization in the panel covers the database. Attachments, exports, logs, PDF invoices and older backups remain a separate area to check. Check which of them the agent can access in the project directory.
Record in the context the scope of the work done and any exceptions. When you pull data from production again, the preparation has to be repeated. You will find the tool’s instructions in the chapter on database anonymization.