If the new modifications are not tied to previous modifications and specific customer data, then we may be able to use the Cronus database as a test platform. This works well when our target is a database that is not heavily modified in the area on which we are currently working. As the Cronus database is small, we will not get lost in large data volumes. Most of the master tables in Cronus are populated, so we don't have to create and populate this information. Setups are done and generally contain reasonably generic information.

If we are operating with an unmodified version of Cronus, we have the advantage that our test is not affected by other preexisting modifications. The disadvantage, of course, is that we are not testing in a wholly realistic situation. Because the data volume in Cronus is so small, we are not likely to detect a potential performance problem.

Even when our modification is targeted at a highly-modified system, where those other modifications will affect what we are doing, it's often useful to test a version of our modification initially in Cronus. This may allow us to determine if our change has internal integrity before we move on to testing in the context of the fully modified copy of the production system.

If the target database for our modifications is an active customer database, then there is no substitute for doing complete and final testing in a copy of the production database using a copy of the customer's license. This way, we will be testing the compatibility of our work with the production setup, the full set of existing modifications, and of course, live data content and volumes. The only way to get a good feeling for possible performance issues is to test in a recent copy of the production database.