Stop running database scripts to reset test data, there is a better way.
One of the common use-case problems we hear about from QA Teams is figuring out how to reset test data once any testing activity has been performed on a complex test environment. In most cases, the stories describe multi-day or multi-week processes that must be completed to reset a test system back to some known data state. If you don’t do a reset, then you are accumulating technical debt in your test data. Any repetitive testing results become suspect, and quality decisions can not be made from the testing results. In some cases, it isn’t possible to start a new iteration of QA testing without first resetting your test data from the prior test run.
What is the common way this is addressed? There are two obvious choices:
1) Run some form of DB “reset” script that will go through and delete data from the database schema and then re-insert clean data to be used as the next testing starting point. This approach’s problem is that data could also have been created outside of the application’s databases under test. For example, configuration flat files or log files might be part of what is modified during a test run. And of course, if “something goes wrong” while running the reset script, you have to triage and debug what happened—all time-consuming.
2) Physically remove the file system files that make up the database holding the data and re-create the database from scratch. With this approach, it might not be as prone to failures or errors and a refresh script that deletes data, but it does require more specific expertise to do the database administration.
There is another way.
The cloud approach leverages “image templates” where complete, ready to use VMs along with their network topology, and test data are saved into templates. If a database becomes corrupt, or heavily modified from the previous testing, instead of resetting the data via scripts, the cloud model replaces the entire database VM along with all of its data in one-step. The reset process can often be done in seconds or minutes versus hours or days. Complete ready to use environments containing dozens of VMs can be saved as templates and reconstituted in very short amounts of time. For example, instead of taking days, weeks, or months to rebuild a complex multi-server system, what if it could only takes a few hours?
The test cycle of the “Environment” under test then becomes this:
In one step, replace all the components that became dirty from the last test run. The environment template contains all the servers in a state where they are ready to use, including having test data at a known starting point.
Ideas like this are why it is worthwhile to take existing Enterprise applications and do a simple “lift and shift” to the cloud without making any structural changes to how the application works. Moving an on-prem application to the cloud still brings along all of its historical “cruft.” But on the positive side, by doing a simple lift-and-shift to the cloud, you get cloud capabilities applied to traditional on-prem applications. Even if you have an existing on-prem application whose destiny is not to exist in the cloud, you can leverage cloud capabilities to improve how it works.