Cloud implementation - test
This unit is a summary of the steps in the test step of a cloud implementation of finance and operations apps.
Deploy a sandbox environment
The sandbox environment will include all core functionality of the Dynamics applications and will typically contain sample or demonstration data. Occasionally the sandbox environment can be reverted back to the base product. At the end of each cycle, after the customer business decision maker (BDM) has signed off requirements, the sandbox environment will be converted into the Training environment, and the final sprint cycle build will be deployed to the training environment.
This will allow trainers to learn about the customizations and start to produce training materials. Sandbox environments can also be used for performance testing, to ensure that the product meets the performance needs as outlined in the requirements specification.
Testing and sign-off
When a requirement has been analyzed, designed, and developed, it should be tested before the requirement can be regarded as complete.
Each test script produced during the ‘Create test scripts’ activity should be executed and any failures should be tracked as bugs in Azure DevOps (formerly known as Visual Studio Team Services (VSTS)) and discussed among the consultant and customer subject matter expert (SME) to determine what changes, if any, must be made to the development or the test scripts.
During this activity, if any changes are required an initial estimate should be made for implementing these changes. If this initial estimate can be included in the daily sprint cycle without impacting other deliverables, these changes will be accepted.
However, if the change is expected to extend the original estimate time and impact the delivery of other requirements within the daily sprint cycle, then a change request should be raised. The change request should record the required change and then be discussed during a sprint technical preview session.
No changes should be incorporated within the cycle that would result in the increase in the duration of any requirement estimate or detailed task estimate. When all sprint cycle tests for the requirement have been completed and all required changes have been made or documented with a change request, the requirement is deemed as ‘Complete’ and the next requirement task is undertaken.
Monitor system health
At any point in time, you can monitor the system health using the Monitoring and diagnostics dashboard in Lifecycle Services and fix any issue found in the environment. You can also use system diagnostics to identify bottlenecks and performance issues, along with any warnings or errors from data gathered from collectors in Lifecycle Services that pull the data from the finance and operations apps instance.
Triage bugs
After the testing process, bugs will be triaged. This includes bugs with customizations or bugs that require Microsoft attention. Each bug must be assessed against the impact to the project.
Support tickets
You can raise a support ticket with Microsoft using the support service in Lifecycle Services. Use the support service to create incidents and submit support tickets to either your development team or Microsoft.
Get updates from Microsoft
At any point in the lifecycle, you can download hotfixes relevant to any environment from the Environment page. You can use the Update tool in Lifecycle Services to update the application and binary packages.
Priority bugs closed
Ensure all priority bugs have been delivered, tested, and closed.
Analyze Code
The Customization analysis offers finance and operations apps customers an automated tool to validate the customer’s model files against finance and operations apps best-practice rules for tables, classes, forms, and enums. It then generates reports that list all issues that were identified. Make sure that you evaluate your customizations using customization analysis and then file bugs for the issues that were identified.
Data migration
Ensure that data migration has been run and tested by business users. This needs to be done prior to User Acceptance Testing (UAT).
User Acceptance Testing
All business scenarios must be tested with production data in the target environment. UAT sign-off is required from the customer.
Gold build sign-off
Your company may also be interested in having a gold environment. Your gold environment is used to stage data for go-live and it acts as the database of records for implementation. This environment is meant to be kept as up-to-date as possible as it acts as the system of record during mock go lives and pre-go live activities. To apply a gold build to your production environment you sign-off on the gold build that you want to use. After you have the gold build, upload it to the Lifecycle Services Asset library and tag it as a gold build. Use the asset libraries for this stage of implementation.
Performance testing sign-off
Performance testing should be a combination of system health and end user feedback to ensure that all environments are performing as expected. You can also use system diagnostics to identify bottlenecks and performance issues.