Triggers, join logical files, constraints and data areas are all automatically created in your target environment or IASP.
When you execute choose your data source on your local IBM i or within an IASP. You can also select any remote IBM i and once the extraction is complete the data will be automatically sent to you test environment.
But the game has changed. GDPR and other legislation means that data confidentiality is no longer a choice.
Now simply decide which fields need to be protected and use a variety of obfuscation methods to protect your data. You can even synchronise your scrambling across multiple files.
Good, representative, clean test data is a precious asset but is quickly burnt through use or damaged by failed tests.
Now you can avoid either the painful save/restores and you can stop attempting to explain bad test results based on poor initial data.
Simply set a Checkpoint each time a transaction or set of transactions has been completed and simply return to this point if subsequent tests fail. We even handle the stuff that IBM doesn’t !
UI testing, examining API and batch outputs is great, but leaves a massive hole. What if the database is corrupted?
The challenge is that verifying the database is difficult, requires deep SQL skills and can only look at the final data state.
Now you can track every insert, update and delete including intervening data states. Even better you can create rules so that data failures are flagged to you automatically.
Stop buying DASD, Stop long-running data copies, Stop using data that is out of date. Get current!
Get GDPR compliant, protect your data assets and easily adopt best practice.
Data corruption can bring your company down but the database is the thing least tested. Now you can bring data to the heart of your testing.