1.2 Automate testing
Automate tests to cover the large majority of your use cases. Automated Test Scripts programmatically perform validations.
Another good practice is to run automated testing as much as possible. Automation of test scripts is time-effective, accurate, and improves the bottom line of the business operations. As a result, bugs are uncovered more quickly and fixed more efficiently.
1.3 Business test using relevant data
In the case of major releases and changes directly impacting the business, your business users should test those changes in a production environment.
Another good practice is to run the UAT in a production-like environment. This will help the business users understand the change and certify that it works as expected.
1.4 Test the performance at peak
If you have large data or expect spikes in volumes, dedicate some time to perform testing in a production-like environment. Performance Testing of the production-like environment will assist in monitoring the latency issues and stability of the tenant.
1.5 Keep your master data aligned with production
Testing is most effective when the testing environment is clean. It is essential to clean and maintain production-like environments before each deployment. If environments are kept running for a long time keeping track of all the configuration changes and updates that cause failures and errors can be difficult.
Avoid modifying the product-like environment before any deployment.
1.6 Establish Appropriate Permission Levels
It is best to have well-defined roles with the required set of permissions for the users who can actually deploy from one environment to another. They should have the proper credentials and permissions before deploying from one environment to another.
1.7 Continuous Deployments and Releases
Continuous Deployment involves automating the release of a good build to the production environment. This makes the change management process more agile as the releases are managed in short iterations continuously.
2. Deployment Considerations with Zuora Deployment Manager and Central Sandbox
2.1 Deployment Manager
Zuora recently launched a feature called Zuora Deployment Manager® that provides full capabilities of comparison, validation, deployment, and roll-back, in order to support the best practices for deployment and testing.
Creating Deployment
The user experience for creating new deployments is intuitive and captures the Multi-entity. It may be in the best interest of the users to provide a description of Development: UAT or Production: UAT etc
Validating Deployment
The compare screen will check the potential sources of errors without making changes. It guides the users for the parameters with differences, no change, parameters that are in target only, parameters that cannot be reverted, and any feature which requires T9 permissions activation. Please refer to the known facts and limitations of Deployment Manager here.
Observability of Deployment
Observability is one of the most essential aspects of deployment. Zuora Deployment Manager captures the success and failure of API calls in logs so that users can understand what is happening in the backend, away from the user interface.
It is vital to maintain a record of the history of changes; currently, Deployment Manager allows users to download the information of the deployments in a CSV format. Maintaining an audit trail can be made easier this way.
2.2 New to Deployment Manager
If you are new to Deployment Manager, take a walkthrough of the feature on the following URL on Knowledge Base Zuora Deployment Manager or find A reference in the Community Post Zuora Deployment Manager Demo.
2.3 Central Sandbox
Zuora Central Sandbox is a centralised environment to test all Zuora features, including new pricing scenarios, customer acquisition channels, payment gateway connections, data migration efforts and new functionality, with real production data and settings.
Self-Service
The newly launched self-service refresh feature gives greater control of customer’s testing cycles by allowing production to central sandbox refreshes without the need to contact support.
API Testing
This sandbox positions customers to perform adequate testing for large-scale change initiatives where bulk updates need to be made via API in order to test and confirm that the changes are configured correctly.
Data Load Testing
In addition to API Testing, Central Sandbox also allows customers to perform adequate testing for large-scale change initiatives such as chart of accounts updates, bulk price increase changes, bulk contact updates, bulk billing account updates.
Bill Runs and Payment Runs:
Central Sandbox enables customers to perform adequate testing for billing-related questions related to large-scale change initiatives such as product-line swaps/changes
For more information, please refer Zuora_Central_Sandbox
Overall, Central Sandbox significantly improves testing cycle time by providing a test environment that behaves and provides functionality that is consistent with the production environment.