Best practices for testing when consolidating systems

The following testing activities are recommended as part of a consolidation:

• Application unit testing—Testing performed to validate that any customizations to the ITSM application as part of the consolidation are working correctly.
• Migration unit testing—Testing that the data migration engineers perform to validate the success of the data migration component of the consolidation.
• Integration unit testing—Testing of each integration that the consolidation will affect. The testing is primarily focused on new integrations, although existing integrations might be affected, too. The impact of unique identifier changes can have a significant impact on applications that integrate with BMC Helix ITSM. Integration testing must be particularly focused around these identifier changes because these might affect service-desk-to-service-desk (SD2SD) integrations significantly.
• Cutover validation testing—Testing performed during the cutover and emulated cutover processes to validate that the data migration, application, and integrations have worked.
• User acceptance testing—Validation by the customer and business users that the application and supporting systems are all working effectively to support the business requirements. This typically is concluded by a formal signoff from the customer and business users that all components of the system are acceptable for production usage.
• Regression testing—Validation by the existing users of the system that the behavior of the system is not affected by the consolidation. Business/customers currently using the system should perform this important testing step and formally signoff on it.

Our recommended best practice is to document and track the execution of all test cases. This ensures that the scope of testing is clearly understood and that no component of the system is accidentally overlooked.

User acceptance testing recommendations

Identify all stakeholders and secure commitments from them for dedicated time to perform user acceptance testing. This activity is critical to the success of the project and cannot be performed in parallel with day-to-day activities and commitments.

We recommend that UAT includes testing of the following components:

• Core application functionality—Test all of the core application functionality that the business stakeholders rely on. This should include full lifecycle testing. For example, rather than testing only that a change can be created, test that all the involved stakeholders can create, approve, complete a change.
• In-flight data—Test that tickets that are part-way through their lifecycle and have been migrated from the current production system can be progressed through their lifecycle. For example, can an approval request created in the current production system be approved?
• Time-sensitive data—Time-sensitive data such as SLAs are critical to the business. It is critical to test that the application will process this data correctly after an upgrade. For example, will an open Incident created in the current production system correctly trigger SLA notifications when a milestone is breeched?
• Integrations—Integrations between systems that introduce data into the system, such as CMDB discovery or reconciliation, should be verified during UAT.

To ensure that the scope of testing is clear and that all system components are properly tested, document all test cases. The best results are achieved with a high level of structure around testing, including documented test cases and day-by-day tracking of testing progress.

Cutover validation testing

A typical cutover process executes a set of basic tests against the application to ensure that the data migration has worked effectively and that the key activities, such as incident creation, are working effectively. Some tests (such as checking that a report works) do not change data and are referred to as non-destructive testing. However, other tests (such as modifying an existing incident) change the data and are referred to as destructive testing.

Changes to existing data (such as closing a live incident that is not actually resolved) impacts the business. Consider using the following strategies to allow you to perform testing during the cutover without impacting the business:

• Take a full database backup during the cutover, perform testing, and then restore the database backup when testing is complete. This approach is the safest but will increase the outage window.
• Use the Cutover-methodology, which allows you to perform destructive testing without impacting the source or target production systems. Take a full database backup prior to the start of destructive testing. This backup will be restored into the target production environment after cutover validation testing is complete. This backup will not contain any of the changes made during cutover testing.
• Create test data in the production system prior to the cutover, and then modify this data as part of your cutover tests. This data will not refer to real business issues and can be modified at will. However, this data might affect reporting or trigger invalid notifications to users.
• Avoid any destructive testing. This is a high-risk approach that means that the application is not validated during the cutover process. If there are any issues, they might not be discovered until users are using the system. At this point, rolling back to the original system will have significant impact to the business.