Migration Sign-off: Migration Testing

As described in Execution, the test plan becomes visible to all Portal users after the migration runtime starts to execute. It will appear on the ‘Test’ screen in the ‘State’ section of the Portal.

Test Team Preparation

Large projects will usually have a separate Testing workstream that is responsible for all aspects of testing the new system. The Test Manager will need to be set up as an External User of the Portal, together with all testing staff that they nominate. The latest snapshot can also be shared with the Test Manager before the runtime starts to execute, to allow them to start their preparation.

When the test plan is visible in the State section of the Portal, the Test Team can begin to update it. Comments can be added in the ‘Discussion’ text box, to describe the approach to the test.

Note: If the project has more than one Partition, comments can be for all, or a specific Partition.

When tests have been defined for the testing requirements, a second Data Owner interview should be arranged, to secure their agreement to the proposed tests. This agreement can be recorded in another Discussion comment.

Optionally, Tags can also be recorded at this interview, to capture the priority that the Data Owner places on each sign-off requirement. Recommended values are:

• Must Have
• Should Have
• Nice to Have

This prioritization can be very useful when seeking sign-off for the data migration, if the pass rate is less than 100%.

Members of the Test Team can also subscribe to the test areas they are responsible for, by clicking on the bell icon.

Subscribing to an area will allow a user to be notified of any updates to that area. This can include email notifications, if this has been configured in the Hopp infrastructure. Further details on managing subscriptions and notifications can be found here: Subscription and Notifications, and details of how to configure email notifications are explained here: Setting up Notification and Email. 

Test Recording

The migration team’s plan will be organized into Releases, as described in the Hopp Migration Methodology Overview article. At the beginning of each Release, the lead migration analyst will update the state of the areas being worked on in that Release to ‘In development’.

This will generate a notification to relevant test team members, that the area is now being worked on by the data migration team.

When the migration team’s work is ready to test, the state will be updated again. This will generate another notification.

Areas that are ready to test are indicated with a tick in the ‘Ready’ column and there is a warning icon in the ‘Test Pending’ column. It is now possible for a test user to update the State of the test area.

Further comments can be added to the Discussion. 

If a test is failed, an Issue should be added to the migration issues log. This can be done directly from the Links tab of the test area and clicking on ‘Create new’.

The basic details of the Issue are recorded and saved.

Further information about Issue recording is available in the Migration Issues Management article. 

The migration team can be assigned work to address the issue, at which point the state can be reset to ‘In development’. When this work is complete, the state will again be updated to ‘Ready to test’.

Testers can receive notifications to tell them that the area is ready to test again. After completing the testing again, they can update the state to either ‘Passed’ or ‘Failed (retested)’.